Version history:
|
0.1 |
16 September 2011 |
First draft open for discussion |
1. Introduction
A project governance model describes the roles that participants in a project can take on, the ground rules for participation, the processes for communicating and sharing within the community, and the quality control and decision making processes. A clear governance model allows potential contributors to understand how they should engage with the project, what is expected of them and what protections are provided to ensure that their contributions will always be available to them. The adoption and communication of a clear and concise governance model is one of the most important steps a project can take to achieve sustainability through open development.
Governance models range from centralised control by a single individual, also known as benevolent dictator, to distributed control awarded in recognition of contributions, or meritocracy. You can find governance models at any point along this spectrum; it is also possible for a project's chosen governance model to move within this range as the project matures. It is therefore critical that a project clearly communicates its participation policies to potential users and developers.
DataFlow is a meritocratic open source project. Anyone with an interest in the project can join the community, contribute to the project and take part in the decision making process. The following sections describe the roles and responsibilities one can take in the project, and the contribution and decision making processes.
2. Roles and responsibilities
2.1. Users
Users are community members who have a need for the project. They are the most important members of the community and without them the project would have no purpose. While DataFlow is aimed primarily at academic researchers and library specialists, anyone with a need for the project outputs can be a user; there are no special requirements.
We encourage DataFlow project users to get involved in the community as much as possible. The first step in doing this is joining the project mailing list.
Common user contributions include (but are not limited to):
Users who engage with the project on a regular basis are likely to become more and more involved. Such users may find themselves becoming contributors, as described in the next section.
2.2. Contributors
Contributors are community members who contribute in concrete ways to the project. Anyone can become a contributor, and contributions can take many forms. There is no expectation of commitment to the project, no specific skill requirements and no selection process.
In addition to their actions as users, contributors may also find themselves doing one or more of the following:
Contributors engage with the project through the mailing list and issue tracker, or by writing documentation in the project wiki [TO DO: Add link when wiki becomes available]. If their contribution is of a technical nature, they can submit a patch [TO DO: link to relevant info on how to submit a DataFlow patch], which will be considered for inclusion in the project by existing committers (see next section). The developer mailing list is the most appropriate place to ask for help when making that first contribution.
As contributors gain experience and familiarity with the project, their profile within, and commitment to, the community will increase. At some stage, they may find themselves being nominated for committership.
2.3. Committers
Committers are people who have shown that they are committed to the continued development of the project through ongoing engagement with the community. In recognition of their contribution, they are offered direct access to the project resources so that they can more easily fulfil their activities. One aspect of this new role is that committers can make changes directly, without having to submit patches.
This does not mean that committers are free to do what they want. In fact committers have no more authority over the project than the other contributors. While committership indicates a valued member of the community who has demonstrated a healthy respect for the project's aims and objectives, their work continues to be reviewed by the community before acceptance in an official release. The key difference concerns when this approval is sought from the community. A committer seeks approval after the contribution is made, while a contributor has to do it before.
Seeking approval after making a contribution is known as a commit-then-review process. It is more efficient to allow trusted people to make direct contributions, as the majority of those contributions will be accepted by the project. The project employs various communication mechanisms to ensure that all contributions are reviewed by the community as a whole. By the time a contributor is invited to become a committer, they will have become familiar with the project's various tools as a user and then as a contributor.
New committers can be nominated by the existing committers. Once they have been nominated, there will be a vote by the project management committee (PMC; see below). Committer voting is one of the few activities that takes place on the project's private list. This is to allow PMC members to freely express their opinions about a nominee without causing embarrassment. Once the vote has been held, the aggregated voting results are published on the public mailing list. The nominee is entitled to request an explanation of any NO votes against them, regardless of the outcome of the vote. This explanation will be provided by the PMC Chair (see below) and will be anonymous and constructive in nature.
It is important to recognise that commitership is a privilege, not a right. That privilege must be earned and once earned it can be removed by the PMC in extreme circumstances. However, under normal circumstances committership exists for as long as the committer wishes to continue engaging with the project.
A committer who shows an above-average level of contribution to the project, particularly with respect to its strategic direction and long-term sustainability, may be nominated to become a member of the PMC.
2.4 Project Management Committee
The PMC members have additional responsibilities over and above those of a committer that ensure the smooth running of the project. PMC members are expected to review code contributions, participate in strategic planning, approve changes to the governance model and manage the copyrights within the project outputs.
Members of the PMC do not have significant authority over other members of the community, although it is the PMC that votes on new committers. It also makes decisions when community consensus cannot be reached. In addition, the PMC has access to the project's private mailing list and its archives. This list is used for sensitive issues, such as votes for new committers and legal matters that cannot be discussed in public. It is never used for project management or planning.
Membership of the PMC is by invitation from the existing PMC members. A nomination will result in discussion and then a vote by the existing PMC members. PMC membership votes are subject to consensus approval of the current PMC members.
2.5 PMC Chair
The PMC Chair is a single individual, voted for by the PMC members. Once someone has been appointed Chair, they remain in that role until they choose to retire, or the PMC casts a two-thirds majority vote to remove them.
The PMC Chair has no additional authority over other members of the PMC; the role is one of coordinator and facilitator. The Chair is also expected to ensure that all governance processes are adhered to, and has the casting vote when the project fails to reach consensus.
3. Contribution process
Anyone can contribute to the DataFlow project, and there are many ways to contribute. For instance, a contributor might be active on the project mailing list and issue tracker, fix bugs and supply patches, or help with producing project documentation and translation in other languages. The various ways of contributing are described in more detail below.
3.1. User feedback
The DataFlow team is always keen to know more about how users engage with the project and how they would like it to look and function. This feedback is vital to the life of the project. Without it, the team would not be able to improve the software's usability, a key element that makes the project stand out among its competitors.
As a new user, you may feel reluctant to make requests or provide criticism, no matter how constructive, for fear of seeming impolite or ungrateful. But we encourage you to contribute to the project mailing list, and add feature requests to the issue tracker or a special section on the project website. At the same time, you should be aware that not all feature requests will be implemented, although every comment will be considered and feedback will be provided as to how important that request is.
3.2 User support
Once they have gained some experience, old users can help newcomers get started with the project. Helping new users is critical for the success of the project as some of these newcomers will themselves become contributors and ensure the ongoing development and support of the project.
The quickest, easiest and most significant way to provide such support is to answer newcomers' questions on the mailing list. These are often best answered by those who have themselves recently experienced the same issues. By answering questions from newcomers you will also substantially help the project team by saving developers time.
As you gain experience, you will be able to ask and subsequently answer more complex questions. In turn, you will be supported by more experienced users as the complexity of your own requests grows. In this way, providing support will benefit both you and the project itself.
3.3 Marketing
It is vital that the project attracts users on an ongoing basis. As an existing user, you can help the project to do this by telling people about it and encouraging them to try it out.
The project may also engage in more active forms of marketing, such as representation at conferences and workshops. By offering yourself to present the project to others, you can also help ensure that a flow of users, and thus potential contributors, is maintained.
3.4 Software design and implementation
DataFlow also welcomes contributions from people with a technical background. As a software developer, your first step towards contributing code will probably be reporting bugs and submitting fixes. If you are not a committer on the project, you would normally make these contributions by submitting a patch [TO DO: link to relevant info]. You might then go on to design new features for the project or redesign or develop current ones.
Remember that all significant code contributions should be discussed on the developer mailing list before implementation. This will allow the project team to ensure that the design is appropriate and user experience will not be adversely affected. Smaller contributions, such as bug fixes, can be submitted as patches on the issue tracker without discussion.
3.5 Quality assurance
Quality assurance (QA) is critical for the success of the DataFlow project. It is also something to which almost anyone can contribute. As a user, you can help by testing release candidates [TO DO: link to relevant GitHub section when available] before they are formally released and provide feedback in the issue tracker. You can also run the latest version of the software [TO DO: link to relevant GitHub section] and report any bugs. Developers can contribute by fixing those bugs, and by helping to manage them until they are fixed.
To encourage ongoing contributions, the project team will keep users and contributors informed of activity on issues in the issue tracker. They will examine each new issue and comment on it, marking duplicates and highlighting workarounds. They will also discuss potential solutions and close them when work is complete.
3.6 Graphics and art
If you have graphics or art skills, you can make a valuable contribution to the DataFlow project by creating icons, logos, wallpapers, banners, labels and other artwork. These will be seen every day and could potentially be used throughout the project and across all its products. You could also participate by designing marketing material or providing illustrations for presentations and guides.
You should submit this kind of contribution via the project mailing list or issue tracker once you have engaged with a project and developed a feel for it.
3.7 Writing documentation
Documentation is critical to new DataFlow users and something that developers don't always have time to write or update. One of the best ways in which existing users can contribute is by documenting their own experiences of the project. This can be in the form of tutorials, guides, HOW TOs or FAQs (frequently asked questions). These don't have to be perfect: in most cases, a skeleton document with bullet-point instructions is better than nothing at all. Those who use the document will probably ask supplementary questions and, once they understand, can help to pad out the details.
DataFlow is always willing to hear from contributors interested in writing documentation for the project. We maintain a wiki for project documentation [TO DO: link to project wiki when available]. In answering a newcomer's question, you can write up the answer directly in the wiki and point to it from your reply on the mailing list.
You can also contribute to the wiki whenever you see something that could be improved or updated. It is helpful to make people aware of any changes you made to the wiki by mentioning them on the mailing list. Some examples of the documentation you can write are given below.
User FAQs
User FAQs [TO DO: link to FAQ section in wiki] are an excellent place to start contributing to a project. If you're not technical, you can simply post a note in the issue tracker with a proposed FAQ entry.
HOW-TOs and tutorials
These short, self-contained documents are also a great place to start contributing to. If you enjoy a particular feature of a project, documenting it for others would be an extremely welcome contribution. Equally, if you have come across a problem with the software or any other aspect of the project, you could write about it and document a solution, which will be very useful to other users. Providing video screencasts, which can be very effective for introductions and HOW-TOs, would also be a good way to contribute.
User guides
Writing and maintaining a comprehensive user guide for the project is a difficult job requiring a lot of time and effort. Any additions, clarifications and corrections to the user guide are therefore very much appreciated by the project team. To do this, you can draw on the mailing list archive, which contains useful material that can be easily converted into paragraphs. Again, the community will be happy to help with any questions you might have.
Developer guides
The project team also welcomes improvements to the developer guides [TO DO: add link when available], but you will need some technical skills to contribute to this kind of documentation. If you have this kind of expertise, it's a great place to start gaining an understanding of how to develop with or for the project. The developer mailing list archive contains plenty of useful information, and the developers themselves are happy to help you get started.
3.8 Create language-based communities
The default language for DataFlow is English. If English is not your native language, you could make a valuable contribution to the project by translating the project applications and documentation into your own language. Even if you can spare only an hour here or there, your translation work will make a difference. The first step to contribute in this way is by offering your support on the project mailing list.
3.9 Monetary donations and developer support
For an open development project, money is less important than active contribution. However, some people or organisations are cash rich and time poor, and would prefer to make their contribution in the form of cash. If you want to make a significant donation, you may be able to sponsor a developer to implement a new feature or fix some bugs. To find out more about how you can make a donation to the project please contact the project manager.
4. Decision making process
Decisions about the future of the project are made through discussion with all members of the community, from the newest user to the most experienced PMC member. All non-sensitive project management discussion takes place on the project mailing list. Occasionally, sensitive discussion occurs on a private list.
In order to ensure that the project is not bogged down by endless discussion and continual voting, the project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to a formal vote.
4.1 Lazy consensus
Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to the project list or, if this is of a technical nature, submit a patch implementing the idea to the issue tracker. This will prompt a review and, if necessary, a discussion of the idea. The goal of this review and discussion is to gain approval for the contribution. Since most people in the project community have a shared vision, there is often little need for discussion in order to reach consensus.
In general, as long as nobody explicitly opposes a proposal or patch, it is recognised as having the support of the community. This is called lazy consensus - that is, those who have not stated their opinion explicitly have implicitly agreed to the implementation of the proposal.
Lazy consensus is a very important concept within the project. It is this process that allows a large group of people to efficiently reach consensus, as someone with no objections to a proposal need not spend time stating their position, and others need not spend time reading such mails.
For lazy consensus to be effective, it is necessary to allow at least 72 hours before assuming that there are no objections to the proposal. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period is chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.
4.2 Voting
Occasionally some decisions cannot be made using lazy consensus. Issues such as those affecting the strategic direction or legal standing of the project must gain explicit approval in the form of a vote. This section describes how a vote is conducted.
If a formal vote on a proposal is called (signaled simply by sending a email with '[VOTE]' in the subject line), all participants on the project contributors' list may express an opinion and vote. They do this by sending an email in reply to the original '[VOTE]' email, with the following vote and information:
-
+1 'yes', 'agree': also willing to help bring about the proposed action
-
+0 'yes', 'agree': not willing or able to help bring about the proposed action
-
-0 'no', 'disagree': but will not oppose the action's going forward
-
-1 'no', 'disagree': opposes the action's going forward and must propose an alternative action to address the issue (or a justification for not addressing the issue)
To abstain from the vote, participants simply do not respond to the email. However, it can be more helpful to cast a '+0' or '-0' than to abstain, since this allows the team to gauge the general feeling of the community if the proposal should be controversial.
Every member of the community, from interested user to the most active developer, has a vote. The project encourages all members to express their opinions in all discussion and all votes. However, only committers and PMC members (as defined above) have binding votes for the purposes of decision making. It is therefore their responsibility to ensure that the opinions of all community members are considered.
While only committers and PMC members have a binding vote, a well-justified '-1' from a non-committer must be considered by the community, and if appropriate, supported by a binding '-1'.
In such situations discussion will continue until the objection is overruled or the proposal itself is altered in order to achieve consensus (possibly by withdrawing it altogether). In the rare circumstance that consensus cannot be achieved, the PMC will decide the forward course of action.
4.3 Types of approval
Different actions require different types of approval, ranging from lazy consensus to a majority decision by the PMC. These are summarised in the table below.
4.4. When is a vote required?
Every effort is made to allow the majority of decisions to be taken through lazy consensus. That is, simply stating one's intentions is assumed to be enough to proceed, unless an objection is raised. However, some activities require a more formal approval process in order to ensure fully transparent decision making.
The table below describes some of the actions that will require a vote. It also identifies which type of vote should be called.