IntroductionThe purpose of this page is to document the issue-tracking process of Pygr: what the meaning of different status tags is and how we define transitions between them, how to indicate a developer/reviewer is associated with an issue etc. DetailsAn Overview of Status ValuesThe following values are presently considered valid for Pygr issues: Open issues - New - just submitted, hasn't been confirmed yet
- Accepted - the issue has been acknowledged by a developer
- Assigned - a developer has been assigned to the issue and is likely working on it
- FixedNeedsReview - a fix has been provided but must be independently validated
- ReviewedNeedsCommit - the fix has been validated but must be propagated into the source code before the issue can be closed
Closed issues - Closed - the issue has been addressed, the fix has been validated
- Invalid - either the issue is not a problem with Pygr or not enough information has been provided to determine this
- WontFix - the issue has been recognised as valid but no action will be taken to address it
- Duplicate - this issue duplicates, significantly overlaps with or is a subset of an existing one
Additionally, an open issue can be blocked - meaning that its further progress depends on successful resolution of another one or ones. This is indicated using a dedicated field and does not alter the status. Owners and ReviewersThe owner of an issue is a developer assigned to fixing it. He or she is indicated by the "Owner" field of the issue. By default an issue has got no owner. The reviewer of an issue is a person expected to validate fixes provided for that issue by the owner. By default this will be the person who reported the issue; however, keep in mind the reviewer and the owner of an issue must NOT be the same person. The reviewer is indicated using labels ("reviewby-name") as well as by being the first on the "Cc" list. Filing and AssigningA newly-filed issue should normally have the status New. A possible exception to this rule involves issues reported by developers in the course of their work (i.e. when one is 100% certain they are valid), in which case one can file as Accepted or, when the person in question is already working on the fix, Assigned. Open issues without owners, i.e. all New and Accepted ones, should have their respective owner field set to pygr-bug-wranglers@googlegroups.com, a mailing list of people responsible for managing issues, thus letting them know an issue has appeared which needs an owner. After an issue has been assigned an owner, one of the issue managers must update the issue's status to Assigned, at the same time listing the owner in the appropriate field. Submission of FixesFor Pygr developers the preferred form of fix submission is to create a dedicated branch issueXXX in our main GitHub repository (git://github.com/ctb/pygr.git) and commit all code there. In case of everyone without write access to that repository, all fixes should be submitted, in the form of patch files (preferably in the format generated by the git format-patch command, preserving commit history of development work; this should be observed particularly rigorously in case of large-scale fixes), as attachments to issue comments. Regardless of the method, if both functional and non-functional changes are made by the fix, they should be provided as separate patches/commits. After the fix has been posted, the issue should be advanced - normally by the developer who submits the fix, otherwise by one of the project managers - to the FixedNeedsReview stage. Not that a reviewer must be assigned before the issue can be advanced thus. The review is to be provided as a comment or comments on the issue and accompanied by an appropriate change of status (see below). If the reviewer submits any code him-/herself, this code must be reviewed too before the issue can be considered resolved. Normally it should be enough for the owner to sign off the changes made by the reviewer, if however a conflict arises between the two the issue should then be assigned to a new, independent reviewer. Note that such a reassignment is only necessary if the reviewer submits code; if the reviewer replies with comments but actual changes to the code are made by the owner, no such change is necessary. Should the fix be deemed incomplete or incorrect, the issue should be demoted back to Accepted so that it is clear it must still be worked on. Once the (final) reviewer is happy with the fix, he should update the issue's status ReviewedNeedsCommit or Closed, depending on whether the relevant code to the next stage. If that is not possible for some reason, it should be done by one of the project managers. Issues tagged ReviewedNeedsCommit should be closed as soon as the relevant changes have made their way into the Git repository, by the person who performed the commit. The relevant GitHub branch should be deleted at that time as well. MiscellaneousAny situations not discussed here will be resolved by project managers on the basis of communication with involved parties and, above all, common sense.
|
Sign in to add a comment
