how the new PEAR government might work
| From: | Gregory Beaver | Date: | Wed, 14 Mar 2007 03:29:40 +0000 |
| Subject: | how the new PEAR government might work | ||
| Groups: | php.pear.dev | ||
| Request: | Send a blank email to pear-dev+get-45897@lists.php.net to get a copy of this message | ||
Hi all,
Since there has been little feedback, I'd like to describe the timeline
I envision for power transfer to the new system, and how it should
work. Suggestions and improvements are welcome.
Before describing the timeline, let me see if I can distill the
important essence of the constitution (all of the stuff below is spelled
out in more detail in the constitution):
Developers have supreme power over ultimately what bugs/features will be
assigned to specific roadmap versions, and to releasing package versions
(just like now). Developers will have to cede some control over API
decisions/QA/docs to the collective. Unlike now, developers may be
expected to mentor a new developer and help introduce them to the
systems within PEAR (how to package, document, test, etc.)
In other words, the bulk of the day-to-day power will remain with
developers, but some of the QA decisions and individual ownership will
be relinquished to the collective.
The collectives have supreme power over packages within the collective
in terms of API decisions, QA, documentation, defining the way
collaboration works in the collective, choosing a collective leader or
leaders, self-promotion of packages within the collective and assigning
mentors to new developers of packages within the collective.
The PEAR Group only has power over issues that affect all of PEAR like
coding standards, CVS karma, and all major decisions made about PEAR as
a whole like allowed licenses and even what defines a collective.
The PEAR president has no power over any of the things above, except for
the ability to veto a PEAR Group decision. The president cannot create
policy. The president's main job will be PR, talking to people outside
of PEAR like an ambassador, trying to recruit new developers or bring
packages into PEAR, and to solve big emergencies in a hurry like if pair
were to suddenly decide not to host pear.php.net.
[if this abstract is useful, I'll add it to the constitution at the top]
So, here is the timeline I see:
By March 18, 2007: Transfer the constitution into the official manual in
docbook format, Officially announce adoption of the new constitution on
March 18 on the front page.
By March 25, 2007: Announce elections for the 7-member PEAR Group and
the president, solicit nominations
By April 8, 2007: Begin elections, to run concurrently until April 22, 2007
April 23: winners immediately begin official power transfer (cvs karma
rights, etc.)
Post April 23: PEAR Group decides how to conduct discussions, defines a
collective, and begins re-organization of PEAR
Post April 23: the website team implements collaboration tools as needed
for the new PEAR group and for each collective
My hope is that by June 1, when many potential developers are getting
out of school or on vacation, we can begin the work in earnest of
improving PEAR as a whole through things suggested by others earlier
such as a design competition for the PEAR website, or serious
improvement to the documentation, etc.
Thanks,
Greg