Ideas for Improving our Jira Workflow

[Sharan-F]

Hi All

We have an amazing number of Jiras open and because we have so many it's getting very confusing as to what are the priorities and things are getting clogged up.

I've got a few initial ideas and suggestions that could maybe help improve the workflow

1) Highlight Parked / On Hold Jiras
We have quite a few Jira issues that are 'parked' or 'on hold' – so it would be good if these were clearly identified so that if people come across them they know that they are not being worked on (and the reason).

We could look at adding a new status, a flag or a label that could hold this information.

2) QA Review for New Jiras
I think it would also be good to look at introducing some type of review stage for newly created issues. This also could give us a bit of QA to make sure that there is enough information needed for the task to be worked on. It could also be then allocated to a workstream.  

3) Define Workstreams
We have a good idea of the areas that we want to focus so it should be relatively easy to setup some workstreams.  I'd like to explore the idea of workstreams a bit more because it could be something that could be an entire sprint, an issue category or it could be the equivalent of a planned future release.

I know Jira allow us to define a Roadmap and versions and that we already have something setup that helps us with our release management (I.e.automatically incorporates all the Jiras applied to a version) that we don't want to break – so this might need more investigation

4) Review of Old Jiras
One of things that we've had hanging around for ages is a lot of old Jiras. At the moment I think Jacques takes on a few at a time, so it could be good to get some other volunteers and start looking at these and either closing them, parking them or allocating them to a workstream.

These are a few of the ideas I had in mind – the main objective is to make Jira into a useful tool for help us with our workflow.

Please feel free to let me have your feedback and comments, and if anyone else has other ideas and suggestion to share, then please do.

Thanks
Sharan

[Jacques Le Roux]

Hi Sharan, inline...

Le 15/07/2016 à 11:53, Sharan Foga a écrit :

> Hi All
>
> We have an amazing number of Jiras open and because we have so many it's getting very confusing as to what are the priorities and things are getting clogged up.
>
> I've got a few initial ideas and suggestions that could maybe help improve the workflow
>
> 1) Highlight Parked / On Hold Jiras
> We have quite a few Jira issues that are 'parked' or 'on hold' – so it would be good if these were clearly identified so that if people come across them they know that they are not being worked on (and the reason).
>
> We could look at adding a new status, a flag or a label that could hold this information.

For those we could maybe close them with the "Later" status? So nothing to do (but closing them), we did that already, not sure it completely fits for
all cases though...

> 2) QA Review for New Jiras
> I think it would also be good to look at introducing some type of review stage for newly created issues. This also could give us a bit of QA to make sure that there is enough information needed for the task to be worked on. It could also be then allocated to a workstream.

Are we not already (slowly) doing it? Do we really need a policy or (a) tool/s for that? I fear we don't miss policies but rather free time from
contributors...

> 3) Define Workstreams
> We have a good idea of the areas that we want to focus so it should be relatively easy to setup some workstreams.  I'd like to explore the idea of workstreams a bit more because it could be something that could be an entire sprint, an issue category or it could be the equivalent of a planned future release.
>
> I know Jira allow us to define a Roadmap and versions and that we already have something setup that helps us with our release management (I.e.automatically incorporates all the Jiras applied to a version) that we don't want to break – so this might need more investigation
>
> 4) Review of Old Jiras
> One of things that we've had hanging around for ages is a lot of old Jiras. At the moment I think Jacques takes on a few at a time, so it could be good to get some other volunteers and start looking at these and either closing them, parking them or allocating them to a workstream.

This relates to point 1

> These are a few of the ideas I had in mind – the main objective is to make Jira into a useful tool for help us with our workflow.
>
> Please feel free to let me have your feedback and comments, and if anyone else has other ideas and suggestion to share, then please do.

Thanks for this initiative Sharan!

Jacques

> Thanks
> Sharan
>
>

[Pierre Smits]

Hi Sharan, All,

Please see inline.

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Fri, Jul 15, 2016 at 11:53 AM, Sharan Foga <[hidden email]> wrote:

> Hi All
>
> We have an amazing number of Jiras open and because we have so many it's
> getting very confusing as to what are the priorities and things are getting
> clogged up.
>


> I've got a few initial ideas and suggestions that could maybe help improve
> the workflow
>

We should differentiate between bugs and the other types of JIRA issues
(improvement, new feature and wish) for single or placeholder issues. The
latter type is a depiction of a potential future scenario (improvement
being closest to now - direct related to existing code and wish being the
farthest away) intended to enhance the user experience with new
functionality.

So, here I am focussing on the issues typed as Bug in JIRA.



>
> 1) Highlight Parked / On Hold Jiras
> We have quite a few Jira issues that are 'parked' or 'on hold' – so it
> would be good if these were clearly identified so that if people come
> across them they know that they are not being worked on (and the reason).
>
> We could look at adding a new status, a flag or a label that could hold
> this information.
>

Not all bugs are equally important. That is why we have the Priority field,
with a limited set of choices. But there is a difference in impact. A bug
might be of a technical nature, which is easy to prove with an error
report. Or it might be of a business nature: it works fine technically, but
is unacceptable in a particular business domain due to GRC policies and
procedures. I refer to OFBIZ-7796
<https://issues.apache.org/jira/browse/OFBIZ-7796>, OFBIZ-7767
<https://issues.apache.org/jira/browse/OFBIZ-7767> and OFBIZ-7783
<https://issues.apache.org/jira/browse/OFBIZ-7783> as examples. Some will
call these improvements as well, but these kinds of issues put a serious
barrier regarding adoptability.

So my suggestion is to be able to classify better: e.g. add 'business' and
'techinal' as choices to the mix.

>
> 2) QA Review for New Jiras
> I think it would also be good to look at introducing some type of review
> stage for newly created issues. This also could give us a bit of QA to make
> sure that there is enough information needed for the task to be worked on.
> It could also be then allocated to a workstream.
>
> 3) Define Workstreams
> We have a good idea of the areas that we want to focus so it should be
> relatively easy to setup some workstreams.  I'd like to explore the idea of
> workstreams a bit more because it could be something that could be an
> entire sprint, an issue category or it could be the equivalent of a planned
> future release.
>
> I know Jira allow us to define a Roadmap and versions and that we already
> have something setup that helps us with our release management
> (I.e.automatically incorporates all the Jiras applied to a version) that we
> don't want to break – so this might need more investigation
>
>

https://www.youtube.com/watch?v=7GL6LH6ufhM



> 4) Review of Old Jiras
> One of things that we've had hanging around for ages is a lot of old
> Jiras. At the moment I think Jacques takes on a few at a time, so it could
> be good to get some other volunteers and start looking at these and either
> closing them, parking them or allocating them to a workstream.
>

I have been reviewing old issues regularly over the past few years, and
some I could help move forward. It is a tedious job, but one must not shy
away from it. Each contributor can start with the ones he assigned himself
to. And then work his way, slowly but surely through the list of issue
related to the subject he cares about. I remember us having a wiki page
indicating who was interested in what and who was willing to work on what.
A page I now can't find that easily. Maybe we could revisit that and see if
we can bring that back to life.


>
> These are a few of the ideas I had in mind – the main objective is to make
> Jira into a useful tool for help us with our workflow.
>
> Please feel free to let me have your feedback and comments, and if anyone
> else has other ideas and suggestion to share, then please do.
>

Thanks for sharing. Great initiative.


>
> Thanks
> Sharan
>
>

[Jacques Le Roux]

Le 15/07/2016 à 16:12, Pierre Smits a écrit :
>   I remember us having a wiki page
> indicating who was interested in what and who was willing to work on what.
> A page I now can't find that easily. Maybe we could revisit that and see if
> we can bring that back to life.
This ?
https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document

Jacques

[Pierre Smits]

I was indeed referring to that document. Though that only addresses
improvements, new features and wishes, it can be tied in with a (loosely)
planning [1] regarding future releases [2] and existing components. Bugs
could thus be tied in the same way.

[1] You should take this as potential intent, not a written commitment of
the interested contributor(s).
[2] As Taher expressed here
https://issues.apache.org/jira/browse/OFBIZ-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379018#comment-15379018
visavis a possible intent to work on theming improvement for a release
after r16.x ( I won't put a gun to his head, as every effort applied is
volunteer work as much as time permits).

Best regards,

Pierre Smits

ORRTIZ.COM <http://www.orrtiz.com>
OFBiz based solutions & services

OFBiz Extensions Marketplace
http://oem.ofbizci.net/oci-2/

On Fri, Jul 15, 2016 at 7:27 PM, Jacques Le Roux <
[hidden email]> wrote:

> Le 15/07/2016 à 16:12, Pierre Smits a écrit :
>
>>   I remember us having a wiki page
>> indicating who was interested in what and who was willing to work on what.
>> A page I now can't find that easily. Maybe we could revisit that and see
>> if
>> we can bring that back to life.
>>
> This ?
>
> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>
> Jacques
>
>

[Jacques Le Roux]

Hi Sharan, All,

I just did something which might help us, at least on your point 4. I have enabled the Jira Service Desk option so we have now a SLA feature (Service
Level Agreement)
I used the default, can be changed at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/sla (need more work and especially agreement, to be
discussed I guess)
It shows at the top right of each issue
There is also queues at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/queues

I don't think we want to change that https://issues.apache.org/jira/servicedesk/agent/OFBIZ/people
I don't think we need https://issues.apache.org/jira/servicedesk/agent/OFBIZ/customer I guess we can customize to have something like
https://issues.apache.org/jira/servicedesk/customer/portal/1, related with line above, useful for us? I guess not.

There are reports at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/reports

I think this could be usefully used to organise and prioritise our issues, beginning by our own.

What do  you think?

Jacques


Le 15/07/2016 à 12:03, Jacques Le Roux a écrit :

> Hi Sharan, inline...
>
> Le 15/07/2016 à 11:53, Sharan Foga a écrit :
>
>> Hi All
>>
>> We have an amazing number of Jiras open and because we have so many it's getting very confusing as to what are the priorities and things are
>> getting clogged up.
>>
>> I've got a few initial ideas and suggestions that could maybe help improve the workflow
>>
>> 1) Highlight Parked / On Hold Jiras
>> We have quite a few Jira issues that are 'parked' or 'on hold' – so it would be good if these were clearly identified so that if people come
>> across them they know that they are not being worked on (and the reason).
>>
>> We could look at adding a new status, a flag or a label that could hold this information.
>
> For those we could maybe close them with the "Later" status? So nothing to do (but closing them), we did that already, not sure it completely fits
> for all cases though...
>
>> 2) QA Review for New Jiras
>> I think it would also be good to look at introducing some type of review stage for newly created issues. This also could give us a bit of QA to
>> make sure that there is enough information needed for the task to be worked on. It could also be then allocated to a workstream.
>
> Are we not already (slowly) doing it? Do we really need a policy or (a) tool/s for that? I fear we don't miss policies but rather free time from
> contributors...
>
>> 3) Define Workstreams
>> We have a good idea of the areas that we want to focus so it should be relatively easy to setup some workstreams.  I'd like to explore the idea of
>> workstreams a bit more because it could be something that could be an entire sprint, an issue category or it could be the equivalent of a planned
>> future release.
>>
>> I know Jira allow us to define a Roadmap and versions and that we already have something setup that helps us with our release management
>> (I.e.automatically incorporates all the Jiras applied to a version) that we don't want to break – so this might need more investigation
>>
>> 4) Review of Old Jiras
>> One of things that we've had hanging around for ages is a lot of old Jiras. At the moment I think Jacques takes on a few at a time, so it could be
>> good to get some other volunteers and start looking at these and either closing them, parking them or allocating them to a workstream.
>
> This relates to point 1
>
>> These are a few of the ideas I had in mind – the main objective is to make Jira into a useful tool for help us with our workflow.
>>
>> Please feel free to let me have your feedback and comments, and if anyone else has other ideas and suggestion to share, then please do.
>
> Thanks for this initiative Sharan!
>
> Jacques
>
>> Thanks
>> Sharan
>>
>>
>
>

[Jacques Le Roux]

Le 15/07/2016 à 16:12, Pierre Smits a écrit :

>> 1) Highlight Parked / On Hold Jiras
>> >We have quite a few Jira issues that are 'parked' or 'on hold' – so it
>> >would be good if these were clearly identified so that if people come
>> >across them they know that they are not being worked on (and the reason).
>> >
>> >We could look at adding a new status, a flag or a label that could hold
>> >this information.
>> >
> Not all bugs are equally important. That is why we have the Priority field,
> with a limited set of choices. But there is a difference in impact. A bug
> might be of a technical nature, which is easy to prove with an error
> report. Or it might be of a business nature: it works fine technically, but
> is unacceptable in a particular business domain due to GRC policies and
> procedures. I refer to OFBIZ-7796
> <https://issues.apache.org/jira/browse/OFBIZ-7796>, OFBIZ-7767
> <https://issues.apache.org/jira/browse/OFBIZ-7767>  and OFBIZ-7783
> <https://issues.apache.org/jira/browse/OFBIZ-7783>  as examples. Some will
> call these improvements as well, but these kinds of issues put a serious
> barrier regarding adoptability.
>
> So my suggestion is to be able to classify better: e.g. add 'business' and
> 'techinal' as choices to the mix.
>
>

How would you do that in Jira?

Jacques

[Jacques Le Roux]

I believe we need more automated tools, if we have to do to much things by hand (almost) nothing will ever be done

Jacques


Le 15/07/2016 à 19:38, Pierre Smits a écrit :

> I was indeed referring to that document. Though that only addresses
> improvements, new features and wishes, it can be tied in with a (loosely)
> planning [1] regarding future releases [2] and existing components. Bugs
> could thus be tied in the same way.
>
> [1] You should take this as potential intent, not a written commitment of
> the interested contributor(s).
> [2] As Taher expressed here
> https://issues.apache.org/jira/browse/OFBIZ-5840?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15379018#comment-15379018
> visavis a possible intent to work on theming improvement for a release
> after r16.x ( I won't put a gun to his head, as every effort applied is
> volunteer work as much as time permits).
>
> Best regards,
>
> Pierre Smits
>
> ORRTIZ.COM <http://www.orrtiz.com>
> OFBiz based solutions & services
>
> OFBiz Extensions Marketplace
> http://oem.ofbizci.net/oci-2/
>
> On Fri, Jul 15, 2016 at 7:27 PM, Jacques Le Roux <
> [hidden email]> wrote:
>
>> Le 15/07/2016 à 16:12, Pierre Smits a écrit :
>>
>>>    I remember us having a wiki page
>>> indicating who was interested in what and who was willing to work on what.
>>> A page I now can't find that easily. Maybe we could revisit that and see
>>> if
>>> we can bring that back to life.
>>>
>> This ?
>>
>> https://cwiki.apache.org/confluence/display/OFBADMIN/New+Features+Roadmap+-+Living+Document
>>
>> Jacques
>>
>>

[Sharan-F]

Hi Jacques

I'll take a look at this Jira Service Desk functionality and come back with some feedback.

Thanks
Sharan

On 2016-07-30 13:53 (+0200), Jacques Le Roux <[hidden email]> wrote:

> Hi Sharan, All,
>
> I just did something which might help us, at least on your point 4. I have enabled the Jira Service Desk option so we have now a SLA feature (Service
> Level Agreement)
> I used the default, can be changed at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/sla (need more work and especially agreement, to be
> discussed I guess)
> It shows at the top right of each issue
> There is also queues at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/queues
>
> I don't think we want to change that https://issues.apache.org/jira/servicedesk/agent/OFBIZ/people
> I don't think we need https://issues.apache.org/jira/servicedesk/agent/OFBIZ/customer I guess we can customize to have something like
> https://issues.apache.org/jira/servicedesk/customer/portal/1, related with line above, useful for us? I guess not.
>
> There are reports at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/reports
>
> I think this could be usefully used to organise and prioritise our issues, beginning by our own.
>
> What do  you think?
>
> Jacques
>
>
> Le 15/07/2016  12:03, Jacques Le Roux a crit :
> > Hi Sharan, inline...
> >
> > Le 15/07/2016  11:53, Sharan Foga a crit :
> >
> >> Hi All
> >>
> >> We have an amazing number of Jiras open and because we have so many it's getting very confusing as to what are the priorities and things are
> >> getting clogged up.
> >>
> >> I've got a few initial ideas and suggestions that could maybe help improve the workflow
> >>
> >> 1) Highlight Parked / On Hold Jiras
> >> We have quite a few Jira issues that are 'parked' or 'on hold' \u2013 so it would be good if these were clearly identified so that if people come
> >> across them they know that they are not being worked on (and the reason).
> >>
> >> We could look at adding a new status, a flag or a label that could hold this information.
> >
> > For those we could maybe close them with the "Later" status? So nothing to do (but closing them), we did that already, not sure it completely fits
> > for all cases though...
> >
> >> 2) QA Review for New Jiras
> >> I think it would also be good to look at introducing some type of review stage for newly created issues. This also could give us a bit of QA to
> >> make sure that there is enough information needed for the task to be worked on. It could also be then allocated to a workstream.
> >
> > Are we not already (slowly) doing it? Do we really need a policy or (a) tool/s for that? I fear we don't miss policies but rather free time from
> > contributors...
> >
> >> 3) Define Workstreams
> >> We have a good idea of the areas that we want to focus so it should be relatively easy to setup some workstreams.  I'd like to explore the idea of
> >> workstreams a bit more because it could be something that could be an entire sprint, an issue category or it could be the equivalent of a planned
> >> future release.
> >>
> >> I know Jira allow us to define a Roadmap and versions and that we already have something setup that helps us with our release management
> >> (I.e.automatically incorporates all the Jiras applied to a version) that we don't want to break \u2013 so this might need more investigation
> >>
> >> 4) Review of Old Jiras
> >> One of things that we've had hanging around for ages is a lot of old Jiras. At the moment I think Jacques takes on a few at a time, so it could be
> >> good to get some other volunteers and start looking at these and either closing them, parking them or allocating them to a workstream.
> >
> > This relates to point 1
> >
> >> These are a few of the ideas I had in mind \u2013 the main objective is to make Jira into a useful tool for help us with our workflow.
> >>
> >> Please feel free to let me have your feedback and comments, and if anyone else has other ideas and suggestion to share, then please do.
> >
> > Thanks for this initiative Sharan!
> >
> > Jacques
> >
> >> Thanks
> >> Sharan
> >>
> >>
> >
> >
>
>

[Sharan-F]

Hi Jacques

I took a look at the Service Desk functionality you enabled in Jira and I'm not sure that it fits the project flow. It seems to be focussed at customer service desk resolution within agreed timeframes. Although you could argue that our users are also our customers, no one is under any obligation to fix an issue within a fixed time frame – everyone gives their time voluntarily.

I understand that the service desk is used by the infra team as they have specific Service Level Agreements they need to meet and I think imposing SLAs onto a voluntary team of contributors could cause a bit of unnecessary pressure and stress.

The main thing we as a project need to address, is to sort out and make sense of our Jira backlog (or 'jira mess') so that it becomes a useful tool rather than where things stay in limbo.  I'd suggest rather than trying to fix everything at once, let's try to find the things that could improve the throughput or reduction of issues and focus on implementing them as a first step.

Thanks
Sharan

On 2016-07-30 13:53 (+0200), Jacques Le Roux <[hidden email]> wrote:

> Hi Sharan, All,
>
> I just did something which might help us, at least on your point 4. I have enabled the Jira Service Desk option so we have now a SLA feature (Service
> Level Agreement)
> I used the default, can be changed at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/sla (need more work and especially agreement, to be
> discussed I guess)
> It shows at the top right of each issue
> There is also queues at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/queues
>
> I don't think we want to change that https://issues.apache.org/jira/servicedesk/agent/OFBIZ/people
> I don't think we need https://issues.apache.org/jira/servicedesk/agent/OFBIZ/customer I guess we can customize to have something like
> https://issues.apache.org/jira/servicedesk/customer/portal/1, related with line above, useful for us? I guess not.
>
> There are reports at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/reports
>
> I think this could be usefully used to organise and prioritise our issues, beginning by our own.
>
> What do  you think?
>
> Jacques
>
>
> Le 15/07/2016  12:03, Jacques Le Roux a crit :
> > Hi Sharan, inline...
> >
> > Le 15/07/2016  11:53, Sharan Foga a crit :
> >
> >> Hi All
> >>
> >> We have an amazing number of Jiras open and because we have so many it's getting very confusing as to what are the priorities and things are
> >> getting clogged up.
> >>
> >> I've got a few initial ideas and suggestions that could maybe help improve the workflow
> >>
> >> 1) Highlight Parked / On Hold Jiras
> >> We have quite a few Jira issues that are 'parked' or 'on hold' \u2013 so it would be good if these were clearly identified so that if people come
> >> across them they know that they are not being worked on (and the reason).
> >>
> >> We could look at adding a new status, a flag or a label that could hold this information.
> >
> > For those we could maybe close them with the "Later" status? So nothing to do (but closing them), we did that already, not sure it completely fits
> > for all cases though...
> >
> >> 2) QA Review for New Jiras
> >> I think it would also be good to look at introducing some type of review stage for newly created issues. This also could give us a bit of QA to
> >> make sure that there is enough information needed for the task to be worked on. It could also be then allocated to a workstream.
> >
> > Are we not already (slowly) doing it? Do we really need a policy or (a) tool/s for that? I fear we don't miss policies but rather free time from
> > contributors...
> >
> >> 3) Define Workstreams
> >> We have a good idea of the areas that we want to focus so it should be relatively easy to setup some workstreams.  I'd like to explore the idea of
> >> workstreams a bit more because it could be something that could be an entire sprint, an issue category or it could be the equivalent of a planned
> >> future release.
> >>
> >> I know Jira allow us to define a Roadmap and versions and that we already have something setup that helps us with our release management
> >> (I.e.automatically incorporates all the Jiras applied to a version) that we don't want to break \u2013 so this might need more investigation
> >>
> >> 4) Review of Old Jiras
> >> One of things that we've had hanging around for ages is a lot of old Jiras. At the moment I think Jacques takes on a few at a time, so it could be
> >> good to get some other volunteers and start looking at these and either closing them, parking them or allocating them to a workstream.
> >
> > This relates to point 1
> >
> >> These are a few of the ideas I had in mind \u2013 the main objective is to make Jira into a useful tool for help us with our workflow.
> >>
> >> Please feel free to let me have your feedback and comments, and if anyone else has other ideas and suggestion to share, then please do.
> >
> > Thanks for this initiative Sharan!
> >
> > Jacques
> >
> >> Thanks
> >> Sharan
> >>
> >>
> >
> >
>
>

[Jacques Le Roux]

Agreed Sharan, it was just a try and it's not worth it for us. I just closed it, thanks for checking!

Jacques

Le 17/08/2016 à 09:50, Sharan Foga a écrit :

> Hi Jacques
>
> I took a look at the Service Desk functionality you enabled in Jira and I'm not sure that it fits the project flow. It seems to be focussed at customer service desk resolution within agreed timeframes. Although you could argue that our users are also our customers, no one is under any obligation to fix an issue within a fixed time frame – everyone gives their time voluntarily.
>
> I understand that the service desk is used by the infra team as they have specific Service Level Agreements they need to meet and I think imposing SLAs onto a voluntary team of contributors could cause a bit of unnecessary pressure and stress.
>
> The main thing we as a project need to address, is to sort out and make sense of our Jira backlog (or 'jira mess') so that it becomes a useful tool rather than where things stay in limbo.  I'd suggest rather than trying to fix everything at once, let's try to find the things that could improve the throughput or reduction of issues and focus on implementing them as a first step.
>
> Thanks
> Sharan
>
> On 2016-07-30 13:53 (+0200), Jacques Le Roux <[hidden email]> wrote:
>> Hi Sharan, All,
>>
>> I just did something which might help us, at least on your point 4. I have enabled the Jira Service Desk option so we have now a SLA feature (Service
>> Level Agreement)
>> I used the default, can be changed at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/sla (need more work and especially agreement, to be
>> discussed I guess)
>> It shows at the top right of each issue
>> There is also queues at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/queues
>>
>> I don't think we want to change that https://issues.apache.org/jira/servicedesk/agent/OFBIZ/people
>> I don't think we need https://issues.apache.org/jira/servicedesk/agent/OFBIZ/customer I guess we can customize to have something like
>> https://issues.apache.org/jira/servicedesk/customer/portal/1, related with line above, useful for us? I guess not.
>>
>> There are reports at https://issues.apache.org/jira/servicedesk/agent/OFBIZ/reports
>>
>> I think this could be usefully used to organise and prioritise our issues, beginning by our own.
>>
>> What do  you think?
>>
>> Jacques
>>
>>
>> Le 15/07/2016  12:03, Jacques Le Roux a crit :
>>> Hi Sharan, inline...
>>>
>>> Le 15/07/2016  11:53, Sharan Foga a crit :
>>>
>>>> Hi All
>>>>
>>>> We have an amazing number of Jiras open and because we have so many it's getting very confusing as to what are the priorities and things are
>>>> getting clogged up.
>>>>
>>>> I've got a few initial ideas and suggestions that could maybe help improve the workflow
>>>>
>>>> 1) Highlight Parked / On Hold Jiras
>>>> We have quite a few Jira issues that are 'parked' or 'on hold' \u2013 so it would be good if these were clearly identified so that if people come
>>>> across them they know that they are not being worked on (and the reason).
>>>>
>>>> We could look at adding a new status, a flag or a label that could hold this information.
>>> For those we could maybe close them with the "Later" status? So nothing to do (but closing them), we did that already, not sure it completely fits
>>> for all cases though...
>>>
>>>> 2) QA Review for New Jiras
>>>> I think it would also be good to look at introducing some type of review stage for newly created issues. This also could give us a bit of QA to
>>>> make sure that there is enough information needed for the task to be worked on. It could also be then allocated to a workstream.
>>> Are we not already (slowly) doing it? Do we really need a policy or (a) tool/s for that? I fear we don't miss policies but rather free time from
>>> contributors...
>>>
>>>> 3) Define Workstreams
>>>> We have a good idea of the areas that we want to focus so it should be relatively easy to setup some workstreams.  I'd like to explore the idea of
>>>> workstreams a bit more because it could be something that could be an entire sprint, an issue category or it could be the equivalent of a planned
>>>> future release.
>>>>
>>>> I know Jira allow us to define a Roadmap and versions and that we already have something setup that helps us with our release management
>>>> (I.e.automatically incorporates all the Jiras applied to a version) that we don't want to break \u2013 so this might need more investigation
>>>>
>>>> 4) Review of Old Jiras
>>>> One of things that we've had hanging around for ages is a lot of old Jiras. At the moment I think Jacques takes on a few at a time, so it could be
>>>> good to get some other volunteers and start looking at these and either closing them, parking them or allocating them to a workstream.
>>> This relates to point 1
>>>
>>>> These are a few of the ideas I had in mind \u2013 the main objective is to make Jira into a useful tool for help us with our workflow.
>>>>
>>>> Please feel free to let me have your feedback and comments, and if anyone else has other ideas and suggestion to share, then please do.
>>> Thanks for this initiative Sharan!
>>>
>>> Jacques
>>>
>>>> Thanks
>>>> Sharan
>>>>
>>>>
>>>
>>