A note from the governor!
 

The project governance statement below is selected from a standard common template that describes the 'Benevolent Dictator' model in detailed terms. Strictly speaking, it is an accurate depiction of how the NuPattern project is currently being run today, and how it has been run to date. Ow'ever, the gov'ner would prefer to have da project run with a more 'Meritocratic' governance model (with PMC), that distributes much of the decision making and strategic direction to many more people. Ow'ever, despite the gov'ners wishes, the project does not yet have a quorum of committers willing to make decisions about the future of the project, so the gov'ner at this point is the only one willing to.
 

Seriously, join the project committers and let's get the this stuff shared in the community.
 

If you are interested in some different governance models for open source projects, check out this link.
 

Project Governance

This project is led by a benevolent dictator and managed by the community. That is, the community actively contributes to the day-to-day maintenance of the project, but the general strategic line is drawn by the benevolent dictator. In case of disagreement, the benevolent dictator has the last word. It is the benevolent dictator’s job to resolve disputes within the community and to ensure that the project is able to progress in a coordinated way. In turn, it is the community’s job to guide the decisions of the benevolent dictator through active engagement and contribution.

Roles and Responsibilities

Jezz Santos (the gov'ner) is self-appointed as Benevolent Dictator or project lead. However, because the community always has the ability to fork, this person is fully answerable to the community. The project lead is expected to understand the community as a whole and strive to satisfy as many conflicting needs as possible, while ensuring that the project survives in the long term.

In many ways, the role of the benevolent dictator is less about dictatorship and more about diplomacy. The key is to ensure that, as the project expands, the right people are given influence over it and the community rallies behind the vision of the project lead. The lead’s job is then to ensure that the committers (see below) make the right decisions on behalf of the project. Generally speaking, as long as the committers are aligned with the project’s strategy, the project lead will allow them to proceed as they desire.

Additionally, Outercurve Foundation staff consider the project lead primary point of contact or first point of contact for the project for purposes of business operations including domain registrations, and technical services (e.g. code-signing).

Committers

Committers are contributors who have made sustained valuable contributions to the project and are now relied upon to both write code directly to the repository and screen the contributions of others. In many cases they are programmers but it is also possible that they contribute in a different role. Typically, a committer will focus on a specific aspect of the project, and will bring a level of expertise and understanding that earns them the respect of the community and the project lead. The role of committer is not an official one, it is simply a position that influential members of the community will find themselves in as the project lead looks to them for guidance and support.

Committers have no authority over the overall direction of the project. However, they do have the ear of the project lead. It is a committer’s job to ensure that the lead is aware of the community’s needs and collective objectives, and to help develop or elicit appropriate contributions to the project. Often, committers are given informal control over their specific areas of responsibility, and are assigned rights to directly modify certain areas of the source code. That is, although committers do not have explicit decision-making authority, they will often find that their actions are synonymous with the decisions made by the lead.

How to become one: Be appointed by the Benevolent Dictator

Contributors

Contributors are community members who submit patches to the project. These patches may be a one-time occurrence or occur over time. Expectations are that contributors will submit patches that are small at first and will only grow larger once the contributor has built confidence in the quality of their patches.

NOTE: before a contributor’s first patch is put into the repository they must sign a Contributor License Agreement or an assignment agreement. The patch can be submitted and discussed but it can’t actually be committed to the repository without the appropriate paperwork in place.

How to become one: Submit a patch to NuPattern at http://nupattern.codeplex.com/SourceControl.
  • Create a fork on this project site.
  • Clone your fork to your local machine.
  • Commit your changes to the fork locally.
  • Push your changes to your fork on this project site.
  • Submit a 'Pull Request' from your fork on this project site.

Users

Users are community members who have a need for the project. They are the most important members of the community: without them, the project would have no purpose. Anyone can be a user; there are no specific requirements.

Users should be encouraged to participate in the life of the project and the community as much as possible. User contributions enable the project team to ensure that they are satisfying the needs of those users. Common user activities include (but are not limited to):
  • advocating for use of the project
  • informing developers of project strengths and weaknesses from a new user’s perspective
  • providing moral support (a ‘thank you’ goes a long way)
  • writing documentation and tutorials
  • filing bug reports and feature requests
  • participating on the discussion board(s) or forum(s)

Users who continue to engage with the project and its community will often find themselves becoming more and more involved. Such users may then go on to become contributors, as described above.

How to become one: Use NuPattern

Transparency

Building community trust in the governance of an open-source project is vital to its success. To that end, decision making must be done in a transparent, open fashion. Discussion about the project’s direction must be done publicly. The community should never be caught off-guard by a decision by the Benevolent Dictator. Additionally, discussion about project decisions must be archived so that community members can understand the entire history of a decision and its context.

This work is licensed under a Creative Commons Attribution-ShareAlike 2.0 License.

This work is based upon "Benevolent Dictator Governance Model" by University of Oxford.

Last edited Apr 3, 2013 at 2:13 AM by jezzsa, version 6

Comments

No comments yet.