Re: [DISCUSSION] Remove the "Resolved" resolution type from Jira workflow

[Jacques Le Roux]

Done

Le 29/07/2019 à 16:19, Jacques Le Roux a écrit :

Hi Pawan,

I agree, it's

https://issues.apache.org/jira/browse/OFBIZ-10921
https://issues.apache.org/jira/browse/OFBIZ-10817

We are not in a hurry. We need to warn Suraj and Nicolas and w/o reaction from 
them, in say 3 days, do it indeed :)

Thanks

Jacques

PS: weirdly when answering (either to the list or all) I only got your answer. 
The rest below disappeared, not a bit deal but weird.

Le 29/07/2019 à 14:40, Pawan Verma a écrit :

Hello Jacques,

I've found only two tickets(OFBIZ-10921 and OFBIZ-10817) in *Resolved*
status.

I think we can move them and remove the *Resolved* status. WDYT?

Re: [DISCUSSION] Remove the "Resolved" resolution type from Jira workflow

[Jacques Le Roux]

Hi Pawan,

I agree, it's

https://issues.apache.org/jira/browse/OFBIZ-10921
https://issues.apache.org/jira/browse/OFBIZ-10817

We are not in a hurry. We need to warn Suraj and Nicolas and w/o reaction from 
them, in say 3 days, do it indeed :)

Thanks

Jacques

PS: weirdly when answering (either to the list or all) I only got your answer. 
The rest below disappeared, not a bit deal but weird.

Le 29/07/2019 à 14:40, Pawan Verma a écrit :

Hello Jacques,

I've found only two tickets(OFBIZ-10921 and OFBIZ-10817) in *Resolved*
status.

I think we can move them and remove the *Resolved* status. WDYT?

Re: [DISCUSSION] Remove the "Resolved" resolution type from Jira workflow

[Pawan Verma]

Hello Jacques,

I've found only two tickets(OFBIZ-10921 and OFBIZ-10817) in *Resolved*
status.

I think we can move them and remove the *Resolved* status. WDYT?
-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Mon, Jul 29, 2019 at 5:45 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Got this:
>
>
> Failed to remove status
>
> *We can't remove this status for you*
> There are issues in this status that need to be moved to another status or
> project before we can remove this status. Please contact your JIRA
> administrator if you need assistance.
>
> Let it be
>
> Jacques
>
> Le 24/07/2019 à 07:51, Aditya Sharma a écrit :
> > +1
> >
> > Thanks and Regards,
> > Aditya Sharma
> >
> > On Tue, Jul 23, 2019 at 12:11 PM Pawan Verma <
> pawan.ve...@hotwaxsystems.com>
> > wrote:
> >
> >> +1,
> >>
> >> "Resolved" Seems unused to me also.
> >> --
> >> Thanks & Regards
> >> Pawan Verma
> >> Technical Consultant
> >> *HotWax Systems*
> >> *Enterprise open source experts*
> >> http://www.hotwaxsystems.com
> >>
> >>
> >> On Mon, Jul 22, 2019 at 1:25 PM Jacques Le Roux <
> >> jacques.le.r...@les7arts.com> wrote:
> >>
> >>> Hi,
> >>>
> >>> After a short discussion with Mathieu at OFBIZ-11140, we both suggest
> >> that
> >>> we remove the "Resolved" resolution type from Jira workflow.
> >>>
> >>> If nobody disagree I'll do so in a week
> >>>
> >>> Jacques
> >>>
> >>>
>

Re: [DISCUSSION] Remove the "Resolved" resolution type from Jira workflow

[Jacques Le Roux]

Got this:


   Failed to remove status

*We can't remove this status for you*
There are issues in this status that need to be moved to another status or project before we can remove this status. Please contact your JIRA 
administrator if you need assistance.


Let it be

Jacques

Le 24/07/2019 à 07:51, Aditya Sharma a écrit :

+1

Thanks and Regards,
Aditya Sharma

On Tue, Jul 23, 2019 at 12:11 PM Pawan Verma 
wrote:


+1,

"Resolved" Seems unused to me also.
--
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Mon, Jul 22, 2019 at 1:25 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:


Hi,

After a short discussion with Mathieu at OFBIZ-11140, we both suggest

that

we remove the "Resolved" resolution type from Jira workflow.

If nobody disagree I'll do so in a week

Jacques

Re: [DISCUSSION] Remove the "Resolved" resolution type from Jira workflow

[Aditya Sharma]

+1

Thanks and Regards,
Aditya Sharma

On Tue, Jul 23, 2019 at 12:11 PM Pawan Verma 
wrote:

> +1,
>
> "Resolved" Seems unused to me also.
> --
> Thanks & Regards
> Pawan Verma
> Technical Consultant
> *HotWax Systems*
> *Enterprise open source experts*
> http://www.hotwaxsystems.com
>
>
> On Mon, Jul 22, 2019 at 1:25 PM Jacques Le Roux <
> jacques.le.r...@les7arts.com> wrote:
>
> > Hi,
> >
> > After a short discussion with Mathieu at OFBIZ-11140, we both suggest
> that
> > we remove the "Resolved" resolution type from Jira workflow.
> >
> > If nobody disagree I'll do so in a week
> >
> > Jacques
> >
> >
>

Re: [DISCUSSION] Remove the "Resolved" resolution type from Jira workflow

[Pawan Verma]

+1,

"Resolved" Seems unused to me also.
-- 
Thanks & Regards
Pawan Verma
Technical Consultant
*HotWax Systems*
*Enterprise open source experts*
http://www.hotwaxsystems.com


On Mon, Jul 22, 2019 at 1:25 PM Jacques Le Roux <
jacques.le.r...@les7arts.com> wrote:

> Hi,
>
> After a short discussion with Mathieu at OFBIZ-11140, we both suggest that
> we remove the "Resolved" resolution type from Jira workflow.
>
> If nobody disagree I'll do so in a week
>
> Jacques
>
>

[DISCUSSION] Remove the "Resolved" resolution type from Jira workflow

[Jacques Le Roux]

Hi,

After a short discussion with Mathieu at OFBIZ-11140, we both suggest that we remove the 
"Resolved" resolution type from Jira workflow.

If nobody disagree I'll do so in a week

Jacques

Re: Ideas for Improving our Jira Workflow

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

Re: Ideas for Improving our Jira Workflow

[Sharan Foga]

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

Re: Ideas for Improving our Jira Workflow

[Sharan Foga]

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

Re: Ideas for Improving our Jira Workflow

[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

Re: Ideas for Improving our Jira Workflow

[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=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 
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 <
jacques.le.r...@les7arts.com> 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
>
>

Re: Ideas for Improving our Jira Workflow

[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

Re: Ideas for Improving our Jira Workflow

[Pierre Smits]

Hi Sharan, All,

Please see inline.

Best regards,

Pierre Smits

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  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
, OFBIZ-7767
 and 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
>
>

Re: Ideas for Improving our Jira Workflow

[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

Ideas for Improving our Jira Workflow

[Sharan Foga]

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

Re: jira workflow

[Jacques Le Roux]

Thanks Adam for the very detailed workflow... answers inline, mostly about 
vocabulary :) ...

Le 23/04/2015 07:56, Jacopo Cappellato a écrit :

On Apr 22, 2015, at 10:07 PM, Adam Heath doo...@brainfood.com wrote:


So, I've started attempting to use JIRA and branches, to implement a new 
workflow.  Basically, I'm seeing what the capabilities of the systems are.  
I've run into a bit of a mis-feature, I believe, so I'm asking here to see if 
anyone might help.

Here is the workflow I am attempting to follow.

1: Bug/feature/etc gets created.

2: Branch is made with the name set to the id from (1).

3: Sub-tasks are made, to split up the large amount of work from (1).

4: Each sub-task can be assigned to different people, and work proceeds in 
parallel. The state of the sub-task moves from OPEN to IN-PROGRESS.


There is also the important Patch available status...



5: Commits are done to the shared branch from (2), with each message tagged 
with the id(s) from (3).


Cool to put the name of the possible contributor too ;)



6: When a commit from (5) is pushed, the developer doing the work moves the 
issue state to RESOLVED.  This is not closed, as the change is not available 
for testing by the reported yet.  Nor has it been made available to the rest of 
the ecosystem.


A commit is not pushed it's committed :p.
In don't agree about the the change is not available for testing by the reported yet. S/He can always checkout a branch. Anyway I agree not being 
available to the rest of the ecosystem is a status blocker.

7: Some code reviewer looks at the series of commits, and if they do what they 
set out to do, merges the branch to trunk/master/release. The issue state(s) 
change from RESOLVED to 


Some code reviewer here must be a committer to be able to merge and commit the branch, and it's not in trunk/master/release, it's, so far, 
eventually in svn trunk HEAD.


For the rest I agree with you and Jacopo

Jacques



8: The original filer looks at trunk/master/release, and if the original report 
has been resolved, changes the issue state from  to CLOSED.

I don't see an option in JIRA for the represenative state in 7.  The commits I 
have just sent into branch OFBIZ-6275 are currently at line (6) from above.


Thanks for the detailed workflow, this is a good topic.
For now, without adding statuses or customizing the workflow (we may have to 
contact the ASF Infra for this), I would suggest to use  = CLOSED.
This means that the task will be closed in step 7 when the feature branch is 
merged into the trunk/master/release branches.
At step 8 the original reported will either add a comment confirming that the 
issue is resolved or reopen the task.

Jacopo

Re: jira workflow

[Adam Heath]

On 04/27/2015 09:16 AM, Jacques Le Roux wrote:
Thanks Adam for the very detailed workflow... answers inline, mostly 
about vocabulary :) ...


Le 23/04/2015 07:56, Jacopo Cappellato a écrit :

On Apr 22, 2015, at 10:07 PM, Adam Heath doo...@brainfood.com wrote:

So, I've started attempting to use JIRA and branches, to implement a 
new workflow.  Basically, I'm seeing what the capabilities of the 
systems are.  I've run into a bit of a mis-feature, I believe, so 
I'm asking here to see if anyone might help.


Here is the workflow I am attempting to follow.

1: Bug/feature/etc gets created.

2: Branch is made with the name set to the id from (1).

3: Sub-tasks are made, to split up the large amount of work from (1).

4: Each sub-task can be assigned to different people, and work 
proceeds in parallel. The state of the sub-task moves from OPEN to 
IN-PROGRESS.


There is also the important Patch available status...



With git, there is never a single patch.  It's a commit stream, a 
branch, a repo fork.  But yeah, I'll think about using this status.




5: Commits are done to the shared branch from (2), with each message 
tagged with the id(s) from (3).


Cool to put the name of the possible contributor too ;)



6: When a commit from (5) is pushed, the developer doing the work 
moves the issue state to RESOLVED.  This is not closed, as the 
change is not available for testing by the reported yet.  Nor has it 
been made available to the rest of the ecosystem.


A commit is not pushed it's committed :p.


Ok, not pushed, not committed.  How about, when the change leaves the 
developer's system, and is somehow made available in the shared 
branch?  This could be via a commit to a shared repo(ala svn), or a 
pull request(ala git/fork)?


In don't agree about the the change is not available for testing by 
the reported yet. S/He can always checkout a branch. Anyway I agree 
not being available to the rest of the ecosystem is a status blocker.


The integration area(svn branch, git repo fork) may not be available for 
the original reporter to easily test.  There would need to be a download 
area for the resultant binaries, or the user would have to check out 
directly.  Not all end-users can or want to compile ofbiz.


7: Some code reviewer looks at the series of commits, and if they do 
what they set out to do, merges the branch to trunk/master/release. 
The issue state(s) change from RESOLVED to 


Some code reviewer here must be a committer to be able to merge and 
commit the branch, and it's not in trunk/master/release, it's, so 
far, eventually in svn trunk HEAD.


For the rest I agree with you and Jacopo

Jacques



Let's not tie the workflow to svn-only terms.  Just because ofbiz 
primary is currently managed through svn, outside vendors might be using 
git, and can use more advanced push/pull/merge-request type workflows.





8: The original filer looks at trunk/master/release, and if the 
original report has been resolved, changes the issue state from  
to CLOSED.


I don't see an option in JIRA for the represenative state in 7.  The 
commits I have just sent into branch OFBIZ-6275 are currently at 
line (6) from above.



Thanks for the detailed workflow, this is a good topic.
For now, without adding statuses or customizing the workflow (we may 
have to contact the ASF Infra for this), I would suggest to use  
= CLOSED.
This means that the task will be closed in step 7 when the feature 
branch is merged into the trunk/master/release branches.
At step 8 the original reported will either add a comment confirming 
that the issue is resolved or reopen the task.


Jacopo

Re: jira workflow

[Pierre Smits]

Adam,

JIRA offers quite some flexibility with respect to defining status field
values (see:
https://confluence.atlassian.com/display/JIRA063/Defining+Status+Field+Values)
and workflow schemes (
https://confluence.atlassian.com/display/JIRA063/Configuring+workflow+schemes
)

It might be so that what we have got is limited, e.g. just the default re
status field (values
https://confluence.atlassian.com/display/JIRA063/What+is+an+Issue#WhatisanIssue-Status
)

I remember Jacques and I having discussed potential changes (status and
workflow) in the past and what the process would of having that
implemented. If I remember well, there are some options available to
projects. But such questions about extensions should best be directed at
INFRA.

Best regards,

Pierre Smits

*ORRTIZ.COM http://www.orrtiz.com*
Services  Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail  Trade
http://www.orrtiz.com

On Wed, Apr 22, 2015 at 10:07 PM, Adam Heath doo...@brainfood.com wrote:

 So, I've started attempting to use JIRA and branches, to implement a new
 workflow.  Basically, I'm seeing what the capabilities of the systems are.
 I've run into a bit of a mis-feature, I believe, so I'm asking here to see
 if anyone might help.

 Here is the workflow I am attempting to follow.

 1: Bug/feature/etc gets created.

 2: Branch is made with the name set to the id from (1).

 3: Sub-tasks are made, to split up the large amount of work from (1).

 4: Each sub-task can be assigned to different people, and work proceeds in
 parallel. The state of the sub-task moves from OPEN to IN-PROGRESS.

 5: Commits are done to the shared branch from (2), with each message
 tagged with the id(s) from (3).

 6: When a commit from (5) is pushed, the developer doing the work moves
 the issue state to RESOLVED.  This is not closed, as the change is not
 available for testing by the reported yet.  Nor has it been made available
 to the rest of the ecosystem.

 7: Some code reviewer looks at the series of commits, and if they do what
 they set out to do, merges the branch to trunk/master/release. The issue
 state(s) change from RESOLVED to 

 8: The original filer looks at trunk/master/release, and if the original
 report has been resolved, changes the issue state from  to CLOSED.

 I don't see an option in JIRA for the represenative state in 7.  The
 commits I have just sent into branch OFBIZ-6275 are currently at line (6)
 from above.

Re: jira workflow

[Jacopo Cappellato]

On Apr 22, 2015, at 10:07 PM, Adam Heath doo...@brainfood.com wrote:

 So, I've started attempting to use JIRA and branches, to implement a new 
 workflow.  Basically, I'm seeing what the capabilities of the systems are.  
 I've run into a bit of a mis-feature, I believe, so I'm asking here to see if 
 anyone might help.
 
 Here is the workflow I am attempting to follow.
 
 1: Bug/feature/etc gets created.
 
 2: Branch is made with the name set to the id from (1).
 
 3: Sub-tasks are made, to split up the large amount of work from (1).
 
 4: Each sub-task can be assigned to different people, and work proceeds in 
 parallel. The state of the sub-task moves from OPEN to IN-PROGRESS.
 
 5: Commits are done to the shared branch from (2), with each message tagged 
 with the id(s) from (3).
 
 6: When a commit from (5) is pushed, the developer doing the work moves the 
 issue state to RESOLVED.  This is not closed, as the change is not available 
 for testing by the reported yet.  Nor has it been made available to the rest 
 of the ecosystem.
 
 7: Some code reviewer looks at the series of commits, and if they do what 
 they set out to do, merges the branch to trunk/master/release. The issue 
 state(s) change from RESOLVED to 
 
 8: The original filer looks at trunk/master/release, and if the original 
 report has been resolved, changes the issue state from  to CLOSED.
 
 I don't see an option in JIRA for the represenative state in 7.  The commits 
 I have just sent into branch OFBIZ-6275 are currently at line (6) from above.
 

Thanks for the detailed workflow, this is a good topic.
For now, without adding statuses or customizing the workflow (we may have to 
contact the ASF Infra for this), I would suggest to use  = CLOSED.
This means that the task will be closed in step 7 when the feature branch is 
merged into the trunk/master/release branches.
At step 8 the original reported will either add a comment confirming that the 
issue is resolved or reopen the task.

Jacopo

jira workflow

[Adam Heath]

So, I've started attempting to use JIRA and branches, to implement a new 
workflow.  Basically, I'm seeing what the capabilities of the systems 
are.  I've run into a bit of a mis-feature, I believe, so I'm asking 
here to see if anyone might help.


Here is the workflow I am attempting to follow.

1: Bug/feature/etc gets created.

2: Branch is made with the name set to the id from (1).

3: Sub-tasks are made, to split up the large amount of work from (1).

4: Each sub-task can be assigned to different people, and work proceeds 
in parallel. The state of the sub-task moves from OPEN to IN-PROGRESS.


5: Commits are done to the shared branch from (2), with each message 
tagged with the id(s) from (3).


6: When a commit from (5) is pushed, the developer doing the work moves 
the issue state to RESOLVED.  This is not closed, as the change is not 
available for testing by the reported yet.  Nor has it been made 
available to the rest of the ecosystem.


7: Some code reviewer looks at the series of commits, and if they do 
what they set out to do, merges the branch to trunk/master/release. The 
issue state(s) change from RESOLVED to 


8: The original filer looks at trunk/master/release, and if the original 
report has been resolved, changes the issue state from  to CLOSED.


I don't see an option in JIRA for the represenative state in 7.  The 
commits I have just sent into branch OFBIZ-6275 are currently at line 
(6) from above.