Prplwrt Governance Model

(Redirected from OpenWrt Governance Model)
Jump to: navigation, search

Every PEG in prpl has a governance model. prplwrt's governance model is below.


The mission of the prplwrt PEG is to enable close collaboration between users, hardware manufacturers, semiconductor companies, and the broader OpenWrt ecosystem in a community-run fashion. The focus of the technology enhancements are centered around creating a robust, flexible open source platform suitable for mission critical, highly reliable products. We encourage innovation and applicability to a wide variety of hardware platforms.

Feature discussion[edit]

PEG Community members will work collaboratively to add features to prplwrt that fulfill their own needs and the needs of the community as a whole. Features will be added following the prpl Improvement Proposal process.

Discussion can occur in a number of different ways including via the GitHub issue tracker, the mailing list, and via in-person or web conferences. Meetings will be open to all members of the PEG community and will be announced on the mailing list with sufficient notice. Online meetings should be recorded and posted to a video sharing site. Posting these meetings provide a record of the discussion and allow for participation from those who are unable to participate at the normal meeting time.

Roles and Responsibilities[edit]

Each member of the community has one or more roles in the project. No role is more important than another. PEG community members consist of any individuals with interest in a project; they are not the same as prpl Foundation members.


Users are community members who have a need for the project. Without users, 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
  • propose changes to the code
  • submit changes to the code under the project license

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 committers as described below.


Committers are members of the community with commit access to the project repository. Committers are responsible for ensuring code standards are enforced. Committers will regularly evaluate patch requests with the goal of maximum community participation in development while following code standards and verifying that the patches comply with the prpl IP Policy.

Committers will follow the standard procedure of making changes via pull requests. The only time a committer may push directly to the official repository is when they are fixing a conflict as part of merging a pull request.

Committers have a private mailing list set up and observed by the Community Manager. The private list will only be used for discussing whether to add or remove PEG committers. This mailing list will have a private archive to document decisions and discussions. Decisions will be made via majority vote and votes must last at least 72 hours. If a committer is added or removed, it will be announced on the main mailing list.

Committers should be added based upon the peer acclaim with an appreciation of the unique experiences and skills of those and consistent with the prpl Rules of Engagement and Diversity policy. Of note, no member of the community may be excluded from committer participation based upon their employer or whether they are paid to work on the PEG.

Community Representative[edit]

The project is entitled to one representative on the prpl Foundation Technical Steering Committee (TSC). The community representative will use their own best judgment to represent the needs, thoughts and goals of the project community on the TSC.

Any member of the community may request an election for the project's community representative, provided that at least six months have passed since the last election. Elections for Community Representative will last at least seven days and will be decided by simple majority approval. All community members are eligible to vote.

Code modifications decision-making[edit]

The PEG uses different decision-making processes for buildable branches and feature branches. The wiki for the PEG will clearly specify which branches are “buildable branches.” In all cases, a -1 vote of a code modification is a veto of the code change.

Blue, solid lines branches are 'buildable'; green, dashed lines are 'feature'

Buildable branches[edit]

Buildable branches are branches which are expected to contain code which will compile and pass most tests at all time. This code will be where releases are created from. Buildable branches include, at a minimum, the 'master' branch.

Additionally, any branches which correspond to a supported release are buildable branches. For example, if the project has a major version 2 which is supported and for which bug fixes are made, the branch for 2 will be a buildable branch.

Buildable branch code changes use the review-then-merge voting system. Buildable branches are expected to fully comply with project coding standards.

Feature branches[edit]

Feature branches are branches used for prototyping and building features. Feature branches should build at all times but it’s not an absolute requirement. While these branches should follow project coding standards, this is also not an absolute requirement.

Feature branch changes use the merge-then-review voting system. Once a feature branch is considered sufficiently mature, a pull request can be made to merge a feature branch into a buildable branch and treated like any buildable branch code change.

Release decisions[edit]

Votes on whether a project is ready to be released use majority approval of the project community on the mailing list. Releases may not be vetoed. If anyone identifies serious problems in a potential release, members of the community should consider that in making their votes.

Procedural decisions[edit]

Procedural decisions are decided using simple majority approval of those voting.