Feature "ratification" process

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Feature "ratification" process

Simon Reinhardt
Hi,

I just had this random idea how to improve the development process and make the end result be what the community wants as well as giving the developer the knowledge their work is wanted and not wasted. I know, this sounds like an utopic all-in-one solution ("egg-dropping woolmilksow" as we say in .de), but perhaps it could work.

Let me first describe the current process. Basically there are two ways of new features to be added or changes to be made. Either a user requests an RFE. We already achieved to be dispciplined enough to let this all be done over trac. Sometimes there is some discussion about the RFE on the ticket page for it, mostly between the requesting user and a developer, rarely with other community members. Then if the developer decides the feature is worth implementing, they implement it and let the result go live on the test server.
Another way is that the developers have ideas for new features or improvements themselves. They will then implement them - sometimes with, sometimes without ticket - and put them on the test server.
This is all logged through the tickets and changesets on trac. It is accessible for everyone, yet very few people if any follow this and mostly other users note the changes on the test server or even not until it goes live and they have to use it the first time. So most of the time the development process happens silently and decisions are done by the developers.

This causes: people who don't like the new features / the changes (the developer might think it is better, but different people have different opinions). Either they complain about the changes and annoy the developers or they don't say anything because they fear annoying the developer knowing it was a lot of work. Good communication in the golden middle happens rarely because not everyone is an expert in good communication (including me ;)).

How could this be changed? What I have in mind is some sort of "ratification" process. This would include the following:
- Developers add tickets for their own feature ideas (only for the bigger ones, not for changes of cell heights or stuff like that).
- Proposed features are discussed by the community before work on them is started, so that the developer can be sure what they implement is wanted by the community and they don't waste time working on implementations which are rejected.
- Changes on the server code are handled with a voting system similar to that we use for the MB data:
  - Changes which the developers consider trivial will just be applied
  - However for bigger changes they can and should (requires some self-discipline) put for a vote. Everyone (or just "major contributors"?) can take part in that and decide if they like it or not. If the change is related to a ticket and there has been enough discussion on the ticket before, then the change will surely be accepted (requires self-discipline on side of the users). For changes which are not related to a ticket, this is the first chance for the community to ratify them.

So why should a developer put their own work to a vote? Isn't this a risk to let good work being rejected? - Well, what's the alternative? If it is just applied although people don't like it, then they will complain which produces hate and - if enough people complain - more work because the changes have to be undone. This is also a good reason for developers to create tickets for their own ideas: they can get the ratification/approval of the community *before* they start the work.

It may sound like it slows down development but I think it actually reduces work and increases satisfaction on both sides.

Another thing which could help with this process is - rob mentioned that? - to have a test server farm where people can implement features and let others decide whether they are good or not.

Simon (Shepard)

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

ZaphodBeeblebrox


> Hi,
>
> I just had this random idea how to improve the development process and make the end result be what the community wants as well as giving the developer the knowledge their work is wanted and not wasted. I know, this sounds like an utopic all-in-one solution ("egg-dropping woolmilksow" as we say in .de), but perhaps it could work.
>
> Let me first describe the current process. Basically there are two ways of new features to be added or changes to be made. Either a user requests an RFE. We already achieved to be dispciplined enough to let this all be done over trac. Sometimes there is some discussion about the RFE on the ticket page for it, mostly between the requesting user and a developer, rarely with other community members. Then if the developer decides the feature is worth implementing, they implement it and let the result go live on the test server.
> Another way is that the developers have ideas for new features or improvements themselves. They will then implement them - sometimes with, sometimes without ticket - and put them on the test server.
> This is all logged through the tickets and changesets on trac. It is accessible for everyone, yet very few people if any follow this and mostly other users note the changes on the test server or even not until it goes live and they have to use it the first time. So most of the time the development process happens silently and decisions are done by the developers.
>
> This causes: people who don't like the new features / the changes (the developer might think it is better, but different people have different opinions). Either they complain about the changes and annoy the developers or they don't say anything because they fear annoying the developer knowing it was a lot of work. Good communication in the golden middle happens rarely because not everyone is an expert in good communication (including me ;)).
>
> How could this be changed? What I have in mind is some sort of "ratification" process. This would include the following:
> - Developers add tickets for their own feature ideas (only for the bigger ones, not for changes of cell heights or stuff like that).
> - Proposed features are discussed by the community before work on them is started, so that the developer can be sure what they implement is wanted by the community and they don't waste time working on implementations which are rejected.
> - Changes on the server code are handled with a voting system similar to that we use for the MB data:
>   - Changes which the developers consider trivial will just be applied
>   - However for bigger changes they can and should (requires some self-discipline) put for a vote. Everyone (or just "major contributors"?) can take part in that and decide if they like it or not. If the change is related to a ticket and there has been enough discussion on the ticket before, then the change will surely be accepted (requires self-discipline on side of the users). For changes which are not related to a ticket, this is the first chance for the community to ratify them.
>
> So why should a developer put their own work to a vote? Isn't this a risk to let good work being rejected? - Well, what's the alternative? If it is just applied although people don't like it, then they will complain which produces hate and - if enough people complain - more work because the changes have to be undone. This is also a good reason for developers to create tickets for their own ideas: they can get the ratification/approval of the community *before* they start the work.
>
> It may sound like it slows down development but I think it actually reduces work and increases satisfaction on both sides.
>
> Another thing which could help with this process is - rob mentioned that? - to have a test server farm where people can implement features and let others decide whether they are good or not.
>
> Simon (Shepard)

I like this idea!
I think it will need a tiny-bit remodeling to work in the scheme of mb (altough I wouldn't know how or which part)
but I think this could work. I can clearly see how this can make the developemnt easier, I especially agree with "and they don't waste time working on implementations which are rejected."
If *I* was a developer, I'd surly like that.
it would potentially make the work much faster too, because developers then could focus on parts that people *really* wanted to be changed
and they would in return reap alot more sweets than thorns for their trouble.

~mo :D

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

DonRedman
In reply to this post by Simon Reinhardt
Well to be honest, I do not thik this will ever work. You will never find  
a volunteer programmer who writes a feature and then lets some people vote  
it down.

You will however find volunteer developers who pick up _all_ the feedback  
(even the one they do not like) and work together with people who are  
prepared to put energy in the issues they percieve to solve all issues  
(even the ones they do not understand). Robert said that he learned this  
the hard way a few years ago. Keschte is learning right now. :-)

Remember that we have very few people doing actual development work.  
Putting even more weight on their shoulders can easily put the development  
to a total halt.

Also note that we already *have* a system in place to help with these  
problems which works very well: Idea Championing. This is a possibility  
for non-hackers to help in the development process, to encourage early  
discussion with the community and to take weight from the dev's shoulders.  
Unfortunately this has not been used a lot lately. I have done this twice  
and it has worked quite well.

So instead of devising some complex and abstract QA scheme, I suggest you  
just get something concrete done. Go and pick up some issue that you feel  
is important and be its IdeaChampion and work together with a dev. The  
IntuitivePicardInterface is one that springs into my mind, but I am sure  
there are others.

Yes this needs some competences in good communication and this needs some  
persistence. That's life. :-)

And remember: Rules follow practice!
This means: If you actually *do* something and by doing so you implement  
some aspects of the scheme you devised, then this might become a rule. But  
not beforehand. We already broke our nose twice this way.

Cheers,

   DonRedman


On Sun, 06 Aug 2006 22:45:27 +0200, Simon Reinhardt wrote:

> Hi,
>
> I just had this random idea how to improve the development process and  
> make the end result be what the community wants as well as giving the  
> developer the knowledge their work is wanted and not wasted. I know,  
> this sounds like an utopic all-in-one solution ("egg-dropping  
> woolmilksow" as we say in .de), but perhaps it could work.
>
> Let me first describe the current process. Basically there are two ways  
> of new features to be added or changes to be made. Either a user  
> requests an RFE. We already achieved to be dispciplined enough to let  
> this all be done over trac. Sometimes there is some discussion about the  
> RFE on the ticket page for it, mostly between the requesting user and a  
> developer, rarely with other community members. Then if the developer  
> decides the feature is worth implementing, they implement it and let the  
> result go live on the test server.
> Another way is that the developers have ideas for new features or  
> improvements themselves. They will then implement them - sometimes with,  
> sometimes without ticket - and put them on the test server.
> This is all logged through the tickets and changesets on trac. It is  
> accessible for everyone, yet very few people if any follow this and  
> mostly other users note the changes on the test server or even not until  
> it goes live and they have to use it the first time. So most of the time  
> the development process happens silently and decisions are done by the  
> developers.
>
> This causes: people who don't like the new features / the changes (the  
> developer might think it is better, but different people have different  
> opinions). Either they complain about the changes and annoy the  
> developers or they don't say anything because they fear annoying the  
> developer knowing it was a lot of work. Good communication in the golden  
> middle happens rarely because not everyone is an expert in good  
> communication (including me ;)).
>
> How could this be changed? What I have in mind is some sort of  
> "ratification" process. This would include the following:
> - Developers add tickets for their own feature ideas (only for the  
> bigger ones, not for changes of cell heights or stuff like that).
> - Proposed features are discussed by the community before work on them  
> is started, so that the developer can be sure what they implement is  
> wanted by the community and they don't waste time working on  
> implementations which are rejected.
> - Changes on the server code are handled with a voting system similar to  
> that we use for the MB data:
>   - Changes which the developers consider trivial will just be applied
>   - However for bigger changes they can and should (requires some  
> self-discipline) put for a vote. Everyone (or just "major  
> contributors"?) can take part in that and decide if they like it or not.  
> If the change is related to a ticket and there has been enough  
> discussion on the ticket before, then the change will surely be accepted  
> (requires self-discipline on side of the users). For changes which are  
> not related to a ticket, this is the first chance for the community to  
> ratify them.
>
> So why should a developer put their own work to a vote? Isn't this a  
> risk to let good work being rejected? - Well, what's the alternative? If  
> it is just applied although people don't like it, then they will  
> complain which produces hate and - if enough people complain - more work  
> because the changes have to be undone. This is also a good reason for  
> developers to create tickets for their own ideas: they can get the  
> ratification/approval of the community *before* they start the work.
>
> It may sound like it slows down development but I think it actually  
> reduces work and increases satisfaction on both sides.
>
> Another thing which could help with this process is - rob mentioned  
> that? - to have a test server farm where people can implement features  
> and let others decide whether they are good or not.
>
> Simon (Shepard)
>
> _______________________________________________
> Musicbrainz-experts mailing list
> [hidden email]
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
>



   DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

Nikki-12
In reply to this post by Simon Reinhardt
On Sun, Aug 06, 2006 at 10:45:27PM +0200, Simon Reinhardt wrote:
> Either a user requests an RFE. We already achieved to be dispciplined
> enough to let this all be done over trac. Sometimes there is some
> discussion about the RFE on the ticket page for it, mostly between the
> requesting user and a developer, rarely with other community members.
> Then if the developer decides the feature is worth implementing, they
> implement it and let the result go live on the test server.

One problem I've noticed with this method is that when a developer does do
the change, someone else tends to come along and report a bug for it to be
changed back. Having more community input rather than just input from the
person requesting the changes/features would, hopefully, help reduce that.
I know I sometimes look at the bug/feature list and think "but how many
people even *want* that?".

> Another thing which could help with this process is - rob mentioned that?
> - to have a test server farm where people can implement features and let
> others decide whether they are good or not.

I want to expand on that... Right now, for people with svn access, the
development process generally goes like so:
 * developer thinks of a good idea
 * developer implements it and commits it to svn
 * test server is updated
 * a: people testing come across the feature, hate it and complain
 * result a: chaos, hurt feelings, etc.
 * b: people testing come across the feature and like it
 * result: success
but there's no way of knowing just which outcome we'll get.

With a test server farm and more discussion the process could be:
 * developer posts about an idea
 * people like it
 * developer implements it on a test server
 * people comment on it
 * developer makes improvements
 * last two steps are repeated until the feature is deemed satisfactory
 * feature is commited to svn
This has the advantage that features aren't released in a state where lots
of people are still unhappy about how it works.

or:
 * developer posts about an idea
 * people don't like it
 * developer saves time and work

While these are pretty idealistic scenarios, I think getting people's
opinions *before* putting lots of effort in would be very helpful. I've
noticed that for an open project, we don't give people much information on
what's going on behind the scenes, new features just materialise whether
people want them or not. Also, I think testing particular features
separately is also easier for people because they've got something to focus
on. I know I never know where to start when testing!

--Nikki

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

Simon Reinhardt
In reply to this post by DonRedman
Don Redman wrote:
> Well to be honest, I do not thik this will ever work. You will never
> find a volunteer programmer who writes a feature and then lets some
> people vote it down.

That's why I proposed adding tickets for bigger features which can have some sort of informal voting process to *prevent* getting done work rejected.
Which is better? Doing silent work, having people who don't like it and complain loudly - and then probably undoing the changes. Or good preliminary planing together with the community, *less* complaints, *less* worthless spent time?

> You will however find volunteer developers who pick up _all_ the
> feedback (even the one they do not like) and work together with people
> who are prepared to put energy in the issues they percieve to solve all
> issues (even the ones they do not understand). Robert said that he
> learned this the hard way a few years ago. Keschte is learning right
> now. :-)
>
> Remember that we have very few people doing actual development work.
> Putting even more weight on their shoulders can easily put the
> development to a total halt.

I don't want to put more weight on anyones shoulders. It's not that I want to put chains on the developers. Rather I want to improve the process such that the developers get the feeling the work they do is exactly what is wanted. Robert said it quite right: the developers are the people who make MB possible. They are not only machines who implement code for features that other people have in mind but actually they are the most inventive force in MB. People might have rough ideas about features, developers though have to bother with all the details. But! They are single persons who do the work the way *they* think it is best. That doesn't mean most of the users think the same. So they will get feedback anyways (quite as you said) and will have to get along with it (since it's the users they write the code for). I just propose changing the way the community is involved in the process, to make it better for both sides.

> Also note that we already *have* a system in place to help with these
> problems which works very well: Idea Championing. This is a possibility
> for non-hackers to help in the development process, to encourage early
> discussion with the community and to take weight from the dev's
> shoulders. Unfortunately this has not been used a lot lately. I have
> done this twice and it has worked quite well.

I don't think it is that easy. You are missing some cases here. Idea championing (whatever that exactly is, it has no wiki page :P ) doesn't work for all of them. The simplest case is that a user has an idea for a feature, works out some details and tells a developer. That's what I have done with the track parser: it came to my mind, I did a rough sketch of it on a wiki page, Stefan implemented it, lots of people liked it. Typical case for you idea champion stuff I guess.
But how about that: user Anton has an idea, developer Berta works on it for some days and puts it on the test server, users Carsten, Detlef and Frieda notice it and don't like it (or just some parts of it or the way it was implemented). They complain, one of them probably enters a ticket to remove it, the developer is pissed because she (Berta ;)) put lots of work in it, Carsten, Detlef and Frieda are pissed because Berta doesn't see why it should be removed, eventually it gets removed anyways, now Anton is pissed. Also a typical case for successful idea championing?
Or how about that: the developer changes the layout or the way the interface works thinking it is an improvement. Some users think the same, lots of users don't think so and want it to be changed back again, or changed in another way. This has nothing to do with idea championing at all. Of course good communication afterwards can help to change the changes in a way that more people will be happy. But how about some good communication *before* the work is done? Every software developing company does teamwork planning before writing a single line of code. I think an open source project should do that even more!

> So instead of devising some complex and abstract QA scheme, I suggest
> you just get something concrete done. Go and pick up some issue that you
> feel is important and be its IdeaChampion and work together with a dev.
> The IntuitivePicardInterface is one that springs into my mind, but I am
> sure there are others.

I don't think what I proposed is complex. And I thought it was quite concrete. I can't get something concrete done because I'm not a developer of MB and probably never will be (this is partly a decision, partly my abilities). But I'm adding tickets all the time. I think that's the best way for me to communicate with the developers.

> And remember: Rules follow practice!
> This means: If you actually *do* something and by doing so you implement
> some aspects of the scheme you devised, then this might become a rule.
> But not beforehand. We already broke our nose twice this way.

You are the expert but I think you see this a bit too strict. ;)

Greets,
  Simon

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

DonRedman
I think I see where we misunderstood each other. I am not against more  
communication before and durnig the development process. I am, however,  
opposed to two details in the *way* you want to achieve this:

(a) A voting mechanism that creates a hurdle, instead of a process which  
fosters collaboration.
(b) Devising an abstract process as 'policy', instead of doing something  
and leading to a policy by example.

I'll go through both points in detail.

Ad (a)
Some issue trackers give users the possibility to vote _for_ a ticket.  
(but not against). This is a means of measuring the percieved importance  
of an issue to the community. People can rate how annoying a bug is to  
them. This works. I do not know if Trac supports this. It is really only  
necessary in very large projects in which the devs loose the overview over  
all the tickets.

However, with a *feature* you rarely know beforehand how it will look  
like, in what it will help and how it will create new problems. So if a  
dev writes a ticket for a new feature (and this _is_ a burden: She[1]  
might just have a vague idea but is forced to write up a comprehensive  
proposal) the cummunity might at best make a very uninformed decision  
about a feature that would look completey different if it were developed.  
If you have ever accompanied a development process, then you know that it  
is _during_ that process that understanding of the issue emerges, that  
concepts are overthrown and problems solved. Not beforehand.

IdeaChampioning is a concept that fosters communication _during_ the  
development process. From your mail I gather that you have not understood  
how it works (you are not to blame, as, ideed, it has not been documented).


> I don't think it is that easy. You are missing some cases here. Idea  
> championing (whatever that exactly is, it has no wiki page :P ) doesn't  
> work for all of them. The simplest case is that a user has an idea for a  
> feature, works out some details and tells a developer. That's what I  
> have done with the track parser: it came to my mind, I did a rough  
> sketch of it on a wiki page, Stefan implemented it, lots of people liked  
> it. Typical case for you idea champion stuff I guess.

No, it's not. It is not a one way process. IdeaChampioning also means to  
champion your idea in the mailing lists in front of other _users_.
You will put it forward when peoploe point ot an issue that you think  
would be solved by the idea (this will help you to understand other user's  
views of the problems, to find flwas in your idea or imagined  
implementation).
You will also have to 'shield' the dev from all the debates (and noise)  
that take her attention from the thing only she can do: coding. You will  
deal with the debates and give her condensed reports by mail, skype or  
wiki pages (which will instantly document your feature).

So, let's see how this works in your examples.

> User Anton has an idea, developer Berta works on it for some days and  
> puts it on the test server, users Carsten, Detlef and Frieda notice it  
> and don't like it (or just some parts of it or the way it was  
> implemented). They complain, one of them probably enters a ticket to  
> remove it.

If Anton is a good idea champion, they will not enter a ticket but use the  
mailing list. That is the public forum in which Anton started to discuss  
the feature. That is where they will complain.

> The developer is pissed because she (Berta ;)) put lots of work in it.

If Anton does his job, he will be in between the raw complain and Berta.  
He should use good communications techniques (mirror the other's POV,  
"Yes, and" and all that jazz) to figure out, what exaclty pisses the  
others off. There will very likely be some substance to the complain, and  
picking this up can only make the implementation better. Once the  
discussion has reached this point, Anton will pass the good bits over to  
Berta in the medium they have decided to use for their collaboraton. Berta  
will be pleased because she can go on hacking undisturbed and gets good  
feedback (that she would never have thoght of).

> Carsten, Detlef and Frieda are pissed because Berta doesn't see why it  
> should be removed,

In this case they should be relatively happy because their concerns have  
been taken seriously. Note that this is the tricky part. Anton has to pay  
close attention to a lot of things:
  - that the debate does not evolve about "yes or no", "either you are with  
us, or you are against us", but about the greyscales in between.
  - that the tone of the debate remains productive. This can be difficult,  
if Detlef is really negative about this. However, Anton's authority as an  
IdeaChampion can help him to establish: "If you want to have some effect  
on the development process, then you'll have to communicate with me in a  
decent way."
  - that maybe the others are just uninformed, he will have to offer  
instant documentaition (yes, that is work).
  - that there can be hurt feelings on both sides. He will have to pull the  
emotional and the objective layers of the debate apart (hard work).

> eventually it gets removed anyways, now Anton is pissed.

If the communication was successful, then this should not happen. The  
feature might turn out to become something entirely different from what  
Anton and Berta imagined in the first place, but it should not be a matter  
of "yes or no".

So, you see, IdeaChampioning is hard work, but it is work that gets  
results. Provenly so: The AR interface and WikiDocs are there. They are  
not perfect, but they fulfill their purpose (oh, what I'd love someone to  
idea champion a better AR interface!).

> Or how about that: the developer changes the layout or the way the  
> interface works thinking it is an improvement. Some users think the  
> same, lots of users don't think so and want it to be changed back again,  
> or changed in another way. This has nothing to do with idea championing  
> at all. Of course good communication afterwards can help to change the  
> changes in a way that more people will be happy. But how about some good  
> communication *before* the work is done?

You hit the problem exactly on the spot. What the latest server release  
has lacked completely was communication about the percieved issues  
*during* the development process. And this goes to both parties, the dev  
(Keschte) and the complainers. Yes this also goes directly to you in  
person. I do not want to start blaming or looking for whose fault it was.  
This is just an obersvation of what went wrong. Keschte has complained  
that he did not _want_ to work alone on this release. Maybe we were just  
missing a middleman who could foster communication about the UI  
rearrangements while he was working on it.


Ad (b)

>> So instead of devising some complex and abstract QA scheme, I suggest  
>> you just get something concrete done. Go and pick up some issue that  
>> you feel is important and be its IdeaChampion and work together with a  
>> dev. The IntuitivePicardInterface is one that springs into my mind, but  
>> I am sure there are others.
>
> I don't think what I proposed is complex. And I thought it was quite  
> concrete.

By abstract I mean that it is *policy*. It says what devs and users  
*should* do.[2]
By concrete I mean to *do* some work on a very specific issue. If you feel  
you have something at hand that should be put to a vote, then do it. If  
you think you need feedback from newbs, then ask them.

In doing so you can create a policy. That is leading by example, or as I  
say: "Rules follow practice".

> I can't get something concrete done because I'm not a developer of MB  
> and probably never will be (this is partly a decision, partly my  
> abilities).

I think that is wrong. You could do all of what I have described above.  
The only reasons not to be able to do this are
  - someone feels they do not have the social competencies to foster  
communication like this [3].
  - someone is not prepared to put in the energy and percistency that is  
required to get an idea through to implementation.


>> And remember: Rules follow practice!
>> This means: If you actually *do* something and by doing so you  
>> implement some aspects of the scheme you devised, then this might  
>> become a rule. But not beforehand. We already broke our nose twice this  
>> way.
>
> You are the expert but I think you see this a bit too strict. ;)

Well, the StyleCouncil broke down twice because of some abstract policies  
that did not fit reality. And I certainly do not want the MB development  
process to ever break down. So forgive my strictness. I will persit with  
it.

I can only repeat: Pick up an idea or feature, push it through as *you*  
think it should work. When you have succeeded, come back and propose a  
policy based upon your concrete experience: Rules based upon practice. If  
this turns out to be an alternative/better/second way compared to  
IdeaChampioning, then I will be most happy with the result.

   DonRedman

----
[1] Selective sexism: Today devs are female, because, let's face it, dudes  
just don't know shit about coding. ;-)

[2] Just a note (if you feel attacked by this then I can understand it):  
After the server release you had written a post about accessibilty [4]. I  
was really pissed off from this, because I percieved it as an attempt of  
political policy making. In my eyes it was completely counterproductive.  
It took even more energy from both development and attemüts to undertand  
each other, and instead fostered arguments about abstract "goals of MB"  
between camps.
Working together with Steve and Keschte, maybe putting yourself in between  
both and reformulating arguments so that the otherone can pick them up,  
putting your won ideas into concrete mockups etc, *that* would have been  
helpful.

[3] Please do not take _this_ as a personal attack. It is not intended to  
be one. In fact it is directed at nobody in personal.

[4]  
<http://www.nabble.com/Accessibility-and-usability---goals-of-MB--tf1915563s2885.html#a5244218>

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

Nikki-12
On Tue, Aug 08, 2006 at 11:46:20AM +0200, Don Redman wrote:
> Some issue trackers give users the possibility to vote _for_ a ticket.  
> (but not against). This is a means of measuring the percieved importance  
> of an issue to the community. People can rate how annoying a bug is to  
> them. This works. I do not know if Trac supports this. It is really only  
> necessary in very large projects in which the devs loose the overview over  
> all the tickets.

That still doesn't really solve anything, the people who don't consider it
a bug or don't like the RFE are left out. If a dev fixes/implements it,
we've got exactly the same problem.
 
> However, with a *feature* you rarely know beforehand how it will look  
> like, in what it will help and how it will create new problems. So if a  
> dev writes a ticket for a new feature (and this _is_ a burden: She[1]  
> might just have a vague idea but is forced to write up a comprehensive  
> proposal) the cummunity might at best make a very uninformed decision  
> about a feature that would look completey different if it were developed.  
> If you have ever accompanied a development process, then you know that it  
> is _during_ that process that understanding of the issue emerges, that  
> concepts are overthrown and problems solved. Not beforehand.

The problem here is that features are getting thought up, developed and
added without any input from the community at all. By the time we first
find out about something, the developer has generally put a lot of work
into it.

There's often no "hey, I had this idea and made a mock up" or any chance
for people to be the person acting as a go-between for the users and the
dev. There's no place for the developer to collect opinions about the
feature. I'll take the collapsing releases feature from the last server
release as an example. It was thought up by Stefan, I presume, coded and
put on the server. I tested the server, came across it and found it very
irritating and had a couple of concerns. When I tried to explain my
concerns to Stefan, we didn't get anywhere and the result was that Stefan
was annoyed with me and I was annoyed with him (please notice that I'm
trying to avoid placing the blame on anyone here).

Instead of having one place to collect all concerns/problems/etc., people
are emailing the devs, bugging them on IRC, leaving bug reports on trac and
posting on the mailing lists. Surely *that* creates more work and stress
for the developers than, say, creating a thread on the mailing list and
pointing everyone to it if they start bringing the issue up elsewhere.

> IdeaChampioning is a concept that fosters communication _during_ the  
> development process. From your mail I gather that you have not understood  
> how it works (you are not to blame, as, ideed, it has not been documented).

I don't like the use of 'champion' because without looking it up in a
dictionary, the only meaning of the word that I'm sure about is "someone
who wins something", which isn't what's meant.

> No, it's not. It is not a one way process. IdeaChampioning also means to  
> champion your idea in the mailing lists in front of other _users_.
> You will put it forward when peoploe point ot an issue that you think  
> would be solved by the idea (this will help you to understand other user's  
> views of the problems, to find flwas in your idea or imagined  
> implementation).
> You will also have to 'shield' the dev from all the debates (and noise)  
> that take her attention from the thing only she can do: coding. You will  
> deal with the debates and give her condensed reports by mail, skype or  
> wiki pages (which will instantly document your feature).

What about when the *dev* has the idea? You've explained how the
"IdeaChampion" thing works for *users* who have the idea, but haven't
explained how we can improve the communication and process when the *dev*
has the idea. I think that's -- without trying to place the blame on anyone
-- where a lot of the problems in the last server release came from. Ideas
being implemented without anywhere for the users to give their opinions.
Thus, the only real feedback generated was from people wanting things
changed which must be tiring for the dev. With general threads about
features, there's more likely to be *general* feedback along the lines of
"I like it!" and not just complaints.
 
> I can only repeat: Pick up an idea or feature, push it through as *you*  
> think it should work. When you have succeeded, come back and propose a  
> policy based upon your concrete experience: Rules based upon practice. If  
> this turns out to be an alternative/better/second way compared to  
> IdeaChampioning, then I will be most happy with the result.

How can he suggest changes to the way developers' ideas are implemented
without being a developer?

--Nikki

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

keschte
I'm glad you try hard not to put the blame on anyone, the following
observations i will put forward are neither such an attempt. Please
keep that in mind :-)

> The problem here is that features are getting thought up, developed and
> added without any input from the community at all. By the time we first
> find out about something, the developer has generally put a lot of work
> into it.

i remember very well how things went during the last server release;
work was started, lukas and nikki participated a bit, and suddenly i
was alone. its not true at all that features are developed in MB
without user interaction -- IMO its quite the opposite. DonRedman is
right in his assessment of the situation -- if we can get the
community to involve themselves more, and stick to their commitment --
this is the part which requires communication skills and persistence
-- then we'll have a more satisfactory experience for all parties
involved. We do not need any more tools for that, those who care find
the ways to get in touch with the developers, and the tickets on trac
are publicly accessible, i think this is enough. Most users probably
don't even care, until they see it working the first time.

> put on the server. I tested the server, came across it and found it very
> irritating and had a couple of concerns. When I tried to explain my
> concerns to Stefan, we didn't get anywhere and the result was that Stefan
> was annoyed with me and I was annoyed with him (please notice that I'm
> trying to avoid placing the blame on anyone here).

Yes, this is the experienced vs. inexperienced users problem. The idea
behind the collapseable items is to try not showing all information at
once for the users who are confronted the first time with it. If
things would have happened differently, we might have figured out
before the release when the collapsing makes sense and when it
wouldn't. Most changes had been mentioned in the blog post, and the
testing was running for a fair amount of time.
Its exceptionally hard to find the balance when changing and
(hopefully) improving aspects on the site, because there are always
users who think that all was quite fine how it was before, but:
   Even the main site should be allowed some slack to try new things
out, but some people reacted to the new release like it was the end of
all things as we knew them. There will always be issues that need
fixing, or improvement, but the reactions to some things changed were
undue, IMHO. Picard for instance is still in a pre 1.0 state, and lots
of people use and like it, even if there are some issues that can be
annoying.

> How can he suggest changes to the way developers' ideas are implemented
> without being a developer?

DonRedman can answer this question much better than i could...

I hope i have hit the mark i attempted to hit when I started this
mail. After proof-reading it i feel its not too bad. Let the feedback
be heard :-)

--keschte

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

DonRedman
In reply to this post by Nikki-12
Just a meta-note: I feel we are close to getting divided in camps again,  
which is stupid, since we try to solve the same problem.

On Tue, 08 Aug 2006 13:53:35 +0200, Nikki wrote:

>> However, with a *feature* you rarely know beforehand how it will look
>> like, in what it will help and how it will create new problems. So if a
>> dev writes a ticket for a new feature (and this _is_ a burden: She[1]
>> might just have a vague idea but is forced to write up a comprehensive
>> proposal) the cummunity might at best make a very uninformed decision
>> about a feature that would look completey different if it were  
>> developed.
>> If you have ever accompanied a development process, then you know that  
>> it
>> is _during_ that process that understanding of the issue emerges, that
>> concepts are overthrown and problems solved. Not beforehand.
>
> The problem here is that features are getting thought up, developed and
> added without any input from the community at all. By the time we first
> find out about something, the developer has generally put a lot of work
> into it.

Yes, I agree very much that this is a problem. However I said (in the  
paragraph above), that according ot my own experience noone can explain a  
feature in detail before they have put work into it. Therefore any process  
which decides *beforehand* will not work. That is why I proposed a process  
in which input from and communication with the community are fostered  
*during* the work process.

> There's often no "hey, I had this idea and made a mock up" or any chance
> for people to be the person acting as a go-between for the users and the
> dev. There's no place for the developer to collect opinions about the
> feature. I'll take the collapsing releases feature from the last server
> release as an example.

I think we all agree that that the way development went with the last  
server release was not good. But mock-ups and gathering oppinons are  
common in MusicBrainz. See the IntuitivePicardInterface and perhaps even  
TaggerScript for current examples.

The point I want to get through is: Why reinvent the wheel? Look at cases  
of good development in MB's hisotry and pick up what is good. Don't devise  
a (IMHO overengineered) QA-process.

> It was thought up by Stefan, I presume, coded and
> put on the server. I tested the server, came across it and found it very
> irritating and had a couple of concerns. When I tried to explain my
> concerns to Stefan, we didn't get anywhere and the result was that Stefan
> was annoyed with me and I was annoyed with him (please notice that I'm
> trying to avoid placing the blame on anyone here).

If you put it this way, i would say: What went wrong was that the  
communication between some users and the dev was shitty. Therefore the  
right question would be: How can we enhance this communication. I believe  
"IdeaChampions" are one, but surely not the only way. I just do not  
believe that formalized processes (make a mock-up, put it to a vote) can  
replace real communication. At least not in a development process, for the  
reasons I already explained.


> I don't like the use of 'champion' because without looking it up in a
> dictionary, the only meaning of the word that I'm sure about is "someone
> who wins something", which isn't what's meant.

Robert invented the word. What else would you call that? A self-appointed  
feature coach? A communicaton manager for an idea (I _hate_ the term  
"manager")?

> What about when the *dev* has the idea? You've explained how the
> "IdeaChampion" thing works for *users* who have the idea, but haven't
> explained how we can improve the communication and process when the *dev*
> has the idea. I think that's -- without trying to place the blame on  
> anyone -- where a lot of the problems in the last server release came
> from. Ideas being implemented without anywhere for the users to give
> their opinions.

You gave the answer yourself: Offer the users a way to give their  
oppinions.
Now, since the dev is a volunteer you cannot give the users such an  
opportunity which raises barriers to the dev (i.e. descirbe it in detail  
and put it to a vote). The dev will simply stop coding for MB.
But you can go to the dev and tell her "Hey you are working on this  
project, and I feat the community is not involved enough, I would like to  
help you with that and be your 'secretary' towards the community". This is  
an offer of help. Now, you are a voluteer too, so you should have some  
interest in the featrue, too.

The point is that Keschte *has* asked for such assitance (not very  
explicitly, though) but the request went unheard or unanswered. Finally  
with the resturcturing of the MB server, it is likely that more of these  
dev-initialted changes will happen in the future. But I am sure that  
Keschte has learned to *insist* on early feedback the next time. And BTW  
AR was not my idea, I still championned it.

> With general threads about
> features, there's more likely to be *general* feedback along the lines of
> "I like it!" and not just complaints.

I did not get that. What are you proposing?

>> I can only repeat: Pick up an idea or feature, push it through as *you*
>> think it should work. When you have succeeded, come back and propose a
>> policy based upon your concrete experience: Rules based upon practice.  
>> If
>> this turns out to be an alternative/better/second way compared to
>> IdeaChampioning, then I will be most happy with the result.
>
> How can he suggest changes to the way developers' ideas are implemented
> without being a developer?

Am I a dev? I have coded a bit of OO Pascal in school, that's it.
IMO it actually _helps_ not to be a dev. Just pick a dev you go along with  
well and offer them help. The important thing is that you are not helping  
with the coding. You are helping with the *communication*:
  - by being the contact person for the community (keep noise off the dev's  
shoulders),
  - by translating aggressive feedback into positive feedback,
  - by documenting the evolving development process
  - by educating the community
  - by putting things to an informal (apache-style) vote on the mailing  
list, if you want,
etc. etc.

And there is another thing which you have already done in your mail: Point  
out to the things that went wrong the last time in a neutral, observing,  
and constructive way. This helps a lot to avoid the same mistakes the next  
time. Actually *that* would be worth being compiled on a wiki page right  
now. ThingsThatCanGoWrongInTheDevelopmentProcess, or the like. I am sure,  
there must be an even longer name. ;-)

   DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

Simon Reinhardt
In reply to this post by keschte
Stefan Kestenholz wrote:
> I'm glad you try hard not to put the blame on anyone, the following
> observations i will put forward are neither such an attempt. Please
> keep that in mind :-)

And I hope that you didn't think the initial post of this thread was criticism of the way you work. Because I didn't intend to put blame on anyone either. ;) I just think the problem lays in the current processes which are noone's fault.

>> How can he suggest changes to the way developers' ideas are implemented
>> without being a developer?
>
> DonRedman can answer this question much better than i could...

And from how I understood him so far I guess I know how he would answer it:

If everything would have gone the "right" way (or: a better way), then you wouldn't have worked on the last server release alone in the first place but together with a handful of people from the community and then we would have had good communication during the development process, opinions from different people, a more satisfactory end result and less complaints afterwards.

This is an ideal we can try to reach but it still doesn't take one fact into account: as I said, the developers are the most inventive force in MB. And while the developer can always have productive talk with others about certain details (like we had last evening about the edit data display), that doesn't mean the developer will only do work when people ask for it. Instead the developer will steadily produce output to improve small details of the server, partly just small fixes and Feinschliff (missing a translation for it), partly adding new features. Yes, we as the community can try to be less lazy and work together with the developer on distinct parts (I will try to!), but we are surely not supposed to be the developer's nanny and read through all changelogs (which would be silly anyways). So yes, trac is open but it's too much data to be observed by everyone. And therefore of course it happens that improvements and new features land on the test server without anyone but
the developer being involved - and then eventually they land on the main server without anyone being involved because noone noticed it on test. That's a fact which IdeaChamponing still can't change. This doesn't necessarily have to be bad (it means progress in the development) nor can it be seen as anyones fault but you may understand that as a community member one sometimes feels a bit helpless about this because upon noticing such a change (where noone but the developer was involved yet) and in case you don't like it, you somehow have to try to start communication about it - *afterwards*.

A very simple example for that: Nikki talked about the collapsing of the releases. There is a little JavaScript feature that, when you collapsed the release, after leaving the mouse over the release header for a short while, will uncollapse it again. Given that I don't like that (1. because when I closed it I don't want it to uncollapse again unless I click the arrow again, 2. it makes copying the release title very hard), how should I proceed?
* I could enter a ticket for removing this feature. I think this is the worst possible solution.
* I could talk to Stefan about it, explain my reasons to him and he could say something like "Ok, I don't feel too strong about that, let's remove it" or "No, I want it to stay for that and that reason" or "Ok, I understand your concerns, but for that and that reason I think we still need it, though we could alter it in that and that way". I'm not sure if there's anything to alter about this apart from just removing it again, but there could possibly be. ;)
* What should I do though when I want to know how others feel about it? Note that this can come after talking to Stefan. Either because he said "no, it should stay for that and that reason" and I want to know how many others also don't like it, or because he said "yes, let's remove it" and I want to make sure, noone will miss it afterwards, or because he said "let's alter it in that and that way" and I want to find out if others think that'll be better (ok, this is what the test server is for). Since there's no ticket about this yet and no thread, there's no audience. So I have to create one. I could write an email (to mb-users?) titled "Issues with the JavaScript feature for expanding the release after a mouseover". It would feel a bit silly but perhaps it would work. But I think if everyone would do that with every concern they have, mb-users would be swamped. So I just don't know if that's a good idea.

Simon (Shepard)

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts
Reply | Threaded
Open this post in threaded view
|

Re: Feature "ratification" process

Simon Reinhardt
In reply to this post by DonRedman
Don Redman wrote:
> Just a meta-note: I feel we are close to getting divided in camps again,
> which is stupid, since we try to solve the same problem.

I don't feel that at all, IMHO we are having objective and productive talk at the moment, better than ever. :)

If Nikki and I share the same opinions then it's either because we are actually a bit similar minded or because we are talking a lot - so when we express our opinions in public for the first time, we very often already had talked about the topic and exchanged our ideas - so of course what we say can sound very coherent.

Simon (Shepard)

_______________________________________________
Musicbrainz-experts mailing list
[hidden email]
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-experts