Issues are at the heart of the Cappuccino project. They tell us where we are in terms of what needs to be fixed, and where we want to go in terms of new features to be added. From the point when an issue is created to the point where it is closed, there is a well-defined path it follows.
A picture is worth a thousand words, so here is a graphical representation of the issue lifecycle:
At the highest level, an issue is either Open or Closed. At the beginning of an issue’s lifecycle, a newly created issue is Open, and it remains Open until it enters one of the “Closed” states pictured above, which is the end of its lifecycle.
Within the high level Open and Closed states, an issue is either in the Review phase or in the Resolution phase. Within a phase, an issue may have one or more tags that identify where it is within the lifecycle and what actions are necessary to advance to the next step. Issue lifecycle tags begin with “#”, such as “#new” and “#accepted”. Issues may also have labels that do not begin with “#”, which are category labels, such as “bug” and “feature”.
Since a picture is worth a thousand words, here is the thousand-word description of the issue lifecycle.
When you create a new issue, its state is Open and it is in the Review phase. An automated script gives it the #new tag, adds it to the “Someday” milestone, adds the #needs-patch tag if it is not a pull request, and the core team is notified.
A designated Reviewer or core team member reviews the issue and the following actions are taken:
At this point, there are a couple of paths the issue might take.
Sometimes accepting a bug report or feature request requires an architectural or implementation design decision. For architectural decisions, the question is whether the issue fits in with the overall design of the Cappuccino frameworks. For implementation decisions, the question is whether it is technically feasible to implement the fix, and if so how to do so.
To make these decisions, we bring the design decisions up for a vote, perhaps with some preliminary discussion. For more information on the voting process, see How We Make Decisions.
If the vote indicates an issue will be accepted, it is labeled #accepted and enters the Resolution phase. Otherwise it is labeled #wont-fix and closed, or it is added to the “Someday” milestone and left open.
Once an issue has been accepted, now it has to be resolved by fixing the bug or implementing the feature. This is where we really rely on the community to help with the coding!
Once a patch is submitted, either as a gist or as a pull request, then the code has to be reviewed by a designated Reviewer or core team member.
Once the code is free of any #needs- tags, it is labeled #ready-to-commit. As the final step, a core team member commits the code to the master branch, labels the issue #fixed, and closes the issue. Thus ends the lifecycle of an issue.
If you see an issue that you especially want to have fixed or implemented, you can vote “bump” it by adding a comment that consists of nothing more than “+1”. This will get picked up automatically and the title of the issue will be updated to show the latest bump count. In addition, the core team will be notified so we have an idea which issues are a priority for the community.
We strive to be as transparent and democratic as possible, so when a new feature or design decision will have a significant impact on the community, we may ask for an informal vote on the objectivej or objectivej-dev mailing list. The subject of the vote will be prefixed by “[VOTE] ”.
In these votes we follow the voting style commonly used by open source projects, where votes are given as +1, +0, -0, or -1. Roughly translated, these votes mean:
Although these votes are informal, they will be taken very seriously. After a suitable voting period (usually a week or two), if an obvious consensus emerges we will follow the votes.
However, consensus is not always possible. If consensus cannot be reached, or if the discussion fizzles out without arriving at a concrete decision, we use a more formal process.
Any core developer may call for a formal vote using the same voting mechanism outlined above. The subject of these formal votes will be prefixed with “[CORE-VOTE] ”. These formal votes differ from informal votes in that although they are conducted in public, only votes by the core team count. A proposition will be considered carried by the core team if:
When calling for a vote, the caller should specify a deadline by which votes must be received, with one week being the minimum amount of time.
Since this process allows any core developer to veto a proposal, any -1 votes must be accompanied by a thorough explanation of what it would take to convert the -1 into at least a +0.
Whenever possible, these formal votes will be announced and held in public on the objectivej or objectivej-dev mailing list. However, very sensitive or contentious issues — including votes on new core developers — may be held in private, using the same rules.