History for WriteAccessRationale

??changed:
-
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",
    http://dev.zope.org/Fishbowl 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.