Re: GNOME Enhancement Procedure

[Bill Haneman <Bill Haneman Sun COM>]

Havoc said:

>
>My take on that would be that if there's an argument over whether it
>needs the procedure, it probably needs the procedure.

<grin>


>The idea is simply to have the RFP author pick a small group they
>think would be representative. 
[...]

This is potentially controversial, I am not sure the RFP author should 
do this.  I am not sure that your suggestion below is the best solution 
to the 'bias' issue, it forces people to take antagonistic positions in 
the eary stages if they are concerned, which is not good for morale.  
Nobody wants to be the 'bad guy' who got the Board involved early on.

>If someone else thinks that group is totally biased, or thinks they
>really should be on it, they first ask the RFP owner to add whoever
>they think should be added, if the RFP owner agrees then OK, otherwise
>the board takes some time and makes a decision. If the board thinks a
>group is good enough then they are probably at least a reasonable
>group, though we won't always have the ultra-super-optimal group
>that's a fact of life.

Maciej suggested:

>> My own proposal would be to have one or more standing architecture
>> review committees to consider issues with global architecture
>> implications. 

Owen said:

>I'd have to hear more details. I guess on first impression, this seems
>more bureaucratic to me - after all, it establishes a bureau. ;-) I
>don't think a small committee trying to establish technical direction
>would have much luck; they'd be overworked, and everyone not on the
>committee would be resentful.

I think the goal is for everyone to be able to comment, and the "ARC" 
sifts the comments and attempts consensus (or votes).  This reduces the 
burden on the ARC since it is responsible only for reviewing the 
comments of interested parties (perhaps including themselves) and not 
the burden of researching all the details on their own.  If one takes a 
"no consensus" vote as a message to revise, then it might seem less 
contentious (than if it's an "outright rejection"), and the ARC could 
apply appropriate standards of conservatism/lack thereof to various 
Gnome revs depending on the schedule and major/minor revision number 
(i.e. "coming up on beta, too risky" or "target new major rev, full 
speed ahead").

This helps a little with the situation where the ARC can't agree 
internally on some issue, the burden of "convincing" them one way or 
another falls to outside parties.

all the best,

-Bill

>
>Havoc
>
>
>_______________________________________________
>gnome-hackers mailing list
>gnome-hackers gnome org
>http://mail.gnome.org/mailman/listinfo/gnome-hackers
>
>

------
Bill Haneman x19279
Gnome Accessibility / Batik SVG Toolkit
Sun Microsystems Ireland