Re: GNOME Enhancement Procedure

[Drazen Kacar <dave arsdigita com>]

Maciej Stachowiak wrote:

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

That's pretty simple and straigthforward:

   The actual technical work of the IETF is done in its working groups. To
   become a participant in the IETF, one merely becomes active in one or
   more working groups by asking to be added to the WG's mailing list.

The whole page is at http://www.ietf.org/join.html. Although I'd be
more interested in cases when the IETF process didn't work out 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.

There are differences between IETF and Gnome. "It's not possible to
implement at all" would be a valid reason against some IETF specification,
but "it's not possible to implement until our next release" would not. And
Gnome project would have to look at the timeline for the implementation.
I hope that "the maintainer has the final word" provision would take care
of this.

A note about bureaucracy (perceived or real): the good thing about writing
proposals like this is that the implementation decisions would be
documented. Once the code is written, one can read it and see how it
works, but it's very hard to find out why the particular implementation
strategy was chosen. In case the implementation has to be changed, this
documentation would be very helpful. It would also be very helpful for the
new people joining the project. Or the old hands who want to start working
on existing module, on which they never worked before. It might also be
helpful for sysadmins who just want to use Gnome and perhaps customize it
a bit.

But it's a trade-off. If people have to write the documentation, they
can't write the code at the same time. Whether it's a good trade-off or
not is a matter of personal opinion, I think.

BTW, I have a small addition for the RFP document. When the final version of
RFP is made (whatever the status may be), it should have the information
about the actual discussion: the mailing list name, pointer to the
archive, starting and ending dates (approximately). Maybe even the subject
lines, if it would be difficult to locate the relevant articles in the
archive for some reason. Rationale: RFP should be a good summary, but 
people who need to know more than that should have an easy way to locate
articles with the relevant discussion.

-- 
 .-.   .-.    Are you crying?  No, I'm bleeding.
(_  \ /  _)
     |        dave arsdigita com
     |