Skip to content

Latest commit

 

History

History
83 lines (54 loc) · 7.09 KB

governance.md

File metadata and controls

83 lines (54 loc) · 7.09 KB
layout title
default
OpenRefine Governance

OpenRefine Governance Model

Draft for discussion. Please sumbit pull request 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 member 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 tutorial.

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
  • submit patch 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 idea 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 earn enough trust from the community to have direct access to the project code base without having to submit pull request. Committers seeks approval after the contribution is made, rather than before.

Therefor committers

  • help contributors via the developer discussion list.
  • merge pull request submit by contributors
  • have direct access to the code base
  • nominate and vote new committer

Committers also participate in strategic planning, release planning, and approving changes to the governance model.

How to become an OpenRefine Committers? Be a contributor and be nominated as a committer. OpenRefine select and elect new committer 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 the contribution ranging from bug fixes to minor changes where the contributor assume to have the support of the community to tackle the issue.

If you are not sure to have the support of the community for a change, you can state a lazy consensus. Member 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 guideline available for Apache Community.