WriteAccessRationale

Zope Public CVS Repository Write Access Rationale

Below is an explanation of who gets write access, and why it's set up the way it is. See DoingWritableCheckouts for instructions on actually doing checkouts, and CommitterGuidelines for the essential rules for people using write access.

Why

Open source is a crucial part of Zope's story - it can promote evolution of the software, in a way which is true to its users needs. There is a number of ways that we enable the community to share their own improvements to the software, among them direct access to the version-control system, CVS, by which we manage change of the source.

Managing Complexity

It takes discipline to keep software complexity manageable as its scope grows. That risk increases dramatically as you add people to its development. This kind of risk is mitigated through deliberate choices, processes and practices to control the complexity. Without this caution, time is lost, instead of gained, in correcting simple errors, and even worse, getting back on track from features and APIs? that head in the wrong direction.

Thus, we are going to be picky about who will have direct checkin access to the repository, and maintain processes by which changes are deliberated carefully, in ways proportional to their scale.

Note that this is not different than what we do when only internal developers have write access. Extending the scope of the collaboration intensifies the need for explicit, clear processes - the kinds of measures like the fishbowl process and issue tracking, which we had already been using in our internal development efforts.

Community committers will be required to submit a signed agreement by which they formally commit their contributions to the Zope community [XXX clarify], indemnify Zope Corporation, and so forth. This is necessary to keep the legal story safe and secure for everyone.

Who

Zope Corporation repository managers (currently Brian and Ken) designate project managers of efforts that have artifacts - software, documentation, etc - in the repository (listed at RepositoryProjects). Those managers can invite developers who have proven their capabilities with contributions through various conventional mechanisms - collector patches, publically available Products and other software artifacts, fishbowl proposals, code sent via pony express, whatever - and follow-up on their contributions with conscientious maintenance and alerts to status changes.

The project managers have responsibility and discretion about granting and rescinding commit privileges. The managers, themselves, are subject to review by Zope Corp repository managers, who have the last word about everyone's privileges.

It's important that admitted coders be fairly self-regulating.

Someone may submit patches that implement wonderful, brilliant features, but the code is sloppy and requires substantial revision. Such people can continue to contribute using the mediated mechanisms (collector, postings, deposits in their member folders) - and get feedback so they improve their chops to the point that they're ready for checkin privileges.

Perhaps more important, someone may submit phenomenal code that implements mind-blowing features, but not provide a well-motivated fishbowl proposal for those features. Features that head off in an un-agreed direction can be worse than buggy code, because misguided features can have momentum that has to countered. Thus we require adequate and accepted fishbowl proposals for substantial features before they're committed, to keep things on proper track.

CommitterGuidelines outlines these processes.

How

Repository committers checkout Zope using SSH-mediated access to the CVS :ext: server mechanism. We have a (php, sigh) mechanism on cvs.zope.org for declaring repository users, coupled with their zope.org accounts, and depositing their SSH public keys for the server access. See ManagingYourCheckinKeys? and DoingWritableCheckouts for details.

Every Public CVS-based project has a number of resources - see RepositoryProjects for a roster and the details for each.

See CommitterGuidelines for details about policies and practices committers should follow.