Team, Gerald K raised a good point: what do you do in the event that you have an issue that you want to document, but which won't be resolved until some indefinite release in the future?
To deal with this case, I've added a version to all of the projects called "Future Release". So, if you don't want to assign the issue to Colorado 1.0, 2.0, 3.0, or D, then please assign it to this version. Please, only assign to this version if you are fairly certain that you won't resolve the issue until after the D release. Note that one implication of doing this is that you *must* periodically review the issues assigned to 'Future Release' and either assign them to a planned release, or close them. On projects I've worked on in the past, we often did this toward the end of a release, in preparation for the start of the next release. So, why not just leave "fix version" empty in this case? The answer is that we need to be able to differentiate between a positive decision to assign an issue to an indefinite future release, and simply forgetting to fill in the "fix version" field. Let me know if you have any questions. David On Thu, Aug 18, 2016 at 10:57 AM, David McBride < dmcbr...@linuxfoundation.org> wrote: > Team, > > As you know, I've been asking PTLs to update their JIRA projects to > improve accuracy and to enable use of JIRA as a project management tool. > Note that these updates will also improve the accuracy and relevance of > JIRA reports produced by Bitergia. > > Essentially, I'm asking the team to follow four basic principles: > > 1. All JIRA issues must be assigned to a common version string, using > the "fix version" field. > 2. Commit messages must include a reference to the issue ID. > 3. JIRA issue status should be updated whenever the status changes. > 4. All JIRA issues assigned to a particular release must either be > closed, or pushed out to a future release (i.e. update "fix version") by > the release date. > > In order to track progress for 1 and 3, I've put together a script that > pulls data from JIRA. The first report is attached. Please locate your > project in the report and make plans to resolve any issues that are > identified. > > Notes on the report: > > - "no versions" - indicates that the admin page contains no version > strings for selection in the "fix version" field. > - To fix this, add the common version strings to the "Versions" > section on the project admin page. > - "Version list NOT correct" - the project contains version strings, > but is missing one or more of the *common* version strings. > - All projects must use the common set of version strings. > - "Unassigned issues found: [list]" - the project has issues where the > "fix version" field is empty. > - Remember, all issues must be assignee to a version, using the > "fix version" field. > - About 85% of the projects have unassigned issues. > - There are two solutions to this: (a) educate your project team to > set the field when they create the ticket; (b) when you conduct a bug > scrub, or triage, search your JIRA project for issues that are > unassigned > and update them. > > *Kudos! * Note that the Domino, Models, and IPv6 projects all have the > correct version list and no unassigned issues. An inspiration to us all :) > > Final note: this script is new, so it wouldn't surprise me if there are > errors. If you see something that doesn't make sense, please let me know. > > David > > -- > *David McBride* > Release Manager, OPNFV > Mobile: +1.805.276.8018 > Email/Google Talk: dmcbr...@linuxfoundation.org > Skype: davidjmcbride1 > IRC: dmcbride > -- *David McBride* Release Manager, OPNFV Mobile: +1.805.276.8018 Email/Google Talk: dmcbr...@linuxfoundation.org Skype: davidjmcbride1 IRC: dmcbride
_______________________________________________ opnfv-tech-discuss mailing list opnfv-tech-discuss@lists.opnfv.org https://lists.opnfv.org/mailman/listinfo/opnfv-tech-discuss
