Re: [Development] Changes to the Jira roles and workflow

2012-02-13 Thread marius.storm-olsen 
On 02/13/2012 01:27 PM, ext 
shane.kea...@accenture.com wrote:

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.

The "contributor" role in Jira was part of the original recommendation:

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

Note the "Developer" + "Assignee" -> "Contributor" transition in the roles, 
meaning that the "Contributor" role can be assigned tasks.

--
.marius


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.



--
.marius
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-13 Thread shane.kearns 
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@qt-project.org
> [mailto:development-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of Alan Alpert
> Sent: 09 February 2012 22:26
> To: development@qt-project.org
> Cc: j...@qt-project.org
> Subject: Re: [Development] Changes to the Jira roles and workflow
>
> On Thu, 9 Feb 2012 12:58:40 ext marius.storm-ol...@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@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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread Alan Alpert 
On Thu, 9 Feb 2012 12:58:40 ext marius.storm-ol...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread shane.kearns 
It's easy to make a report on your personal dashboard to show issues reported 
on a given (set of) component(s).
It means polling rather than email notification, but the email notifications 
have poor signal:noise ratio.

> -Original Message-
> From: development-bounces+shane.kearns=accenture@qt-project.org
> [mailto:development-bounces+shane.kearns=accenture@qt-project.org]
> On Behalf Of marius.storm-ol...@nokia.com
> Sent: Thursday, February 09, 2012 11:47
> To: michael.godd...@nokia.com
> Cc: thiago.macie...@intel.com; development@qt-project.org
> Subject: Re: [Development] Changes to the Jira roles and workflow
>
> On 09/02/2012 05:41, Goddard Michael (Nokia-MP/Brisbane) wrote:
> >> Assigning new tasks "unassigned" will not notify the maintainer
> >> about issues in the modules that have come up, and the maintainer
> >> will not by notified when someone takes a task and starts working
> >> on it.
> >
> > Surely this is something that JIRA could support?  Watching a
> > component or similar?  (also can Gerrit do this too?)
>
> Not by default. But there is a 3rdparty pluging to allow adding Watcher
> on components:
>
> https://studio.plugins.atlassian.com/wiki/display/JCWP/JIRA+Component+Wa
> tcher+Plugin
>
> --
> .marius
> ___
> Development mailing list
> Development@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

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread andre.poenitz 
Storm-Olsen Marius wrote:
> Thiago Macieira wrote:
> > Agreed. As a Maintainer, I really don't want tons of tasks assigned
> > to me and in idle state. It would make my life difficult because I
> > can't find the tasks I want to work on. And it would get people
> > screaming at me for not looking at their tasks.
> 
> I think the argument against that is that Maintainers should know what
> goes on in their modules.
> 
> Assigning new tasks "unassigned" will not notify the maintainer about
> issues in the modules that have come up, and the maintainer will not by
> notified when someone takes a task and starts working on it.

These are exactly the reasons for the Qt Creator project to use
default assignment to the maintainer. Sure, there's a slight chance 
that there will be a "P5, nice to have, but I really don't have the time to
do it myself" case where unassigning is one way to handle it, but the
majority of tasks _is_ properly assigned the automated way for us.

I also think it helps to feel responsible for a particular task if it's 
assigned to me. It's much easier to ignore tasks otherwise, with the
net effect of tasks piling up quicker than they are solved.

> (/me has no strong feelings either way, just highlighting the different
> view points)

Thanks ;-)

Andre'
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread marius.storm-olsen 
On 09/02/2012 05:41, Goddard Michael (Nokia-MP/Brisbane) wrote:
>> Assigning new tasks "unassigned" will not notify the maintainer
>> about issues in the modules that have come up, and the maintainer
>> will not by notified when someone takes a task and starts working
>> on it.
>
> Surely this is something that JIRA could support?  Watching a
> component or similar?  (also can Gerrit do this too?)

Not by default. But there is a 3rdparty pluging to allow adding Watcher 
on components:
 
https://studio.plugins.atlassian.com/wiki/display/JCWP/JIRA+Component+Watcher+Plugin

-- 
.marius
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread michael.goddard 
Howdy,

>Assigning new tasks "unassigned" will not notify the maintainer about
>issues in the modules that have come up, and the maintainer will not by
>notified when someone takes a task and starts working on it.

Surely this is something that JIRA could support?  Watching a component or
similar?  (also can Gerrit do this too?)

Cheers,
MichaelG

___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread marius.storm-olsen 
On 09/02/2012 04:33, ext Thiago Macieira wrote:
> On Thursday, 9 de February de 2012 10.20.47, bradley.hug...@nokia.com
> wrote:
>>> 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?
>> Unassigned should be the default. When someone picks up the task,
>> they should assign it to themselves. Anything else is misleading.
>
> Agreed. As a Maintainer, I really don't want tons of tasks assigned
> to me and in idle state. It would make my life difficult because I
> can't find the tasks I want to work on. And it would get people
> screaming at me for not looking at their tasks.

I think the argument against that is that Maintainers should know what 
goes on in their modules.

Assigning new tasks "unassigned" will not notify the maintainer about 
issues in the modules that have come up, and the maintainer will not by 
notified when someone takes a task and starts working on it.

(/me has no strong feelings either way, just highlighting the different 
view points)

-- 
.marius
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread Daniel Teske 
> > 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?
> 
> Unassigned should be the default. When someone picks up the task, they
> should assign it to themselves. Anything else is misleading.
I don't think the Creator team wants to change away from the current default 
assignee system for bugs in Creator, as that works pretty well for us.

daniel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread Thiago Macieira 
On Thursday, 9 de February de 2012 10.20.47, bradley.hug...@nokia.com wrote:
> > 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?
> Unassigned should be the default. When someone picks up the task, they
> should assign it to themselves. Anything else is misleading.

Agreed. As a Maintainer, I really don't want tons of tasks assigned to me and
in idle state. It would make my life difficult because I can't find the tasks I
want to work on. And it would get people screaming at me for not looking at
their tasks.

--
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center
 Intel Sweden AB - Registration Number: 556189-6027
 Knarrarnäsgatan 15, 164 40 Kista, Stockholm, Sweden


signature.asc
Description: This is a digitally signed message part.
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

Re: [Development] Changes to the Jira roles and workflow

2012-02-09 Thread bradley.hughes 
On 09 Feb, 2012, at 03:58 , ext marius.storm-ol...@nokia.com wrote: 
> Jira changes recommendations

[snip]

> 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.

I think such tasks should become Unassigned.

[snip]

> 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?

Unassigned should be the default. When someone picks up the task, they should 
assign it to themselves. Anything else is misleading.

--
Bradley T. Hughes
bradley.hug...@nokia.com




___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development

[Development] Changes to the Jira roles and workflow

2012-02-08 Thread marius.storm-olsen 
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 (j...@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@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development