Overall I agree that the community needs to be further engaged but I'm
not sure I understand how your suggestion of BPPs can be effective.  I'm
going to one-up your strawman by arguing with your particular example,
feel free to posit another if appropriate:

Why would someone wanting to do a project agree to this framework?  It
seems to me if I saw some need I would much rather pursue it freely at
my own schedule, be able to fail in something approximating privacy if
it comes to that, and not be bound to answer to others.  If I then come
up with something that I think the community should consider adopting I
would present it as something close to a finished project that can be
examined and evaluated directly, in contrast to a proposal.  Any voting
or arbitration or decree by the Leadership can happen just as well at
that phase as before.  If I'm voted down then I and my compatriots have
perhaps lost something (not much really, package it and let anyone who
chooses to use it do so individually) but it seems like no greater risk
to the community than if the team agrees to a BPP then fails.

Ken

On Sat, 2009-02-21 at 12:45 -0800, Andreas Raab wrote:
> Indeed. Which comes back to my reasons for running in this board 
> election. Historically, decisions have been made by the people screaming 
> the loudest or the longest. We need to work out a way to fix this and to 
> come to a process by which we can make decisions that are acceptable to 
> the community at large. Here is a straw-man of what I'm thinking about:
> 
> I would like to introduce the idea of a "board project" which is a 
> community project that is approved by the board. The idea is that the 
> board would bless a particular project with a particular schedule and 
> for the period of the project its members can commit freely to the 
> required repositories.
> 
> A Board Project Proposal (BPP) would have to include:
> * A Rationale: Why would we want this project?
> * A Deliverable: What is being done (specifically; best with links to 
> existing code)
> * A Project Lead: Who owns this project?
> * A Board Liaison: Who is the board representative for this project?
> * A Schedule: What is to be done when.
> 
> The most important part of a BPP is its schedule. It allows the board to 
> measure progress by seeing if milestones have been reached. For many 
> things the schedule might be as simple as reserving one month to make 
> the core changes, and another one for bug fixing. That is fine. But what 
> the schedule avoids is having projects stalling forever and nobody 
> knowing how much behind they are and whether it's even still alive.
> 
> Anyone can write a BPP and submit it to the board. The board will vote 
> (by closed ballot) on the proposal and can either approve, reject, or 
> ask for revision of the proposal.
> 
> If approved, the project becomes active. The members working on the 
> project can freely post to the required repositories. The board tracks 
> and communicates the progress of the active projects in its meetings 
> based on the schedule and the milestones.
> 
> If an active project does not reach its milestones, it can be canceled 
> by the board. When a project is canceled it is the responsibility of the 
> board liaison to clean up any damage that might have been created by 
> premature commits.
> 
> Here is an example BPP:
> 
> -----------------------------------------------------------
> BPP: Replace InputSensor/EventSensor
> ====================================
> 
> 1. Rationale: InputSensor/EventSensor are fraught with peril. Many 
> projects (including Sophie, Hydra etc) have had to fight with its 
> shortcomings. This project is the integration of a rewrite of both of 
> these classes done in Sophie.
> 
> 2. Deliverable: Integrate code originally posted at 
> http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg03413.html 
> 
> 
> 3. Project Lead: Michael Rueger
> 
> 4. Board Liaison: Igor Stasenko
> 
> 5. Schedule:
>     - March 09: Update Mantis with code+Installer scripts
>     - Milestone: April 1st; All code is committed.
>     - April 09: Bug fixing as needed.
>     - Project completion: May 1st.
> 
> -----------------------------------------------------------
> 
> With a proposal like the above the board can most definitely vote on it. 
> It's clear what is to be done, why it should be done. There is a 
> schedule that can be used to measure progress. If the milestones are not 
> achieved the board can react properly.
> 
> What do people think? I think one of its main advantages is that it 
> strengthens the position of the board. If you don't like what the 
> board's approving, run for it yourself (and yes, there is still time!).
> 
> Cheers,
>    - Andreas
> 
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090221/980d4f88/attachment.pgp