[Development] Changes to the Jira roles and workflow
alan.alpert at nokia.com
Thu Feb 9 23:26:08 CET 2012
On Thu, 9 Feb 2012 12:58:40 ext marius.storm-olsen at nokia.com wrote:
> 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.
That role might be useful, but please don't call it "Nokia Engineer". Even if
we don't expect anyone to ever volunteer to do task management roles, Qt as an
open project could grow to other companies. Calling it "Task Manager" or
"Issue Secretary" (or something along those lines that's not a joke ;) ) will
mitigate the risk of having to change the name again later.
> 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
The theory I was taught was that you don't use your 'tasks assigned to me'
list as your list of your in-progress bugs. You use your 'tasks assigned to me
and listed as in-progress' for that list. So assignment merely means "If
someone's going to look at this bug, it'll probably be this guy first". If
you're working on a bug and don't want people to take it away, you mark it as
in-progress. Then the tasks which are up for grabs are the ones assigned to
the maintainer (or anyone, actually) which are not marked as 'in-progress'.
On the 'unassigned' suggestion, I think that could only work if there's an
easy way to find the correct maintainer for a component. Currently the table
in qt-project contains some data, which is nice, but it's just not convenient
enough or obvious enough to work with JIRA. Default assignee has basically
been the way people find maintainers for bug reporting (at least), if you take
that away then something else is needed.
Nokia, Qt Development Frameworks
More information about the Development