[JEG] [Development] Changes to the Jira roles and workflow

[daniel.molkentin at nokia.com]

When implementing that, keep in mind that MediaWiki can make use of those roles too. I turned this off because I didn't want MediaWiki to expose Nokia Developer's internal roles (they are irrelevant). Please clean those out. What we could do is e.g. everyone who has a approver status gets elevated privileges, such as uploading images and PDFs to the wiki.

Cheers,
  Daniel

On Feb 9, 2012, at 03:58 , ext marius.storm-olsen at nokia.com<mailto:marius.storm-olsen at nokia.com> wrote:

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?

_______________________________________________
Development mailing list
Development at qt-project.org<mailto:Development at qt-project.org>
http://lists.qt-project.org/mailman/listinfo/development

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.qt-project.org/pipermail/jeg/attachments/20120209/367b16d9/attachment-0001.html