Code Contribution Workflow
This page describes the contribution workflow for the openFrameworks core.
Contribution to openFrameworks has been historically restricted to the core developers (Zach, Theo and Arturo), using a private Subversion repository (and before that, ZIP files). In late 2009, development was moved to GitHub. In early 2011 the first openFrameworks developers conference was held, hosted by the STUDIO for Creative Inquiry at Carnegie Mellon University. While contributed code had been pulled throughout 2010, this conference represented the first major community-supported development of openFrameworks. In mid 2011 openFrameworks 007 was released, containing contributions from a huge network of people. Throughout 2011 and into 2012 the core received an increased number of contributions via pull requests, but because the expectations and requirements for contributed code were not explicit, a large number of pull requests were ignored. This was primarily because they lacked context, required testing or added features that were not fully discussed or formulated. As a result, in early 2012, at the second openFrameworks developers conference was held at OmniCorpDetroit, we resolved the essentials of the following workflow, specifically the roles and responsibilities of section leaders with regards to core code.
The administrators of the repository are comprised of the core developers and the section leaders. The official list of section leaders is available on the main About page.
The goal of the section leader is to try to help gather the right people together to get consensus, and to bounce ideas off of each other, cut down on repetitive development, and build better tools together.
To that end, some questions they should consider:
- what are the common questions / issues around the section?
- who are the people in the community who are interested in this topic?
- what addons already exist ? what kind of addons are needed ?
- what issues exist?
- what sample code in this topic exists?
- what kind of building blocks in OF would help out addons in this topic or cut down on repetition?
- what longer term structural changes would be useful or beneficial?
- what other approaches to this topic exist, and what are their strengths and weaknesses?
The section leaders have a number of responsibilities and freedoms:
- All changes (bug fixes and feature requests) should first be submitted as issues. Pull requests for features developed without discussion or approval may not be considered.
- If you put "Closes #" (or a similar message) in a commit message, the issue will be closed automatically as soon as that commit is merged in. Sadly, this doesn't work in pull request descriptions.
- Simple bug fixes may be merged by anyone.
- Leaders should be active in commenting on, reviewing and analyzing any issues or pull requests that fall under their section.
- Feature proposals will be collected, discussed and approved during a monthly IRC chat.
- Approved features, submitted as pull requests, will be reviewed by the core before being merged.
- All development should be in forks, and submitted as a pull request, except the most minimal bug fix merges.
- If you merge a PR, please scan the PR page for any mention of issues which are closed by the PR, and close them if appropriate. Automated closing only works in the commit message, see second bullet.
Section leaders should follow the openFrameworks git workflow, the openFrameworks Coding style guidelines and the Issue and pull request management details document.