Governance Model

Users are community members who have a need for EduERP e.g. staff of an institution using the software. Users are the most important members of the community and without them the Project would have no purpose. Anyone can be a User; there are no special requirements. The EduERP Project asks its Users to participate in the community as actively as possible. Common User contributions will include:

Evangelizing about the Project (e.g. a link on a website and word-of-mouth awareness raising) Giving the community feedback from a User perspective, and being courteous and constructive when doing so Providing moral support (a ‘thank you’ goes a long way) Users who continue to engage with the community will often become more and more involved. Such Users may find themselves becoming Contributors.

Contributors are community members who provide significant input to the Project. Anyone can be a Contributor – there is no selection process. In addition to User inputs, Contributors might support the Project in many ways including:

  • Suggesting future developments [lists.eduerp.org.ng] 
  • Reporting bugs
  • Triaging bugs
  • Fixing bugs
  • Programming (writing code, new tests, etc.)
  • Commenting on others’ code in the review tool
  • Writing documentation
  • Participating in the release process
  • Providing graphics and web design
  • Organizing conferences
  • Doing community work (active on mailing lists [lists.eduerp.org], forums, IRC and at events)
  • Supporting and coaching new users

Contributors engage with the project through tools like the issue tracker, code review tool, IRC and mailing lists, or by writing or editing documentation.  Code changes are submitted via patches, which will be considered for inclusion in the project by existing Approvers.  The developer mailing lists or IRC are the most appropriate places to ask for help when making a first contribution.

Both Users and Contributors are able to see and comment on all contributions to the project via the code review tool (Github).  In that way they can help improve the code quality and may also be able to influence the review process, which ends at the acceptance or rejection by the Approver.  This commit-then-review process is efficient, as it allows everyone to make direct contributions into a review system.  This levels the field between Contributors and Approvers, ensures that all contributions are reviewed, and allows all reviews and comments to be more easily tracked by the community as a whole.   A Contributor’s profile will increase as he / she gains experience with the project and makes significant contributions to it.   As a result they may be nominated as an Approver, described in the next section.

Approvers are community members who have shown that they are committed to the project and its objectives, and perform an essential role safeguarding its long-term success. Approvers review all code contributions and decide which are accepted for commitment based on “technical fit” and “spirit fit” with the project.  Approvers are also Contributors and in some cases they can directly commit their own code, but this is unusual. Approvers are expected to provide constructive feedback to rejected contributions.  This helps Contributors learn the expected quality and direction of the project, and thus improve the future contributions.  Approvers are also expected to participate on relevant mailing lists and to coach Contributors.

A Contributor can be nominated as an Approver by an existing Approver, and seconded by one other Approver or Maintainer.  Once nominated and seconded, the Approver is appointed unless a community member objects to the Chief Maintainer within 15 work days.  If an objection is raised, the Chief Maintainer decides, usually within 15 work days. Discussion about the nomination may happen in private between existing Approvers.  This allows Approvers to freely express their opinions about a nominee without causing embarrassment. The nominee can request an explanation of any rejection from the Chief Maintainer.  Once someone has been appointed Approver, they remain in that role until they choose to step down by informing the Chief Maintainer. In extreme circumstances Approver privileges can be revoked by a vote of no confidence, proposed by an existing Approver or Maintainer and arranged by the Chief Maintainer. Privilege revocation requires a two-thirds majority vote of those Approvers and Maintainers who express an opinion.

Maintainers are recognized leaders in their area, and have been identified as owners of a component of the project code. A Maintainer may delegate responsibility for a subset of his / her component to another Maintainer.  Maintainers are responsible for the overall quality and spirit fit of their component, so they need good visibility of Contributor and Approver activity. They ensure the smooth running of the Project and must always be aware of the current state of their component, ideally ensuring it is ready for beta release at any time.  Maintainers are expected to participate in strategic planning, approve changes to the governance model, manage intellectual property rights discussions within the community, and review code contributions which have not been reviewed by others.  An Approver who makes a high level of contribution to the Project, particularly to its strategic direction and long-term success, may be nominated as a Maintainer by an existing Maintainer.  A Maintainer may also nominate a new Maintainer to take ownership of a subset of his / her component.  All new Maintainer nominations must be seconded by another Maintainer. Once seconded, a new Maintainer is appointed unless a community member objects to the Chief Maintainer within 15 work days. If an objection is raised, the Chief Maintainer decides, usually within 15 work days.

Maintainers may delegate their responsibilities temporarily to people they trust, such as when unavailable for extended periods. In this case, the Maintainer who has delegated retains responsibility for the actions of the person who received the delegation. Once someone has been appointed Maintainer, they remain in that role until they choose to step down by informing the Chief Maintainer, preferably with one month’s warning. In extreme circumstances Maintainer privileges can be revoked by a vote of no confidence, proposed by an existing Maintainer and arranged by the Chief Maintainer. Privilege revocation requires a two-thirds majority vote of those Maintainers who express an opinion.

The Chief Maintainer leads the Maintainer group, coordinating and facilitating its activities. He / she sets the overall vision and direction of the EduERP Project. The Chief Maintainer has the final say when the Project fails to reach consensus. He / she is expected to ensure that all governance processes are adhered to, and to intercede if other community members aren’t acting appropriately. The Chief Maintainer will also oversee contributions from a strategic and roadmap perspective.  When the Chief Maintainer decides to step down, the Maintainers will arrange a vote to choose his / her successor by simple majority vote of all Maintainers. Once someone has been appointed Chief Maintainer, they remain in that role until they choose to step down by informing the Maintainers, preferably with one month’s warning, or there is a vote of no confidence by two-thirds of all Maintainers.

Support

All participants in the community are encouraged to provide support for new Users.  This support is an important way to grow the community. Those seeking help should recognize that all support activity within the Project is voluntary and is therefore provided as and when time allows.  A User requiring guaranteed response times or results should seek to purchase a support contract from other sources, but for those willing to engage with the project on its own terms, and willing to help support other Users, the community support channels are ideal.

Decision Making Process

Decisions about the future of the Project are made through mailing list discussion with the members of the community, from the newest User to the Chief Maintainer. In order to ensure that decisions are not bogged down by requiring formal consensus, the Project operates a policy of lazy consensus. This allows the majority of decisions to be made without resorting to formal consensus discussions.

Lazy Consensus

Decision-making typically involves the following steps:

a. Proposal
b. Discussion
c. Decision, by
d. Consensus
e. Maintainer, if consensus is not reached through discussion
f.  Chief Maintainer, if Maintainers disagree and cannot reach 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 Contributor mailing list or submit a patch implementing the idea to the review tool, which is the preferred option. 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 community should 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 recognized 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, a reasonable amount of time should pass before assuming no objections. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period should be chosen so as to be as inclusive as possible of all participants, regardless of their location and time commitments.

Contribution Process

Anyone can contribute to the project, regardless of their skills, as there are many ways to contribute. A Contributor might be active on the EduERP mailing lists and issue tracker, or might supply patches via pull requests. The EduERP mailing lists is the most appropriate place for a Contributor to ask for help when making their first contribution.