Re: GNOME Enhancement Procedure

On 19Jun2001 02:08AM (-0400), Havoc Pennington wrote:
> 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.

I'm not saying it's bad, that was just my gut reaction. I think if the
document said the same things but more concisely I might not have felt
that way. Perhaps it's as good as we can do.

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

Perhaps there should be some way to decide the procedure clearly
should _not_ apply so we don't get too bogged down in process.

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

Picking a representative group makes sense. I'm not totally sure the
RFP author picking it makes sense - it seems like an awkward position
to be in, though I know some provisions are intended to be

> 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 didn't specify details because I didn't think it through very well,
but I wanted to raise this as an alternative. I guess my general point
is that sometimes being a domain expert in a particular problem may
not be the sole best qualification for deciding how a particular
solution to that problem affects the broader project as a whole.
> 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.

I guess I like the idea of ad-hoc groups; perhaps we should look at
the way the IETF sets up working groups, as their process works
well. I think the IETF also has an overall body that reviews the work
of working groups, but perhaps that is not necessary in our case.
> 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.

Your suggested group probably is. I was thinking of a group like
"Havoc, Martin & Dietmar" coming out of this process, which I don't
think would be as good, even though it is the most literal list of
maintainers involved in this particular issue.



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]