how the new PEAR government might work

From: 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

« previous php.pear.dev (#45897) next »