Re: [mb-style] State of the Style Secretary

On 2/7/06, Don Redman <donredman@...> wrote:
Nope, you completely misunderstood me. :) (Well, my emoticons normally
don't have a meaning, and I know, I'm using them far more often then
necessary. But that's a result of the years in the IRC).

In this case, it _had_ a meaning (contrary to your assumption). First,
I just wanted to show, that it's actually not much work to act
according to the current guide on proposing new guidelines. Overall it
took 30 (maybe a few more minutes) to summarize, write the wiki-page,
answer the checklist questions and submit the ticket (of course
spreaded over a few days).

And second, "documentation seems complete" was "documentation is
complete", which was even more an overestimation of what can be
achieved. I think you'd agree with "documentation can never complete"
aka "you can always improve it".

> What I wanted to do was to observe the discussion and summarize consensus.
> The Checklist was intended as a guide for the community. Instead the
> checklist has suffocated discussions, people go through the chelist by
> themselves, present it to me and I have to make a decision. This is
> bullshit. It does not work.

I don't agree. Of course someone has to write the answers to the
checklist. The answers should represent a summary of the discussion
about the issue.  For more controversial proposals (the example above
was an easy shot, because nobody really objected to the proposal) the
answers would include the pros and contras to every aspect of the
checklist.

This summary should it make easy to decide for you, if a change is
worth the effort and possible breakage or not.

> So what to do now? I reall do not know. My great hope is that we can
> invent a new procedure for style issues that works more along the lines of
> fixing bugs and less along those of discussing things to death or a
> controlling secretary.

You can't compare those two in general. A normal bug fix means
repairing a broken thing, that was supposed to be implemented
correctly in the first place.

A style issue is like adding new features, and that's far more
complicated and even more as the style guideline is part of
MusicBrainz interface between the database and the user.

A bug is an objective fact, where with a known input the expected
output is different from the real output. So you know what you have
and you know what you want, something in between is broken. It is
fixed, when expected and real output become identical.

A style issue is a process that involves (1) finding the expected
output (how should the data look like, so it is easy to handle in all
affected aspects?) _and_ (2) implementing the "thing in the middle" in
a way, that its output matches the results of phase (1).

Both steps are problematic when too many people are involved. Another
analogy to the programming: The task is to print the numbers from 1 to
10. Let people discuss the best solution, you would get proposals
like:
a) print "1 2 3 4 5 6 7 8 9 10"
[argument: it's the fastest way to do it!]
b) for ( i = 0 to 10) { print i }
[argument: it's more flexible!]
c) i=0; do { print i; i = i + 1 } until ( i > 10 )
...

People could discuss for weeks about the best solution. It's be hell
on earth if anybody worked this way. :)

We need brainstorming on the list, the wiki, where ever. We need to
stop thinking, we can reach consensus (take the EU or the UNO as an
example, it doesn't work when too many parties are involved). The so
called secretary should do what his/her title implies: guide and
decide.

When he thinks there was enough brainstorming, then he decides to get
on to the next step: summarizing and evaluating the arguments. He
picks a few people who should do this job. If the community has
anything to add, they go to this group of people and don't bother the
style chief.

Finally there will be results, including pros and contras, benefits
and breakages. With this summary it should then be easy for the
secretary to do the final cut and decide. If he has questions, they go
back to the group.

If the decision was a "yes, we'll do it", then the implementation (2)
has to be done. Ideally this is done by only one person, as long as
it's not a major change that involves many different issues. Once the
implementation is done (in most cases it means just cleaning up some
wiki pages, that have been created in the thinking/summarizing phase
== completing the docs).

The final OK from the secretary makes the issue officially resolved.

For minor cosmetic issues, this could be simplified into just one step.

> I think it still makes sense to tackle one style issue at a time. I think
> we should start with Luks' arrangement proposal (or rather close it). And
> here already, I have to point out that I do not claim to be the one who
> decides which comes next. Make your proposals and discuss this!

Just decide on the priority of an issue (with the help of trac), and
then do a classical FIFO queue processing.

> I like Stefan's proposal of quick chat sessions, especially if combined
> with editing on test.

I think only few people will do the test editing, because it's work
that's not funny and lost in the end.

> I think the checklist still is helpful, but only if it guides public
> debate on mb-style.

see above.

> Consensus should still be the thing that makes a style change pass.

No. Take the nasty EU thing. As I explained to you in IRC, I want a
decision and that I can live with any decision. But I won't change my
opinion and have no problem to discuss this 'til the end of days.
Consensus is such a rare thing that we should stop waisting time on
trying to achieve it.

Most people will like the decision based on common sense and the
opinion of a majority, some will not, so what?

> I think the tickets on trac are helpful to tackle style issues one after
> the other in order of importance, but they can never replace lively debate

Yes, and every debate needs a deadline, otherwise it would be
pointless, because you can't go on.


#Fuchs

_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style