[no subject]

I think the time for review is too short. It might be OK for people who
are working full time on Gnome, but it won't be enough for people who have
another job. It's possible that somebody who isn't directly involved in
Gnome would want to review the proposal (because somebody who is involved
asked him/her to, for example), but it might be impossible on such
schedule. Furteher, if the RFP author thinks the reviewing period should
be longer, then it should be longer. So I propose something like "the
reviewing period will be determined by the RFP owner, but it shuld not
be shorter than two weeks." That's for "fast-track approval, if no
controversy" section. Other time constraints should also be at least two
weeks.

I don't see why several persons couldn't author an RFP. I don't know if
that should be explicitely written.

An objection to "A small group of relevant maintainers finalizes the RFP."
It should be "A small group of interested parties." One doesn't have to be
Gnome module maintainer in order to posess usefull technical knowledge
about the problem in question.

I don't particularly like the voting stuff. The general tone implies that
conflicts are expected and that consensus will be an exception. But if you
want to go with rules like that, then there should be no gray areas.
For example, the "List of responsible maintainers" section ends with:
"The board will resolve all disputes regarding the list of responsible
maintainers." How is the board going to do that? On what schedule? The
results of board decision will obviously be public. But is the board
required to write a public explanation? And why voting in the first place?
Shouldn't the board be able to reach a consensus on this issue?

> Two example topics we might use for a test run of the procedure are
> this -config issue, and the sound server/API issue.

Hm. How about testing it on the "GNOME Enhancement Procedure" proposal
itself?

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