7.2 KiB
OpenRefine Governance Model
Draft for discussion. Please submit pull requests to edit this document. Major changes will be discussed in the pull request comment section.
Summary / Overview
OpenRefine is a free, open-source, powerful tool for working with messy data. OpenRefine has a plugin architecture and is distributed under the new BSD license allowing modification, distribution and name changes.
Roles And Responsibilities
OpenRefine development is based on user consensus and open discussion between users. Anyone with an interest in the project can join the community, contribute to the project design, and participate in the decision making process. This document describes how that participation takes place.
Users
Users are community members who have a need for the project. Through their usage, they give the project a purpose. Users are encouraged to participate in the project life by providing feedback on how their needs are satisfied.
Users activities include (but are not limited to):
- Evangelisation and advocating for the project
- Informing developers of strengths and weaknesses from a new user perspective through the user discussion list or the issue list
- Providing moral support (a ‘thank you’ goes a long way)
- Writing tutorials
How to become an OpenRefine user? Download OpenRefine and start refining!
Contributors
Contributors are users contributing in concrete ways to the project. Contribution may be a one-time participation or occur over time. Contribution can take place in many ways:
- Supporting new users via the user discussion list
- Submitting patches to fix bugs or add features
- Identifying requirements
- Providing graphics and web design
- Writing and maintaining the documentation
How to become an OpenRefine contributors? The documentation for developers is a good place to start getting familiar with the code base. We invite contributors to share their feature development and patch ideas through the developer discussion list or the issue list. It is recommended to start with small patches and share your code early so the community can provide feedback and guidance.
Committers
Committers are contributors who have shown dedication to OpenRefine, have a deep understanding of the code base and project strategy and work well with contributors and users. Committers have no more authorities than contributors, and they should engage with the community through the developer discussion list or the issue list regarding their intention. However, committers have earned enough trust from the community to have direct access to the project code base without having to submit pull request. Committers seek approval after the contribution is made, rather than before.
Therefore committers:
- Help contributors via the developer discussion list.
- Merge pull requests submitted by contributors
- Have direct access to the code base
- Nominate and vote for new committers
Committers participate in the Project Management Committee (PMC). They engage in strategic planning, release planning, and approving changes to the governance model. The list of committers is available here: https://github.com/orgs/OpenRefine/people
How to become an OpenRefine Committers? Be a contributor and be nominated as a committer. OpenRefine selects and elects new committers using the Apache model. You may nominate yourself. Nomination should be sent to the developer discussion list
Decision Making Process
From a practical point of view, the direction that the project takes is controlled by the contributors, not the users (unless they're contributors too). Development is made based on contributors and committers donating their time and money to the community. OpenRefine use the Apache Decision Making process to decide the future of the project.
Lazy Concensus
The lazy consensus is used for most of the contributions ranging from bug fixes to minor changes where the contributor assumes to have the support of the community to tackle the issue.
If you are not sure you have the support of the community for a change, you can state a lazy consensus. Members of the community have then 72h to provide feedback on the proposal.
In all cases silence is consent.
Consensus Building
If you feel that lazy consensus isn't appropriate for your proposal, you can explicitly request for feedback on the developer discussion list. Building concensus help contributors and committers to gather feedback early on and pool the interest by the community for a new feature.
Everyone is invited to express their opinion of any given feature or pull request. Support is expressed using:
- +1 means: "I agree with this and will help make it happen."
- +0.9 means: 'This is a cool idea and I like it, but I don't have time/the skills necessary to help out.'
- +0 means: "I agree with this but probably won't make it happen, so my opinion is not that important."
- -0 means: "I don't agree with this, but I'm offering no alternative so my opinion is not that important."
- -0.9 means: 'I really don't like this, but I'm not going to stand in the way if everyone else wants to go ahead with it.'
- -1 means: "I don't agree and I am offering an alternative that I am able to help implement."
Open Development Process
OpenRefine development is based on user consensus and open discussion between users. Decision making must be done in a transparent, open fashion (ie. using discussion list and issue list). No decisions about the project’s direction, bug fixes or features may be done in private without community involvement and participation. Discussions must begin at the earliest possible point on a topic; the community’s participation is vital during the entire decision-making process.
This document is licensed under a Creative Commons Attribution-ShareAlike 2.0. This work is based upon "Meritocratic Governance Model" by University of Oxford, the OWIN Project Governance model and guidelines available for the Apache Community.