Hi Andreas,

On Sat, Feb 21, 2009 at 12:45 PM, Andreas Raab <andreas.raab at gmx.de> wrote:

> Igor Stasenko wrote:
>
>> Now, if we add the nonacceptance of 3.9 release from some of us
>> (traits), maybe its worth considering about changing the release
>> process, otherwise any future release will be doomed to have same
>> level of nonacceptance as previouse releases...
>>
>
> 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!).


I think this is an excellent idea but completely pointless unless this
process is one that comes to the attention of community members quickly and
easily.  Here's what I suspect; I could just be projecting my own initial
experience, but I suspect it is more widely shared.  I suspect that many
community members, newbies and oldies alike, don't realise there is a
community process because the various introductory web portals focus,
understandably, on getting a Squeak system into the hands of the user, not
on community process.  So the newbie becomes an oldie without being made
aware of the community structure around their use of Squeak.  To them the
community process appears to be mysterious and a little cliqueish.  Hence
they may feel excluded, ignorant and hence unhappy.  This may lead to them
screaming long and loud in an effort to get what they want because they have
not been informed of how to participate in community process effectively, if
at all.

So I suggest you augment the above with a significant effort to extend the
existing web portals with visible and enticing links to content that
explains community structure and process and extends a welcome hand to
encourage them to participate.  If the community doesn't effectively publish
its process, no matter how open it may be in reality, it will be perceived
as being closed and exclusive.

I imagine verbiage to the effect of

    "Squeak is a vibrant and expanding open-source community with many
members.  It has great ways to participate, in existying projects, in fixing
bugs, in exploring blue-sky and in evolving the system both as a platform
and as the future of computing.  Here's (i.e. some link) a great overview of
the community.  Even if you're not ready to get involved now you probably
will some time soon; this is a great place to be.  So if not now, please
remember this and visit the overview some time when you're interested in
getting more involved."

would be suitably welcoming.  But text to this effect needs to be front and
centre, not hidden off side pages.  Further, the overview needs to be
well-written, well-structured, concise, informative and up-to-date.  If we
put effort into this I think there will be significant benefits, in rates
and degrees of involvement, in reduction of conflict, and in enabling a more
effective debate about evolving community structure and process.  In short
more happy lads and lasses and more Squeak.

>
>
> Cheers,
>  - Andreas
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20090221/b9d0afad/attachment.htm