[Development] Changes to the Jira roles and workflow

marius.storm-olsen at nokia.com marius.storm-olsen at nokia.com
Thu Feb 9 03:58:40 CET 2012


Hi,



As part of moving Jira, the bugtracker, from being a Nokia system to a Qt Project system, it is only prudent to also look at the roles and workflows of the system. This mail will describe the changes suggested by the former Jira Expert Group which was a Nokia only entity at the time. My suggestion is that we discuss that recommendation here on the development ML, and let the new Jira Expert Group (jeg at qt-project.org<mailto:jeg at qt-project.org>) come to a conclusion. Once the new JEG has come to an agreement, I will send their change specification over to be implemented by our consultants responsible for maintaining Jira.



What follows is the recommendation of the previous Jira Expert Group (JEG).



--

.marius







Jira changes recommendations



Map old roles over to OG roles

The current suggestion is:

Reports -> User

Developer -> Contributor

Assignee -> Contributor

QA -> Approvers

RM -> Maintainers <- note, discussion over this



There is some discussion over if we should burden maintainers with Release Management work.

There is a suggestion of a new workflow "Nokia Engineer" - no privileges in Gerrit only in Jira.



Change workflows

Main point: do the current states, transitions, roles and different issue types fit the OGM?



So far the discussion has yielded that Verified and Release states can be merged If there is a clear policy wherein the contributors and approvers are required to get approval about API additions in particular.



It has been put forward that a "Needs more info" state is needed, since "Withdrawn" is closed and does not match the use-case where you just need more info. Already exists in some workflows.



Transfer ownership of issues

Early on there was a suggestion that a Module attribute was created to map directly to maintainers. Later discussions implied that this is not necessary since Components already maps directly to modules and so to maintainers. Also that it would mean introducing more complexity and we should probably not do it (which is where the decision stands now).



We need to transfer ownership from all the issues now owned by the team users (earth, air,  ...). This can be done by mapping components to maintainers (some cleanup is needed). The team users are obsolete and needs to go.



Closing issues

There's so far a reasonable consensus over that when a change is approved or merged in Gerrit it should be closed in Jira.



Default Assignee

There is call for discussion around default assignee - is it the module maintainer? Which tasks are up for grabs if everything new goes to the maintainer?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20120209/72cc255a/attachment.html>


More information about the Development mailing list