­­Key processes that are happening now in the Plone community

• Who does what

• How they communicate

Jon is also going to try applying a "DARCI" model to each area, in order to describe:

Decision

Who is the person that makes the final or critical decisions on the project?

Accountable

Who is the person that is ultimately accountable for making this project happen?

Responsible

Who is responsible for doing the work for this project?

Consultant

Who only needs to be consulted on specific elements of the project?

Informed

Who only needs to be regularly informed but is not responsible for any work on the project?

• Bug reporting and fixing
  

Users report bugs in Trac. Users optionally assign a component. Some components have owners. Some discussions happen in Trac. Developers fix bugs as they are motivated to. Most bugs don't have clear owners.

Core dev team watches incoming ticket queue and assigns tickets to component and milestone if missing.

In the past, Alexander Limi and Hanno organized fairly regular virtual "bug days" where community members would gather to attack bugs in parallel. As of summer 2008, Gabrielle Hendryx-Parker and Hanno have restarted this tradition as "Plone Tune-Up Rallies." :-)

Hanno is the "lead gardener" of Trac. On a loose by-weekly schedule he reviews reports 15, 16 and 17 and adds missing metadata. In preparation for the Tune-Up-Days he assigns the "newbie" keyword to tickets and provides instructions on how to fix them. The "patch" keyword is assigned to tickets which have patches attached to them and only need to be committed to Subversion.

DARCI Analysis

Decision:
Individual component owners have the final power to resolve tickets.

Accountable:
To some extent, individual component owners. But not all components have owners. Accountability is quite weak, except possibly for the security team.

Responsible:
Plone core developers.

Consultant:
Other core developers, depending on the component or feature. Original feature proposer.

Informed:
Original bug reporters, core developers, wider community.

Challenges

Notification is dependent on active engagement, Either by manually entering your email address into the user profile for each Trac instance or by following RSS feeds.

Large number of open tickets without clear owners. We are making good progress on this with the tune-up days, though.

As a general problem we have quite a few components in Plone which lack a strong committed owner. For example the Wiki-functionality is broken in many ways and not likely to ever get fixed.

No way for community to quickly express consensus about the importance/urgency of bugs. 

• Feature requests
  

Users and Developers alike make feature requests via our Trac issue tracker, similar to bug reports. Feature requests will be monitored by the Core dev team and features which are not in scope of Plone Core are rejected. Major features or changes that will break backwards compatibility usually require a PLIP (see below).

Features will be scheduled for the "Future" milestone as long as they have not gotten approval and a dedicated owner that is likely to complete a feature. Owning feature requests is up to the individual contributors. There is no way of requesting a feature and getting it into Plone itself without either doing the work yourself or finding a developer who is willing to do so for you.

DARCI Analysis

Decision:
Individual component owners have the final power to resolve tickets. Release manager has power to decide if a feature is significant enough to warrant a PLIP, in which case the Framework Team will vet the PLIP.

Accountable:

If a person volunteers to work on a feature, they would be accountable for their code. All accountability is voluntary.

Responsible:
Plone core developers who volunteer to work on a feature.

Consultant:
Other core developers, depending on the component or feature. Original feature proposer.

Informed:
Original bug reporters, core developers, wider community.

Challenges:

There is currently no explicit definition of what is in scope for Plone Core and no clear group of people who is responsible for making binding decisions on this. Currently this is informally done by some people from the Core dev team. As a result many feature requests stay in the "initial idea state" without a clear path to either being implemented in an add-on or the core itself.

Trac is not suited well for engaging in discussions about new ideas. The metadata model for bugs doesn't make much sense for most of the feature requests.

• Contributor access process

• Plone Collective (add-on products)

Jon: Plone community members can request Collective commit privs by filing a ticket in Trac. As long as the person is known to the community and/or seems to have a credible chunk of code in hand (e.g. "Hi, I've just written a product I'd like to release on the Collective.") they are granted access. Godefroid Chapelle handles these tickets.

Decision:
Godefroid Chapelle grants all credible requests.

Accountable:

Godefroid.

Responsible:
Godefroid.

Consultant:
N/A

Informed:
N/A

• Plone Core

Jon: Prospective contributors to the Plone core must have established a track record of positive community participation, and complete a legal agreement which vests ownership of core code to the Plone Foundation. There are several hundred contributors to the core. Process is documented at: http://plone.org/documentation/manual/plone-developer-reference/overview/contributing

Decision:
Godefroid Chapelle, Hanno Schlichting and Martin Aspeli serve informally as the gatekeepers here.

Accountable:

Godefroid, Hanno, Martin

Responsible:
Godefroid, Hanno, Martin

Consultant:
Plone core developer community ?

Informed:
N/A

 

• PLIP process
  

PLIP = "Plone Improvement Proposal", based on Python's "PEP" (Python Enhancement Proposal).

Before major changes to behavior (major new features, or changes that could break backwards compatibility) can be introduced to Plone, the proposed changes need to be written up into a PLIP. PLIPs should contain a description of the problem, the proposed solution, and ideally, a working implementation of the idea. PLIPs are reviewed by the Framework Team, and if a PLIP receives a positive vote a majority of the Framework Team, it can be included in a future version of Plone.

Development practices/policies can also be the topic of a PLIP.

PLIPs are not "feature requests" that one hopes someone else will step up implement. They are intended to spur discussion and collaboration about code that has been written, or code that is about to be written.

DARCI analysis

Jon: doesn't feel like we have much formal process around PLIPs before they are submitted with code to the framework team. I'd love others' opinions here.

 

• Framework Team code review process

The Framework Team is a committee of volunteers, self-propagating. The Framework Team's sole formal responsibility is to review PLIPs, and vote on their technical merit and implementation. The Framework Team consists of skilled Plone developers, who have all made major contributions to the Plone codebase, and are entrusted with the responsibilty of thinking through the technical and non-technical implications of submitted code bundles. The Framework Team actively discusses PLIPs both in pre-implementation and post-implementation.

Most of the Framework Team conversation happens via the Framework Team email list.

The Framework Team is not appointed by the PF Board of Directors, and has zero formal connection with the Board.

DARCI analysis

Decision:

Framework Team

Accountable:

Framework Team

Responsible:
Framework Team

Consultant:
Release Manager, PLIP author

Informed:

Core developers

Challenges:

The framework team has been created to vote on technical merit of proposed PLIP's. In the way it is created and structured it is not intended or built to maintain a long-term strategy for Plone or takes into account mid-term effects of PLIP's like growing overall maintenance burden, integration or documentation problems or use of technology with an uncertain future.

• Release process
  

Jon: Plone has a release manager, currently Wichert "Wiggy" Akkermann, who oversees the release process. Wichert plays a vital "traffic cop" role. He is a wrangler and check-and-balance on the Framework Team. He also reviews all smaller checkins/bugfixes for sanity/quality. The actual making of a release involves a call to package maintainers to tag individual package releases, then assembling those into appropriate tarballs, buildout scripts, etc. The platform-speficic installers are maintained by Steve McMahon (Mac, Linux) Sidnei da Silva (Windows).

Plone currently has the following release cycle:

• Major releases (Plone 3, Plone 4) are on a ~18-month cycle. Major releases include new features, and may break backwards compatibility, typically following a one-release deprecation cycle.
• Minor releases (Plone 3.1, Plone 3.2) happen on a ~6-month cycle, and incorporate both bug fixes and new features that do not break backwards compatibility.
• Bugfix releaease (Plone 3.1.x) happen every 4-6 weeks, and include only bug fixes, no new features or changes that would break backwards compatibility

DARCI analysis

Decision:

Release manager sets dates and overall strategy.

Accountable:

Release manager

Responsible:
Release mananger, core developers

Consultant:
Framework team

Informed:

Wider community.

• Conferences/Symposia (Jon)

There is one annual, global Plone Conference each year, and one or more regional Symposia. Symposia are entirely community-organized. The Conference is community-organized, but the Plone Foundation chooses amongst competitive bids from the community. The 2009 conference selection process has already been announced.

• Writing documentation

Books are written by motivated authors under their own initiative, and are somewhat outside of "formal" process here.

Online documentation is written by community members. There ia a Documentation Team which reviews documentation for quality, and is responsibile for the overall information architecture of the Plone.org documentation section.   The Doc Team has assigned a volunteer Editor to each major documentation subarea.