Re: GNOME Enhancement Procedure

[Havoc Pennington <hp redhat com>]

Maciej Stachowiak <mjs noisehavoc org> writes: 
> First, even though I think we do need some kind of more formal
> process, this one sounds a bit too bureaucratic for my tastes what
> with all the rules and regulations.

Well, your other two criticisms are about how two things aren't
sufficiently spelled out! So I find this first criticism kind of hard
to reconcile with #2 and #3. Clarifying how it works in advance ==
rules. The purpose of written rules is to avoid people making up
convenient-to-them rules as they go along.

As it says at the top of the proposal, it's really quite simple, and
the bulk of the proposal is trying to anticipate problems and specify
how they should be addressed, BEFORE people have a stake in particular
issues.

At the same time, several of the suggestions for simplification people
have made help to reemphasize that the process is above all a
common-sense thing and a technical working group, rather than a "let's
vote our opinion" committee - i.e. the responsible maintainers are
supposed to figure out the best answer together, possibly changing
their mind during the RFP process. I want to edit the document to
better reflect this.

> Second, how do you determine whether a proposed change needs to go
> through this process? There are certainly gray areas. I have a feeling
> there might be a lot of fights over whether a needed change needs to
> go through this procedure, and people making changes without following
> the procedure.

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

I don't see any way to take common sense and judgment out of the
process, that means gray areas. But even if there are some arguments
at the boundaries, most important things people care about are clearly
in the Needs Public Discussion zone. If a big flamewar busts out over
a nontrivial change then the topic blatantly must go the RFP route; no
excuses.

> Third, how do you determine who the "Responsible Maintainers" are? For
> example, in the recent bonobo-conf situation, one could argue that (a)
> only libgnome and bonobo-conf are relevant, since the question was one
> of using bonobo-conf in libgnome; (b) one could argue that gconf is
> also affected since this could lead to a move to deprecate it in the
> platform; (c) one could argue that bonobo is affected since ; (d) one
> could argue that any program that uses at least one of gconf or
> bonobo-conf is affected, since, after all, they must live with the
> consequences of the decision; or (e) one could argue that programs
> that want to use some API for settins are affected since, for example,
> gnumeric is blocked from using _any_ good configuration API so long as
> the future is unclear.
> 
> Which of these makes the most sense? One could argue that maybe only
> the people closest to the problem should be deciding, but if the idea
> is to make sure that the project's architecture meets overall
> requirements, then one should include at least the major consumers of
> those architectures in defining those requirements.

The idea is simply to have the RFP author pick a small group they
think would be representative. For example, on this issue we might
pick:

 - me and Dietmar
 - Martin as libgnome maintainer
 - Jody as an app author who seemed to care and overall grownup 
   and smart guy
 - Elliot since he's shown interest and been talking to people
 - Colm as another person who knows a lot about the technical area

Or something like that. (Please, no one create a thread on whether
this is in fact a good list! It's not an issue at the moment.)

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.

Everyone gets to add comments to the RFP and participate in
discussion, of course, even if they aren't in the list of
responsibles.

> And finally, there are a lot of smart technical people involved in
> GNOME who don't necessarily maintain any modules, or work a lot in
> areas where they are not maintainers. I think it would be better if
> any technical review process we had was designed to include them as
> well.

Yes. Similar point from Drazen, I think it's probably right that any
foundation member should be able to be in the group of evaluators when
that seems appropriate.

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

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.

The RFP process just collects ad-hoc working groups of people
interested in a given topic to hash out that topic, so we spread the
work among people and be sure the appropriate/interested parties are
always involved.

If you look at my suggestions for the GConf panel, for example, I
think that's clearly a better list of people than a generic list of
"most cool GNOME hackers" that might be on a general-purpose
architecture committee.

Havoc