[Development] Changes to the Jira roles and workflow

[Alan Alpert]

On Thu, 9 Feb 2012 12:58:40 ext marius.storm-olsen at nokia.com wrote:
> Hi,
>
> ... 
> 
> 
> 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
> maintainer?

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.

-- 
Alan Alpert
Senior Engineer
Nokia, Qt Development Frameworks