Re: GNOME Enhancement Procedure

> Here's a draft of one way to try and avoid this kind of extended
> flamewar. Let me know what you think.

Hi Havoc,

I like the idea a lot. It's a straightforward, highly visible method to
work through this stuff. A few comments:

* I'd simplify it a bit, particularly surrounding the date and time
stuff. The "fast track" stuff comes to mind in particular. I'd say give
the requirement stuff a week minimum, and if there aren't any problems,
go ahead and approve it.

* It might go without saying, but the essential requirements (mmmm,
verbal redundancy...) should be emphasized as pretty serious things. I
would hate to see a lot of proposals go through and later be sandbagged
because a requirement that was marked as essential needs to be dropped
for whatever reason (plausibility, time constraints, etc). We need a
procedure, but we don't want things to get bureaucratic and tied up in
these things.

* Should we require votes among the maintainers? Since even the largest
group of maintainers is a relatively small group , could we just go on
"consensus"? On the other hand, our track record for "consensus" the
past year or so has been less than stellar. If things get really
deadlocked, we could let the board (sans involved maintainers) decide.

* Ditch the harassment section. A simple procedure is good, but we're
all adults here and it goes without saying that Maintainers Should Act
With Maturity and Play Nice. I expect arguments and an occassional
flamewar, but I should hope that no one would try to stuff the voting or
subvert the process. If so, we have a bigger problem and a set of
maintainers with whom I would rather not associate. I don't think that's
what we have now, and I sincerely hope it never comes to that.

* Add a changelog section to the end. Something simple, like:

    * Some Guy <someguy yahoo com> - 18 June 2001 - Made "Sends email" a
    controversial issue.
    * Joe Hacker <joe foo com> - 19 June 2001 - Added rationale to
    "Sends email" section.
    * Joe Hacker <joe foo com> - 1 July 2001 - Changed status to
    Approved as it was approved during a phone meeting on 30 June.

et cetera, so following the proposals on the web and looking back at
them is easy, and we can see exactly when stuff happened. Also, I
definitely think these should be in CVS. The bonsai stuff in the CVS
commits list is heavenly.

* Minor nit: in the example document, list the modules of the
responsible maintainers.

More as they come to me. :)


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