By nedjo on

With Drupal growing and maturing as a project, a formal and explicit structure of roles and decision making would probably be appropriate.

I've recently attempted to capture current practice in the post "Proposed, draft guidelines for contributing to Drupal" and the book page "The Drupal community". But I was unclear on several areas, e.g., how are different types of decisions made in the project?, how are individuals accepted into specific roles (e.g., core developer)?.

Formal policy on these questions increases the transparency and ultimately the effectiveness of a project.

Towards this end, I think the Jakarta Project Guidelines provide an excellent model. They set out composition and responsiblities of four distinct roles - users, contributors, committers, and the project management committee (PMC) - along with specific details of how individuals are admitted into these roles and how decisions are made.

The Jakarta model provides an explicit and proven way for active contributors to take on appropriately higher levels of responsibility within the project as they prove their skills and accomplish substantively larger tasks. This increased responsibility can help to retain skilled developers, who might otherwise become frustrated by a feeling that no matter how hard they work they are still outside the project. By creating a growing base of "committers", it also relieves pressure on project management committee members to make minute decisions personally, preventing bottlenecks and freeing up core developers for larger tasks and planning.

With its expanding code base, skilled group of active developers, and emerging profile, Drupal seems very ready for the formality and transparency of a Jakarta-like structure.

Is there support for and interest in moving in this direction? If so, let's draft a specific proposal drawing on the Jakarta model and existing Drupal practice.

Comments, suggestions, clarifications of existing practice?

Comments

moshe weitzman’s picture

moshe weitzman commented

I think Drupal project would benefit from some more structure. Yet I find the Jakarta guidelines a bit too formal. We have to walk before we can run. Can anyone propose a compromise between current practice and Jakarta?

I agree that this is a worthwhile effort. Many potential contributors become frustrated with our current CVS review practice leave the project. We have seen many patches which were slightly unacceptable, and thus never got committed (e.g. drupal for bloggers, enhanced statistics.module with graphing, ...). I think some guidelines would reduce this friction.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Thanks for your comments. I agree that the full Jakarta approach might be more structure than is needed.

Likely a valuable first step is to clarify the existing policies and structure. Here's a redraft of the material I presented as "The Drupal Community", with questions identified [[in double brackets]]. Answering these questions would put the project in a good position for (a) providing improved documentation and (b) reviewing and potentially refining the current structure.

Anyone able to provide clarification on these questions? Thanks!

There are four defined roles in the Drupal project, with specific rights and responsibilities to
each.

  • User.  A user can make contributions by participating in the drupal.org forums and issue system and the drupal-dev email list, making suggestions and offering code contributions that others will evaluate and potentially apply either to contributed code or to the Drupal core.
  • Contributor.  Contributors develop and maintain
    "contributed" code (mainly, modules and themes).  A
    contributor has applied for and received write access to the
    "contributions" CVS repository and may also have
    special privileges on the drupal.org site enabling her or him to post
    content (book pages, new project releases) to the site. Contributors do not have any special status, rights, or responsibilities when it comes to making contributions to the Drupal core.
  • Maintainer. Maintainers have formal
    responsibility for a designated portion of the core (e.g., a particular core
    module).  Individual areas of responsibility are listed in the file MAINTAINERS.txt. [[How do individuals become maintainers? How are changes introduced by maintainers reviewed, approved, and committed?]]
  • Core Developer.  Core developers have responsibility for maintaining and patching the Drupal software.  While changes will take into account the views and comments of all members of the Drupal roles, it is the core developers who decide on and make changes. [[Where are the core developers listed? How are decisions made? Is consensus needed among all core developers for changes or can one core developer approve a change? How do individuals become core developers?]]
moshe weitzman’s picture

moshe weitzman commented

[[How do individuals become maintainers? How are changes introduced by maintainers reviewed, approved, and committed?]]

The Maintainer list is managed like other CVS core files. Meaning, you have to convince a CVS Commit person (this is a new role) to name you as a maintainer. In practice, Dries picks maintainers based on past contributions. You may nominate others or yourself via email to Dries.

[[Where are the core developers listed? How are decisions made? Is consensus needed among all core developers for changes or can one core developer approve a change? How do individuals become core developers?]]

Anyone can become a core contributor by uploading patches into the issue system. Patches are reviewed by everyone but final decision to commit belongs tothe CVS review team.

CVS review team currently consists of UnConeD, Natrak, and Dries.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Thanks again for the clarifications. Here, then, is a revised draft of the current structure--followed by suggestions for discussion. I've kept the "CVS review team" as "core developers" since I think that's a more applicable description.

Drupal roles and responsiblities

The roles and responsibilities that people can assume in the project are based on merit and contributions. Everybody can help no matter what their role. Those who have been longer term and valuable contributors to the project may obtain correspondingly greater roles in maintaining the code.

  • User.  Users are the people who use Drupal. Users aren't contributing code but may be submitting bug reports or feature requests through the issues system and participating in the drupal.org forums.
  • Contributor.Contributors have either one or both of two distinct roles:
    • "Contributions" contributors.
      "Contributions" contributors develop and maintain "contributed" code (mainly, modules and themes) that are hosted on the Drupal site but not part of the Drupal core. A "contributions" contributor has applied for and received write access to the "contributions" CVS repository. Contributions contributors are improving the overall reach of Drupal by producing and sharing enhancements that can be used by others. This is not, however, a route to becoming a Maintainer; for that, one must first be a Core Contributor.
    • Core Contributors. Core contributors contribute code patches or documentation for the Drupal core. They may also have special privileges on the drupal.org site enabling them to post content (e.g., book pages) to the site.
  • Maintainer. Maintainers have formal responsibility for a designated portion of the core (e.g., a particular core module).  Individual areas of responsibility are listed in the file MAINTAINERS.txt. Core Contributors who have made substantive contributions (particularly to a core component not individually maintained) may apply for Maintainer status by writing to the core development coordinator; they may also be nominated by others (Core Contributors or Maintainers) or invited by a Core Developer. Applications for maintainer status are reviewed and approved by the core development coordinator.
  • Core Developer.  Core developers have responsibility for maintaining and patching the Drupal software and have write access to the core CVS depository. While changes will take into account the views and comments of all members of the Drupal roles, it is the core developers who decide on and make changes. One of the core developers serves as the Core Development Coordinator, reviewing and approving applications for Maintainer status and taking responsibility for all code without a designated Maintainer.

For discussion:

  • Should Maintainers have the ability to directly approve (and, potentially, commit) patches? This would make Maintainers "Committers". Potential advantages: better ability to work through and approve patches, especially relatively minor ones.
  • Should there be a more formalized, transparent process for selecting Maintainers (or Committers?)
  • How does a Maintainer become a Core Developer? Should there be a formalized process for this?
  • How is the core development coordinator chosen? By vote among the core developers? What would happen in the case that the current one resigned? Is this a permanent position?
nedjo’s picture

nedjo
he/him/his
Primary language English
commented

I've updated the book page The Drupal community based on the draft above.

My thoughts at this point on the question of structure in Drupal are:

  • A sound, well thought out structure for decision making with explicit roles is a key to long-term success in an open source project. If we look e.g. to the various Nuke content management systems, issues of structure, roles, and decision making were central in the repeated forks, splits, etc. that occurred.
  • The current project structure has served Drupal well to this point and needs only tweaking.
  • Drupal has structure, but the structure has been mostly unstated. It's best if decision making processes are explicit and clear to all involved.
  • This sort of discussion can appear to be critical of current structure or individuals in leadership roles. I don't think that's the point at all. Drupal is blessed with a highly skilled, dedicated, and visionary set of lead developers. Refining of the structure should have as primary aims building on the current strengths and retaining the current lead developers.
  • Drupal has succeeded in outgrowing its original personalized basis and is reaching a threshold where changes are needed to ensure the project is not held back by its structure. Specifically, there is a need for a more open and likely a larger group of code maintainers or core developers.
  • Ideally, while individual contributions are invaluable, Drupal should be independent of any specific individuals.
  • What we now have is somewhere in transition between a personal project managed by a small group of founders, whose roles and powers derive from their original founding positions, and an open community-driven project. Completing the transition, however, would require only relatively small steps, and would in the short term likely lead to a project that looks just like what we currently have, with the same core individuals in the same roles. The difference would be felt in the longer term, in the form of greater vitality, resilience, and ability to draw in new energy and skill.
  • The key needs are:
    • Depersonalize decision-making, so that key decisions - e.g., acceptance of new members into established roles, like Maintainers, or significant changes to project - are made in an explicity transparent way by all members of a role.
    • Clarify the role and responsibilities of what I've termed the core development coordinator. Make the position based on an explicit selection process.

If there's interest, I'd be happy to draft a proposed revision of the current structure for discussion.