[mb-style] State of the Style Secretary

[DonRedman]

Yesterday I have answered very calmly and objectively to all mails here.  
However, I realise that I am still angry.

I have been working as a secretary. My job is to make people follow  
existing rules. I DID NOT MAKE UP THESE RULES. They were concieved by  
Tarragon, Alex Dupuy and mostyle by you. You took part in all discussions  
that have led to things like Tarragon's checklist.

I only documented them on the wiki (mostly on StyleCouncil and  
ChecklistForStyleChanges) and pushed people to follow them.

So if you are not happy with the rules, PLEASE do not bug the secretary.  
If you think that the current rules are no good to get things done, you  
are very welcome to start a discussion about changing them. I will take  
part in that discussion as anybody will and Robert will have the last word.

But do not piss me off with hints that entering tickets does not make  
style issues get approved faster ;-) ;-) ha ha, or with stuff like this  
<http://chatlogs.musicbrainz.org/2006/2006-02/2006-02-05.html#T15-59-44>.  
I did not htink this was funny at all and, yes, I read backscrolls.

I am working my ass of here and I could bear with a little more sympathy.

Thanks for listening. This is all you will her from me today. I suppose I  
will have calmed down by tomorrow.

   DonRedman


--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Don Redman wrote:
> or with stuff like this
> <http://chatlogs.musicbrainz.org/2006/2006-02/2006-02-05.html#T15-59-44>.
> I did not htink this was funny at all and, yes, I read backscrolls.

I'm sorry, but this was just the e-mail that I had opened at the moment (because
I wanted to reply to it) and the whole discussion was about Thunderbird HTML
e-mail editor, not about style issues.

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

[Simon Reinhardt]

Don Redman wrote:
> But do not piss me off with hints that entering tickets does not make
> style issues get approved faster ;-) ;-)

That was in no way criticism in your direction. It was no criticism of
the ticket system. I said: the ticket system is good to not forget about
style issues and it is! I like it. But it does not help with the problem
that you have to bring everything to the mailing list over and over
again or against people discussing issues down or people just not
noticing problems - and I did not talk about you when I said that. You
do a fine job. And I actually don't think there is a better way of
handling it - so it was just like.. a sigh I let out when I said this.

> ha ha, or with stuff like this
> <http://chatlogs.musicbrainz.org/2006/2006-02/2006-02-05.html#T15-59-44>.
> I did not htink this was funny at all and, yes, I read backscrolls.

I think you have to calm down and really read what we were talking about
there. We were not talking about your mail but about me having problems
with my mail client - so we took screenshots of a random mail (this one
was one of the latest at this point and good to show the problem because
of a lot of quotation marks) to compare.

Simon (Shepard)

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

[g0llum]

> But do not piss me off with hints that entering tickets does
> not make style issues get approved faster ;-) ;-) ha ha, or
> with stuff like this  

I think, another chapter of MisunderstandingDonRedman, or more generally
MisunderstandingOtherMusicBrainerz needs to be written. MB is such a
delicate social environment, and things said can be interpreted wrongly, or
even as personal attacks very easily, if it is communicated by means of
big-latency communication like e-mail. (I had a similar situation @work
lately, and it was only resolved after talking to the people involved
directly) The thing i learnt from that experience is that if you are angry
about something, or if you feel someone does not treat you with respect, do
not use e-mail as a means of communication, but seek contact directly. We
have the IRC which works very good IMO as a direct communication channel, so
why not try to resolve things there?

Since we have chatlogs available, i don't see why everything "official"
needs to be communicated in the mailing lists. It should be interesting to
see if we could meet in IRC to resolve style issues, discuss the questions
and come up with a decision in a matter of minutes. If something comes up
which needs to be investigated, you would postpone the decision to another
"session", where everyone would meet up again and present the new
findings/arguments to the case (have i been watching too many "TV Judge
Programs"?) ;)

Such a decision/dicussion would be no less official if it were done on the
mailing list, but would achieve results in a 100x faster way, and thus the
potential for frustration on any side would be much smaller.

What do you think?
g0llum


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

[DonRedman]

Ok, I have calmed down a bit. Sorry for the outbreak. I just felt vey  
frustrated. My appointed job is to make sure the process of fixing style  
issues follows a certain procedure. But if this procedure is fucked up,  
then this job is hell for both me and you.

The only possible conclusion to me is: The rules don't work. It is not  
even worth to try to play along them. We need a new practice and we need  
it *now*.

Just to show you how fucked up the current practice is (and please note  
that I am very calm and am not accusing anybody now) observe this new  
ticket that Fuchs entered: <http://test.musicbrainz.org/trac/ticket/1053>.

>>
  As the result of the discussion on the
  [http://lists.musicbrainz.org/pipermail/musicbrainz-
  users/2006-January/022525.html mailinglist] I added a proposal that
  incorporated the old [http://wiki.musicbrainz.org/UntitledBootlegStyle
  UntitledBootlegStyle] with the new ideas.

  This proposal is explained in detail at:
  [http://wiki.musicbrainz.org/LiveBootlegStyle LiveBootlegStyle]. Checklist
  question are already answered, documentation seems complete. ;-)
<<

The last sentence and the emoticon are of course directed towards the  
secretary. I don't blame you for this. But it should be very plain that  
this will not work. The secretary cannot replace open debate on mb-style.  
He would become the bottleneck of the whole process.

I do not know how exactly it happened, but I have become the one who has  
to decide whether a style issue passes or not. I never wanted to do this,  
and I was not appointed to do it. If anyone can decide, then Robert. But  
Robert has so much to do that he will be an even thinner bottleneck  
(anyone who has seen us two in person, will, of course, object ;-) ).

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.

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.

I am prepared to put a lot of work into this but please do not lean back  
and watch Don struggle. Please, if I start to do things in a certain way,  
do not assume that now I (or any other secretary) will have to do them  
until the end of time. Instead, if it has worked, do it yourself next  
time. Please tread in my footsteps if it makes sense and take new paths if  
it does not.

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!

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

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

Consensus should still be the thing that makes a style change pass.  
Remember that I cannot create consensus. I can only observe that there is  
consensus or not. The OK from the secretary is there to prevent that  
someone claims that there is consensus just because people have ceased to  
object out of fatigue. That's all.

So if you seek out consensus about a style issue, do so on mb-style and  
address everybody here.

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  
here.

   DonRedman



--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Beth-2]

   -----Original Message-----
   From: musicbrainz-style-bounces@...
   [mailto:musicbrainz-style-bounces@...] On Behalf
   Of Don Redman
   Sent: Tuesday, February 07, 2006 3:57 PM
   To: MusicBrainz style discussion
   Subject: Re: [mb-style] State of the Style Secretary
   
[Snip]
   
   What I wanted to do was to observe the discussion and
   summarize consensus.  

[Beth] Which you do very well at. Often times I have sat back and said. Wow,
that was a muddy mess clarified very nicely!
[/beth]

   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.
   
[Beth] I think there is some confusion from the end user as to how the
checklist is to be summarized. Some people simply don't know the effect on
the community, or the amount of programming needed. They are not
programmers, or they haven't thought about the impact on the community.
Therefore it's a very open and diffictul to interpret thing for your
"novice" user to truly forge forth and say "this has said impact".
[/beth]

   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.
   
   I am prepared to put a lot of work into this but please do
   not lean back and watch Don struggle. Please, if I start to
   do things in a certain way, do not assume that now I (or any
   other secretary) will have to do them until the end of time.
   Instead, if it has worked, do it yourself next time. Please
   tread in my footsteps if it makes sense and take new paths
   if it does not.
   
   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!
   
   I like Stefan's proposal of quick chat sessions, especially
   if combined with editing on test.

[Beth] The one problem I see with the chat session is the conflict of time
schedules for people in differing countries. I don't believe I mentioned
that before due to lack of cultural knowledge of the main style people. In
fact, I may be stepping on toes by responding here. Often times I've felt I
shouldn't comment on style issues, due to being new. So, if that's the
case.. By all means, just ignore the letter and maybe drop me a personal
note to "butt out". :D
[/beth]
   
   I think the checklist still is helpful, but only if it
   guides public debate on mb-style.
   
   Consensus should still be the thing that makes a style change pass.  
   Remember that I cannot create consensus. I can only observe
   that there is consensus or not. The OK from the secretary is
   there to prevent that someone claims that there is consensus
   just because people have ceased to object out of fatigue. That's all.
   
   So if you seek out consensus about a style issue, do so on
   mb-style and address everybody here.
   
   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 here.
   
      DonRedman
   
   
   
   --
   Words that are written in CamelCase refer to WikiPages:
   Visit http://wiki.musicbrainz.org/ the best MusicBrainz
   documentation around! :-)
   _______________________________________________
   Musicbrainz-style mailing list
   Musicbrainz-style@...
   http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
   

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

[Fuchs]

On 2/7/06, Don Redman <donredman@...> wrote:

> >>
>   As the result of the discussion on the
>   [http://lists.musicbrainz.org/pipermail/musicbrainz-
>   users/2006-January/022525.html mailinglist] I added a proposal that
>   incorporated the old [http://wiki.musicbrainz.org/UntitledBootlegStyle
>   UntitledBootlegStyle] with the new ideas.
>
>   This proposal is explained in detail at:
>   [http://wiki.musicbrainz.org/LiveBootlegStyle LiveBootlegStyle]. Checklist
>   question are already answered, documentation seems complete. ;-)
> <<
>
> The last sentence and the emoticon are of course directed towards the
> secretary. I don't blame you for this. But it should be very plain that
> this will not work. The secretary cannot replace open debate on mb-style.
> He would become the bottleneck of the whole process.

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

[Jan van Thiel-2]

OT:

On 2/8/06, Björn Krombholz <fox.box@...> wrote:

> 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 )
> ...

Well, a is the only correct solution :) Or there are not correct
solutions if you define 'from 1 to 10' in another way ;)

--
Jan van Thiel

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

[Robert Kaye]

On Feb 7, 2006, at 2:57 PM, Don Redman wrote:

> (anyone who has seen us two in person, will, of course, object ;-) ).

That bitch just called me fat!!

(at least your parens are balanced :-) )

> --

--ruaok         Somewhere in Texas a village is *still* missing its
idiot.

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net

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

[DonRedman]

On Wed, 08 Feb 2006 01:38:19 +0100, Beth wrote:

> [Beth] I think there is some confusion from the end user as to how the
> checklist is to be summarized. Some people simply don't know the effect  
> on
> the community, or the amount of programming needed. They are not
> programmers, or they haven't thought about the impact on the community.
> Therefore it's a very open and diffictul to interpret thing for your
> "novice" user to truly forge forth and say "this has said impact".
> [/beth]

It is difficult for everyone. Even the combined knowledge and brainpower  
of all experts here on mb-style could not avoid the SG5Disaster, we simply  
forgot that albums would become VA and what consequences this had.

> [Beth] I don't believe I mentioned
> that before due to lack of cultural knowledge of the main style people.  
> In
> fact, I may be stepping on toes by responding here. Often times I've  
> felt I
> shouldn't comment on style issues, due to being new. So, if that's the
> case.. By all means, just ignore the letter and maybe drop me a personal
> note to "butt out". :D
> [/beth]

Not at all! I think the StyleCouncil (whatever this will be) needs to open  
up and be less elite. So join in, and please step on our toes. You will of  
course recieve comments every once in a while, but else should you learn  
ablut the culture?

   DonRedman

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[DonRedman]

On Wed, 08 Feb 2006 11:08:33 +0100, Robert Kaye wrote:

>
> On Feb 7, 2006, at 2:57 PM, Don Redman wrote:
>
>> (anyone who has seen us two in person, will, of course, object ;-) ).
>
> That bitch just called me fat!!

Or myself skinny.

   DonRedman

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[DonRedman]

On Wed, 08 Feb 2006 02:31:06 +0100, Björn Krombholz wrote:

> On 2/7/06, Don Redman <donredman@...> wrote:
>
>> The last sentence and the emoticon are of course directed towards the
>> secretary. I don't blame you for this. But it should be very plain that
>> this will not work. The secretary cannot replace open debate on  
>> mb-style.
>> He would become the bottleneck of the whole process.
>
> Nope, you completely misunderstood me. :)

I do not think so. Please note again, that I am in no way accusing you. I  
am just observing a cultural practice that has emerged.

First, you will note that the ticket was assigned to me. Why? Obviously  
because the issuer believed that in the correct process, I will have to do  
something with it. What? To decide to let it pass.
That is what I mean, The things all land on my desk and I become the  
bottleneck of the process.

Second, below you argue that I should decide upon style issues. I will not  
do that. That is not my job. If anyone decides, then Robert.
This point is NOT open to debate. I will not decide upon style issues.  
Period. Either the community reaches consensus or Robert makes a decision.  
I will do my best to help the community to reach consensus, and I will  
officially 'declare' consensus when it has been reached. Furthermore there  
were rules for a valid consensus (the checklist) and I used to push people  
to follow these rules. I do not think they are that good anymore.

I have once observed dissensus and called upon Robert. I have been called  
back. The argument was that I had reacted too quickly and that the issue  
had not been discussed enough.

>> 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.

This is exactly the practice I want to break with. I do not decide.

> 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).

Yes that is a good description. The additional difficulty is that the  
"thing in the middle" are text and people, not code and computers, they  
are far less predictable.

>> 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.

As you explained very well, it will never happen that different  
programmers achieve consensus on the best way to print the nubers from 1  
to 10. But they should be able to achieve consensus whether a specific  
solution works well or not.

This is what we need for style issues. The common open source tools to  
achieve this are rapid prototyping, beta testing, and peer review. It is  
not a central authority that takes full responsibility for the quality.

However this only deals with (2) the "thing in the middle". The problem is  
that we discuss (1) the desired 'output' to death. That is the problem  
with the current debate on arrangement. Again here the common practices of  
open source projects are input from users and benevolent dictatorial  
decisions. They do not use marketing departments nor CEOs.

mb-style has turned into a kind of marketing department, in which experts  
discuss the possible needs and actions of users. And I had nearly turned  
into a kind of CEO.


Instead of discussing _this_ to death, I will try to apply open source  
logics to the arrangement style issue. I will do this slowly (I really  
have to learn for my exam) and I will not tackle any other issue before  
this is done. So please be patient with me.

   DonRedman

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

[Beth-2]

   >> [Beth] I don't believe I mentioned
   >> that before due to lack of cultural knowledge of the main
   style people.  
   >> In
   >> fact, I may be stepping on toes by responding here. Often
   times I've
   >> felt I shouldn't comment on style issues, due to being new. So, if
   >> that's the case.. By all means, just ignore the letter and
   maybe drop
   >> me a personal note to "butt out". :D [/beth]
>[Don Redman]You will of course recieve comments every
 >  once in a while, but else should you learn ablut the culture?
>[/Dob Redman]

[Beth]Ack! My bad choice of style/linguistics, that was sort of run
together. The cultural (I meant countries lived in) aspect was in regards of
the chat times and getting everyone together. I don't know where everyone is
from, and time zones can be very difficult to mesh together for meeting in
live chat. [/beth]
   
>>[original comment from Beth] The one problem I see with the chat session
is the conflict of time
>>schedules for people in differing countries. I don't believe I mentioned
that before due to lack
>>of cultural knowledge of the main style people.

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

[Robert Kaye]

On Feb 7, 2006, at 5:31 PM, Björn Krombholz wrote:

> 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).

Very true -- however, when I last spoke with Don, he expressed his  
wishes more like: "I wish we could try out possible style issue  
solutions the way we test bug fixes on test.mb.org". That is not to  
say that we should use the bug process for style issues, but that  
style issues should be rolled out on a test basis to let people see  
the actual impact of the proposed solution. And that makes sense, I  
think.

And now some more general thoughts:

1. We're dealing with a lot of pent up frustrations from previous SC/
Style dude systems that weren't working so well anymore. So, I think  
part of our frustrations towards the Secretary stem from that and  
once we work through those and show that the new process is working,  
we'll find a smooth rhythm for working out style issues. Everyone  
please be a patient for a little longer.

2. As I mentioned above, rolling out style issues and bugs on test  
should be done more frequently. Luks already has root on test.mb.org  
and I would be willing to give that to fuchs as well and instruct  
both on how to update the staging server. Luks & Fuchs: you wanna?

3. As far as the process for style changes is concerned: Does it  
really matter in what forum this happens in? What if a style  
discussion starts in mod notes, migrates to a wiki page and then gets  
formally presented to the secretary? As long as basic requirements  
for defining the problem, outlining the pros and cons and perhaps  
illustrating how the fix would look, does it matter where it is done?  
Perhaps we should define WHAT should be part of a style proposal and  
now HOW a style proposal should look.

4. Forming consensus: I don't think we've been forming consensus for  
a long time and as Fuchs points out -- this is not really possible  
with our size. We're now playing a game of politics: You can't make  
everyone happy. Every action will leave some happy people, some  
pissed off people and lots in between. When we talk about 'forming  
consensus' I think the reality of it looks a lot more like a  
utilitarian approach: How can we make the most number of people  
happy? I'm not really suggesting we changed anything -- I think this  
is mostly a matter of perception and using the right terminology.

Just some thoughts on the current discussions, which I think are very  
exciting. We have difficult social systems to develop and we have a  
lot of intelligent people here who are contributing towards that  
goal. I think this is very exciting -- before the net you would  
largely see these things in action when some government was forming  
-- a rare occurrence. To be part of a social group that constantly  
reinvents itself as the demands placed on it change, is really cool.  
I have faith that in due time we will establish systems that will  
work for the long haul.

--

--ruaok      Somewhere in Texas a village is *still* missing its idiot.

Robert Kaye     --     rob@...     --    http://mayhem-chaos.net



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

[Fuchs]

On 2/8/06, Don Redman <donredman@...> wrote:

Only a short reply to clarify thoughts and ideas.

> >> The last sentence and the emoticon are of course directed towards the
> >> secretary. I don't blame you for this. But it should be very plain that
> >> this will not work. The secretary cannot replace open debate on
> >> mb-style.
> >> He would become the bottleneck of the whole process.
> > Nope, you completely misunderstood me. :)
>
> I do not think so. Please note again, that I am in no way accusing you. I
> am just observing a cultural practice that has emerged.

Hehe. ;) I can assure you, I don't take discussions personally, as
long as they stick to factual arguments. ;)

> First, you will note that the ticket was assigned to me. Why?

Maybe I should answer this, because that's been a point I Was not sure
about and one we should explain somewhere. As I noted, I thought of
the proposal as being complete, meaning I did everything I could, it
is just waiting for a final decision. I thought, that this was in your
responsibility.

The second reason was a practical one and actually groups 2 arguments.
I believed it would be easier to find nearly complete proposals if
they were assigned to you and second, if I don't know a proper
assignee, I often assign bugs to the person that's seems to be the
best choice to me (this is not related to musicbrainz, but a more
general practice I follow). This assignee does at least know what to
do with the report and reassigns it to the right person or accepts it.

The assignee can change over time. In the thinking phase it's likely
that the proposer assigns it to herself, or the one who feels
responsible for evaluating solutions and analyzing the problem takes
it over.

After this part is done, there's nothing more this person can do, so
the assignment is dropped and put to someone else who can complete the
unfinished steps in the work flow.



#Fuchs

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

[DonRedman]

On Mon, 13 Feb 2006 17:54:04 +0100, Björn Krombholz wrote:

> On 2/8/06, Don Redman <donredman@...> wrote:

>> First, you will note that the ticket was assigned to me. Why?
>
> Maybe I should answer this, because that's been a point I Was not sure
> about and one we should explain somewhere. As I noted, I thought of
> the proposal as being complete, meaning I did everything I could, it
> is just waiting for a final decision. I thought, that this was in your
> responsibility.

As I said this practice makes the Secretary the bottleneck of all style  
development. Or in other words: This practice had emerged very quickly, it  
has put a great strain on me (suddenly I was responsible for all  
StyleIssues after most work on them had been done), and this made me write  
the mail that started this thread.

I do now agree with you that complete consensus (esp. consensus about the  
result _and_ the best way to achieve it) is too rare a phenomenon. It is  
therefore too tough as a criterion to make a style change pass.

The 'request for veto' seems to work a bit. (I don't like the term but the  
practice is good)

First Example: Arrangement Sub-Types

Lukas' arrangement request got a couple of comments. They were not very  
concrete and dealt with both the intended result and the way of achieving  
it. At first this was quite frustrating to Lukas, but then Lukas and me  
have worked on a concrete version of his proposal on test and incorporated  
some of these criticisms into it.

I will ask for a second round of feedback on mb-users (I want to write up  
some directions on BetaEditing on the wiki before, and have not come to it  
yet due to lack of time, sorry). Then the 'request for veto' on mb-style  
could be more emphatic: "Does anybody here feel this change is so bad that  
she/he is willing to stand in its way and veto it?".

Anybody could do this. It would not be the secretary's burden to give an  
ok, but the public's job. Giving such a veto should not be as easy as  
sending "-1" to mb-style. If the veto is disputed, I will ask Robert to  
make a decision.

The big difference is, that Lukas and me have been working on a concrete  
enhancement on test. Incorporating part of the cirticism is far less  
frustrating than arguing against them. We have not incorporated  
everything, but we have spent quite an amount of _productive_ work on the  
feature. If someone would want to veto it, her/his agruments should have a  
weight that exceeds the productive and adaptive work of Lukas and me.


Second Example: SortNameStyle

Zout has requested to make SortNameStyle official. The replies to this  
request were _concrete_. It seems to be consensus that the style should be  
simplified. The reply was not:
Secretray (grave official voice): "No, no, no. You need to fill out this  
form first."


I like this new practice. I do not want to set up rules yet, but I will  
try do describe it in an abstract way. Maybe this can lead to rules later:

Someone wants a StyleIssue fixed. She[1] is prepared to put in some work  
to get things right.
So she implements a solution on test or the wiki, proposes it to the  
StyleMailingList, and requests _comments_. Ideally people join into a  
productive debate about how to enhance the change. People might also bring  
forth arguments against this change. The proposer can change her proposal  
to meet these arguments as much as _she_ wants.

In a final stage she might want to call for BetaEdtiting on the  
UsersMailingList. This only applies to big or highly disputed changes.  
Here the practice of using (testing) the solution should show whether it  
is good.

When she thinks she has done enough, she sends a 'request for veto' to the  
StyleMailingList. A veto must match the amount of productive work she has  
put into the change. Therefore a veto is only likely to occur if someone  
sees a severe problem, or if the proposer has worked on her proposal only  
sluggishly.

If there really is dispute, the point of dissensus should be really clear  
by now. It will probably be a general/philosophical point. Robert should  
be able to make a well informed decision that everyone will have to accept.


Now I am not saying this is the perfect way to do things. It is just a  
generalization of what I have observed in the last days. My hope is that  
something vaguely like this might work for the StyleCouncil on the long  
run.

And finally turning back to the issue of assigning tickets: It would have  
to be assigned to the person who does the concrete work on the change. Not  
to the secretary nor to the elder.

   DonRedman

----
[1] Today our example person is female. That is balancing sexism :-)

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)
_______________________________________________
Musicbrainz-style mailing list
Musicbrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style