Hi Ken -

Sorry for being unclear. I absolutely agree with your point about people 
doing their projects until they feel it's ready. As a matter of fact I 
think that pretty much all BPPs should be about stuff that's ready to go 
(see my example which already pointed to the code). I do not want empty 
upfront commitments; I want to be able to have the board make decisions 
about concrete work that is there and available to look at.

Cheers,
   - Andreas

Ken Causey wrote:
> 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
>>
>>