Community and Contributions
This is a work-in-progress attempt to document and explain how the openFrameworks community works in a way that helps it function more smoothly and openly. Related pages:
Missing information:
- What is expected of team contributors?
- How do "projects" fit into this?
- How do we treat each other to make sure everyone feels comfortable and respected?
- What can we explain here to make new contributors feel welcome?
CouchDB has some very clear bylaws and CoC for describing their community.
There are three categories of contributors in the openFrameworks community:
- The core: Zach Lieberman @ofZach, Theo Watson @ofTheo, Arturo Castro @arturoc, sometimes called “the core” or, affectionately, “TAZ”. This group has not changed since 2007, and is not expected to change.
- Team contributors: approximately 50 people on one of the openFrameworks GitHub teams. This group changes regularly. To join, ask the community organizer Kyle McDonald @kylemcdonald or any of the core members.
- Anyone inactive for more than a year may be removed, but may join again at any time. Non-team contributors, including all other openFrameworks users.
To develop openFrameworks together, we have discussions: on the of-dev mailing list, in monthly IRC meetings, sometimes in person, and mostly on GitHub.
Anyone may suggest changes to anything about OF and how it works, but we don’t make changes until some time has passed for people to potentially offer advice or ideas. This is sometimes called "lazy consensus".
We use issues as a way to track what we want to change. Issues are also a way to have a discussion about specifications for a change. Anyone with a GitHub account may submit an issue. If no one suggests fundamental changes or problems with an issue, a pull request (PR) may be submitted with the expectation it will be merged. Disagreements and suggestions of trivial changes ("bikeshedding") may be incorporated or ignored as decided by the person taking responsibility for the work.
After the specifications have been agreed on in an issue, PRs are a way to start discussion about an implementation. If no one suggests fundamental changes or problems with a PR, it may be merged after one week. Again, bikeshedding is resolved by the person taking responsibility for the work. Changes to openFrameworks must be made by PR unless they are an emergency/mistake, or very small "one line" fixes, in which case they may be fixed by directly pushing to the repository.
The core is not restricted to these rules. While they almost always act like other team contributors, they can also ignore disagreements, or make changes without waiting.