[Development] Changes to the Jira roles and workflow

[shane.kearns at accenture.com]

Maybe you're looking at a "triage" role, if the role is prioritizing and assigning of tasks among a team that is mostly funded by one company.

Another role we need in JIRA is "contributor".
This is somebody who is not a reviewer, but can still be assigned tasks & transition their assigned tasks through the normal workflow.
Ideally, anyone who has had a patch accepted should be given this level of access if they want it.*
For example, to work on bugs related to code they previously submitted.
Also, this covers most Nokia (or other organization) engineers who are not approvers.

I'm hoping abuse of JIRA privileges is rare, but it should also be easy to revoke them if needed.

*Some people will contribute a patch for a bug they found in their project that uses Qt, and we don't want to discourage this by giving unwanted responsibility.
> -----Original Message-----
> From: development-bounces+shane.kearns=accenture.com at qt-project.org
> [mailto:development-bounces+shane.kearns=accenture.com at qt-project.org]
> On Behalf Of Alan Alpert
> Sent: 09 February 2012 22:26
> To: development at qt-project.org
> Cc: jeg at qt-project.org
> Subject: Re: [Development] Changes to the Jira roles and workflow
>
> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development


________________________________
Subject to local law, communications with Accenture and its affiliates including telephone calls and emails (including content), may be monitored by our systems for the purposes of security and the assessment of internal compliance with Accenture policy.
______________________________________________________________________________________

www.accenture.com