Taking action on problems with using JIRA

[taher]

Hi Everyone,

As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
50 trivial open JIRAs and I note:

- I think none of the blocker and critical JIRAs belong in that category.
- It is also unrealistic to have 733 major issues. it is like saying we
have that many serious problems
- I think a realistic distribution would have a pyramid count with a max
(pyramid base) being trivial JIRAs.
- A substantial number of jiras is old and no longer applicable.
- A substantial number of jiras is vague and not understandable, poorly
written, without enough details to work on.
- A substantial amount of jiras are placeholders for something to do
without proper thinking and planning, which would make them unrealistic or
not applicable.
- Some JIRAs are extremely granular. For example a task broken to subtasks
each for a tiny amount of work that is not worth the time and effort of
making so many tasks.

So I think our issue tracking system is not properly used and we have many
JIRAs that are not useful and distracting. I propose the following actions:

- Add a wiki page (if one does not exist) documenting:
  - Guidelines for writing JIRA mentioning clarity, provision of solution.
  - A clear definition of priorities (blocker, critical, major, minor,
trivial) with some examples.
  - A description of meaning of assignee and how to use it
  - A description of other metadata and how to properly use it (tags,
components, affects version, etc...)
- we need to close all old, not applicable, vague and poorly written JIRAs
as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
with guidelines.
- We need to fix priorities of all remaining JIRAs as per wiki guidelines

This would give us a realistic view of the _real_ issues in OFBiz instead
of drowning in so many JIRAs many of which are hindering rather than
helping.

What do you think?

Taher Alkhateeb

[Michael Brohl-3]

Hi Taher,

I fully agree with your analysis of the overall state of our Jira issues!

Except the first two statements but simply because I haven't had a
deeper look in the mentioned issues yet.

I'd like to help with the guidelines if we decide to have them.

Regards,

Michael Brohl
ecomify GmbH
www.ecomify.de


Am 03.09.16 um 07:56 schrieb Taher Alkhateeb:

> Hi Everyone,
>
> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
> 50 trivial open JIRAs and I note:
>
> - I think none of the blocker and critical JIRAs belong in that category.
> - It is also unrealistic to have 733 major issues. it is like saying we
> have that many serious problems
> - I think a realistic distribution would have a pyramid count with a max
> (pyramid base) being trivial JIRAs.
> - A substantial number of jiras is old and no longer applicable.
> - A substantial number of jiras is vague and not understandable, poorly
> written, without enough details to work on.
> - A substantial amount of jiras are placeholders for something to do
> without proper thinking and planning, which would make them unrealistic or
> not applicable.
> - Some JIRAs are extremely granular. For example a task broken to subtasks
> each for a tiny amount of work that is not worth the time and effort of
> making so many tasks.
>
> So I think our issue tracking system is not properly used and we have many
> JIRAs that are not useful and distracting. I propose the following actions:
>
> - Add a wiki page (if one does not exist) documenting:
>    - Guidelines for writing JIRA mentioning clarity, provision of solution.
>    - A clear definition of priorities (blocker, critical, major, minor,
> trivial) with some examples.
>    - A description of meaning of assignee and how to use it
>    - A description of other metadata and how to properly use it (tags,
> components, affects version, etc...)
> - we need to close all old, not applicable, vague and poorly written JIRAs
> as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
> with guidelines.
> - We need to fix priorities of all remaining JIRAs as per wiki guidelines
>
> This would give us a realistic view of the _real_ issues in OFBiz instead
> of drowning in so many JIRAs many of which are hindering rather than
> helping.
>
> What do you think?
>
> Taher Alkhateeb
>

[Ashish Vijaywargiya-4]

+1, jira cleanup is an important step that should be taken care as soon as
we can.

Kind Regards
Ashish Vijaywargiya
HotWax Systems - est. 1997


On Sat, Sep 3, 2016 at 11:26 AM, Taher Alkhateeb <[hidden email]
> wrote:

> Hi Everyone,
>
> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
> 50 trivial open JIRAs and I note:
>
> - I think none of the blocker and critical JIRAs belong in that category.
> - It is also unrealistic to have 733 major issues. it is like saying we
> have that many serious problems
> - I think a realistic distribution would have a pyramid count with a max
> (pyramid base) being trivial JIRAs.
> - A substantial number of jiras is old and no longer applicable.
> - A substantial number of jiras is vague and not understandable, poorly
> written, without enough details to work on.
> - A substantial amount of jiras are placeholders for something to do
> without proper thinking and planning, which would make them unrealistic or
> not applicable.
> - Some JIRAs are extremely granular. For example a task broken to subtasks
> each for a tiny amount of work that is not worth the time and effort of
> making so many tasks.
>
> So I think our issue tracking system is not properly used and we have many
> JIRAs that are not useful and distracting. I propose the following actions:
>
> - Add a wiki page (if one does not exist) documenting:
>   - Guidelines for writing JIRA mentioning clarity, provision of solution.
>   - A clear definition of priorities (blocker, critical, major, minor,
> trivial) with some examples.
>   - A description of meaning of assignee and how to use it
>   - A description of other metadata and how to properly use it (tags,
> components, affects version, etc...)
> - we need to close all old, not applicable, vague and poorly written JIRAs
> as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
> with guidelines.
> - We need to fix priorities of all remaining JIRAs as per wiki guidelines
>
> This would give us a realistic view of the _real_ issues in OFBiz instead
> of drowning in so many JIRAs many of which are hindering rather than
> helping.
>
> What do you think?
>
> Taher Alkhateeb
>

[Jacques Le Roux]

Le 03/09/2016 à 07:56, Taher Alkhateeb a écrit :
> - Add a wiki page (if one does not exist) documenting:
>    - Guidelines for writing JIRA mentioning clarity, provision of solution.
>    - A clear definition of priorities (blocker, critical, major, minor,
> trivial) with some examples.
We could start by extracting this section
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-ManageJIRA%27sissues 
to a new "Manage Jira issues" page and reference it from both
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
and (or maybe only?)
https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
BTW I'll carve in stone (put in page) my comment there (ie no longer a soon 10 years old proposition)!

Jacques

[Sharan-F]

Hi Taher

+1

You have raised some good actionable points here. I think you are right that the Jira guidelines need be completely separated out into something that is clear and can be used as an easy reference.

I will create a wiki page to start pulling the information together.

Thanks
Sharan

On 2016-09-03 07:56 (+0200), Taher Alkhateeb <[hidden email]> wrote:

> Hi Everyone,
>
> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
> 50 trivial open JIRAs and I note:
>
> - I think none of the blocker and critical JIRAs belong in that category.
> - It is also unrealistic to have 733 major issues. it is like saying we
> have that many serious problems
> - I think a realistic distribution would have a pyramid count with a max
> (pyramid base) being trivial JIRAs.
> - A substantial number of jiras is old and no longer applicable.
> - A substantial number of jiras is vague and not understandable, poorly
> written, without enough details to work on.
> - A substantial amount of jiras are placeholders for something to do
> without proper thinking and planning, which would make them unrealistic or
> not applicable.
> - Some JIRAs are extremely granular. For example a task broken to subtasks
> each for a tiny amount of work that is not worth the time and effort of
> making so many tasks.
>
> So I think our issue tracking system is not properly used and we have many
> JIRAs that are not useful and distracting. I propose the following actions:
>
> - Add a wiki page (if one does not exist) documenting:
>   - Guidelines for writing JIRA mentioning clarity, provision of solution.
>   - A clear definition of priorities (blocker, critical, major, minor,
> trivial) with some examples.
>   - A description of meaning of assignee and how to use it
>   - A description of other metadata and how to properly use it (tags,
> components, affects version, etc...)
> - we need to close all old, not applicable, vague and poorly written JIRAs
> as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
> with guidelines.
> - We need to fix priorities of all remaining JIRAs as per wiki guidelines
>
> This would give us a realistic view of the _real_ issues in OFBiz instead
> of drowning in so many JIRAs many of which are hindering rather than
> helping.
>
> What do you think?
>
> Taher Alkhateeb
>

[Jacques Le Roux]

I think one thing we should consider before all the rest is Jiras issues with patches. Those are more valuable than others and patches have a
disconcerting tendency to become stale, we should avoid that.

I have a rule for that (I did not invent it, thanks Internet): the 10 min rule. If I (expect I) can do it in 10 min, they I do. Of course sometimes
you happen to shave the yak, and you can't use the rule all the day long.

Also I guess the reason why most Jiras are of major priority is because don't care when they create it. Like they don't care when choosing between
"Fixed", "Done", "Implemented" when closing, which is obviously of a less importance

My 2cts

Jacques


Le 05/09/2016 à 13:06, Sharan Foga a écrit :

> Hi Taher
>
> +1
>
> You have raised some good actionable points here. I think you are right that the Jira guidelines need be completely separated out into something that is clear and can be used as an easy reference.
>
> I will create a wiki page to start pulling the information together.
>
> Thanks
> Sharan
>
> On 2016-09-03 07:56 (+0200), Taher Alkhateeb <[hidden email]> wrote:
>> Hi Everyone,
>>
>> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
>> 50 trivial open JIRAs and I note:
>>
>> - I think none of the blocker and critical JIRAs belong in that category.
>> - It is also unrealistic to have 733 major issues. it is like saying we
>> have that many serious problems
>> - I think a realistic distribution would have a pyramid count with a max
>> (pyramid base) being trivial JIRAs.
>> - A substantial number of jiras is old and no longer applicable.
>> - A substantial number of jiras is vague and not understandable, poorly
>> written, without enough details to work on.
>> - A substantial amount of jiras are placeholders for something to do
>> without proper thinking and planning, which would make them unrealistic or
>> not applicable.
>> - Some JIRAs are extremely granular. For example a task broken to subtasks
>> each for a tiny amount of work that is not worth the time and effort of
>> making so many tasks.
>>
>> So I think our issue tracking system is not properly used and we have many
>> JIRAs that are not useful and distracting. I propose the following actions:
>>
>> - Add a wiki page (if one does not exist) documenting:
>>    - Guidelines for writing JIRA mentioning clarity, provision of solution.
>>    - A clear definition of priorities (blocker, critical, major, minor,
>> trivial) with some examples.
>>    - A description of meaning of assignee and how to use it
>>    - A description of other metadata and how to properly use it (tags,
>> components, affects version, etc...)
>> - we need to close all old, not applicable, vague and poorly written JIRAs
>> as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
>> with guidelines.
>> - We need to fix priorities of all remaining JIRAs as per wiki guidelines
>>
>> This would give us a realistic view of the _real_ issues in OFBiz instead
>> of drowning in so many JIRAs many of which are hindering rather than
>> helping.
>>
>> What do you think?
>>
>> Taher Alkhateeb
>>

[Jacques Le Roux]

Hi Sharan,

I saw you created https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+Jira

In this thread I suggested

> We could start by extracting this section
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities#OFBizCommittersRolesandResponsibilities-ManageJIRA%27sissues 
> to a new "Manage Jira issues" page and reference it from both
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Committers+Roles+and+Responsibilities
> and (or maybe only?)
> https://cwiki.apache.org/confluence/display/OFBADMIN/OFBiz+Contributors+Best+Practices
> BTW I'll carve in stone (put in page) my comment there (ie no longer a soon 10 years old proposition)!

I suggest we can now use this section content in this new page, and then redirect to the new page.

Thanks

Jacques

Le 05/09/2016 à 13:56, Jacques Le Roux a écrit :

> I think one thing we should consider before all the rest is Jiras issues with patches. Those are more valuable than others and patches have a
> disconcerting tendency to become stale, we should avoid that.
>
> I have a rule for that (I did not invent it, thanks Internet): the 10 min rule. If I (expect I) can do it in 10 min, they I do. Of course sometimes
> you happen to shave the yak, and you can't use the rule all the day long.
>
> Also I guess the reason why most Jiras are of major priority is because don't care when they create it. Like they don't care when choosing between
> "Fixed", "Done", "Implemented" when closing, which is obviously of a less importance
>
> My 2cts
>
> Jacques
>
>
> Le 05/09/2016 à 13:06, Sharan Foga a écrit :
>> Hi Taher
>>
>> +1
>>
>> You have raised some good actionable points here. I think you are right that the Jira guidelines need be completely separated out into something
>> that is clear and can be used as an easy reference.
>>
>> I will create a wiki page to start pulling the information together.
>>
>> Thanks
>> Sharan
>>
>> On 2016-09-03 07:56 (+0200), Taher Alkhateeb <[hidden email]> wrote:
>>> Hi Everyone,
>>>
>>> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor and
>>> 50 trivial open JIRAs and I note:
>>>
>>> - I think none of the blocker and critical JIRAs belong in that category.
>>> - It is also unrealistic to have 733 major issues. it is like saying we
>>> have that many serious problems
>>> - I think a realistic distribution would have a pyramid count with a max
>>> (pyramid base) being trivial JIRAs.
>>> - A substantial number of jiras is old and no longer applicable.
>>> - A substantial number of jiras is vague and not understandable, poorly
>>> written, without enough details to work on.
>>> - A substantial amount of jiras are placeholders for something to do
>>> without proper thinking and planning, which would make them unrealistic or
>>> not applicable.
>>> - Some JIRAs are extremely granular. For example a task broken to subtasks
>>> each for a tiny amount of work that is not worth the time and effort of
>>> making so many tasks.
>>>
>>> So I think our issue tracking system is not properly used and we have many
>>> JIRAs that are not useful and distracting. I propose the following actions:
>>>
>>> - Add a wiki page (if one does not exist) documenting:
>>>    - Guidelines for writing JIRA mentioning clarity, provision of solution.
>>>    - A clear definition of priorities (blocker, critical, major, minor,
>>> trivial) with some examples.
>>>    - A description of meaning of assignee and how to use it
>>>    - A description of other metadata and how to properly use it (tags,
>>> components, affects version, etc...)
>>> - we need to close all old, not applicable, vague and poorly written JIRAs
>>> as per wiki guidelines. Alternatively authors can rewrite JIRAs to comply
>>> with guidelines.
>>> - We need to fix priorities of all remaining JIRAs as per wiki guidelines
>>>
>>> This would give us a realistic view of the _real_ issues in OFBiz instead
>>> of drowning in so many JIRAs many of which are hindering rather than
>>> helping.
>>>
>>> What do you think?
>>>
>>> Taher Alkhateeb
>>>
>
>

[taher]

Hi Sharan, Everyone,

Great work on the JIRA ->
https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+Jira

I like the fact that you denote all issues for trunk as being either minor
or trivial. This does not mean they are not important or do not contain a
lot of hard work. Instead it means they are not urgent, which is exactly
the case for trunk (unstable)!

One thing we can do to further improve the situation is to have a default
value of "Trivial" to all newly created JIRAs so that people intentionally
change it to whatever is more suitable. Another thing I note in the wiki is
that the workflow (chart with arrows) is currently confusing. They need to
be broken apart because too many lines intersect and you don't know which
line goes where.

Is this document a good start for adherence for all future JIRAs? Can we
start guiding others towards the link for adherence to our requirements? Or
do we need to finalize it first?

Cheers,

Taher Alkhateeb

On 2016-09-05 14:06 ( 0300), "Sharan [hidden email]> wrote:
> Hi Taher>
>
>  1 >
>
> You have raised some good actionable points here. I think you are right
that the Jira guidelines need be completely separated out into something
that is clear and can be used as an easy reference.>

>
> I will create a wiki page to start pulling the information together.>
>
> Thanks>
> Sharan>
>
> On 2016-09-03 07:56 ( 0200), Taher Alkhateeb <[hidden email]> wrote: >
> > Hi Everyone,>
> > >
> > As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor

and>
> > 50 trivial open JIRAs and I note:>
> > >
> > - I think none of the blocker and critical JIRAs belong in that
category.>
> > - It is also unrealistic to have 733 major issues. it is like saying
we>
> > have that many serious problems>
> > - I think a realistic distribution would have a pyramid count with a
max>
> > (pyramid base) being trivial JIRAs.>
> > - A substantial number of jiras is old and no longer applicable.>
> > - A substantial number of jiras is vague and not understandable,
poorly>
> > written, without enough details to work on.>
> > - A substantial amount of jiras are placeholders for something to do>
> > without proper thinking and planning, which would make them unrealistic
or>
> > not applicable.>
> > - Some JIRAs are extremely granular. For example a task broken to
subtasks>
> > each for a tiny amount of work that is not worth the time and effort
of>
> > making so many tasks.>
> > >
> > So I think our issue tracking system is not properly used and we have
many>
> > JIRAs that are not useful and distracting. I propose the following
actions:>
> > >
> > - Add a wiki page (if one does not exist) documenting:>
> >   - Guidelines for writing JIRA mentioning clarity, provision of
solution.>
> >   - A clear definition of priorities (blocker, critical, major, minor,>
> > trivial) with some examples.>
> >   - A description of meaning of assignee and how to use it>
> >   - A description of other metadata and how to properly use it (tags,>
> > components, affects version, etc...)>
> > - we need to close all old, not applicable, vague and poorly written
JIRAs>
> > as per wiki guidelines. Alternatively authors can rewrite JIRAs to
comply>
> > with guidelines.>
> > - We need to fix priorities of all remaining JIRAs as per wiki
guidelines>
> > >
> > This would give us a realistic view of the _real_ issues in OFBiz
instead>
> > of drowning in so many JIRAs many of which are hindering rather than>
> > helping.>
> > >
> > What do you think?>
> > >
> > Taher Alkhateeb>
> > >
>

[Michael Brohl-3]

+1 on the Wiki page effort, it's great!

Not sure about the issue importance: for me, this is more an indicator
of how much this issue affects the project instead of a priority to deal
with it. I would leave it as that and maybe introduce a new field for
priority (if we do not already have one, haven't checked).

Maybe better use a sequence diagram
(https://en.wikipedia.org/wiki/Sequence_diagram) instead of a flow chart
for the issue status?

Michael


Am 06.09.16 um 12:37 schrieb Taher Alkhateeb:

> Hi Sharan, Everyone,
>
> Great work on the JIRA ->
> https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+Jira
>
> I like the fact that you denote all issues for trunk as being either minor
> or trivial. This does not mean they are not important or do not contain a
> lot of hard work. Instead it means they are not urgent, which is exactly
> the case for trunk (unstable)!
>
> One thing we can do to further improve the situation is to have a default
> value of "Trivial" to all newly created JIRAs so that people intentionally
> change it to whatever is more suitable. Another thing I note in the wiki is
> that the workflow (chart with arrows) is currently confusing. They need to
> be broken apart because too many lines intersect and you don't know which
> line goes where.
>
> Is this document a good start for adherence for all future JIRAs? Can we
> start guiding others towards the link for adherence to our requirements? Or
> do we need to finalize it first?
>
> Cheers,
>
> Taher Alkhateeb
>
> On 2016-09-05 14:06 ( 0300), "Sharan [hidden email]> wrote:
>> Hi Taher>
>>
>>   1 >
>>
>> You have raised some good actionable points here. I think you are right
> that the Jira guidelines need be completely separated out into something
> that is clear and can be used as an easy reference.>
>> I will create a wiki page to start pulling the information together.>
>>
>> Thanks>
>> Sharan>
>>
>> On 2016-09-03 07:56 ( 0200), Taher Alkhateeb <[hidden email]> wrote: >
>>> Hi Everyone,>
>>> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor
> and>
>>> 50 trivial open JIRAs and I note:>
>>> - I think none of the blocker and critical JIRAs belong in that
> category.>
>>> - It is also unrealistic to have 733 major issues. it is like saying
> we>
>>> have that many serious problems>
>>> - I think a realistic distribution would have a pyramid count with a
> max>
>>> (pyramid base) being trivial JIRAs.>
>>> - A substantial number of jiras is old and no longer applicable.>
>>> - A substantial number of jiras is vague and not understandable,
> poorly>
>>> written, without enough details to work on.>
>>> - A substantial amount of jiras are placeholders for something to do>
>>> without proper thinking and planning, which would make them unrealistic
> or>
>>> not applicable.>
>>> - Some JIRAs are extremely granular. For example a task broken to
> subtasks>
>>> each for a tiny amount of work that is not worth the time and effort
> of>
>>> making so many tasks.>
>>> So I think our issue tracking system is not properly used and we have
> many>
>>> JIRAs that are not useful and distracting. I propose the following
> actions:>
>>> - Add a wiki page (if one does not exist) documenting:>
>>>    - Guidelines for writing JIRA mentioning clarity, provision of
> solution.>
>>>    - A clear definition of priorities (blocker, critical, major, minor,>
>>> trivial) with some examples.>
>>>    - A description of meaning of assignee and how to use it>
>>>    - A description of other metadata and how to properly use it (tags,>
>>> components, affects version, etc...)>
>>> - we need to close all old, not applicable, vague and poorly written
> JIRAs>
>>> as per wiki guidelines. Alternatively authors can rewrite JIRAs to
> comply>
>>> with guidelines.>
>>> - We need to fix priorities of all remaining JIRAs as per wiki
> guidelines>
>>> This would give us a realistic view of the _real_ issues in OFBiz
> instead>
>>> of drowning in so many JIRAs many of which are hindering rather than>
>>> helping.>
>>> What do you think?>
>>> Taher Alkhateeb>

[Michael Brohl-3]

Please forget about my statement about priority, it IS Priority what we
are talking about...

Sorry for the confusion,

Michael


Am 06.09.16 um 12:55 schrieb Michael Brohl:

> +1 on the Wiki page effort, it's great!
>
> Not sure about the issue importance: for me, this is more an indicator
> of how much this issue affects the project instead of a priority to
> deal with it. I would leave it as that and maybe introduce a new field
> for priority (if we do not already have one, haven't checked).
>
> Maybe better use a sequence diagram
> (https://en.wikipedia.org/wiki/Sequence_diagram) instead of a flow
> chart for the issue status?
>
> Michael
>
>
> Am 06.09.16 um 12:37 schrieb Taher Alkhateeb:
>> Hi Sharan, Everyone,
>>
>> Great work on the JIRA ->
>> https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+Jira 
>>
>>
>> I like the fact that you denote all issues for trunk as being either
>> minor
>> or trivial. This does not mean they are not important or do not
>> contain a
>> lot of hard work. Instead it means they are not urgent, which is exactly
>> the case for trunk (unstable)!
>>
>> One thing we can do to further improve the situation is to have a
>> default
>> value of "Trivial" to all newly created JIRAs so that people
>> intentionally
>> change it to whatever is more suitable. Another thing I note in the
>> wiki is
>> that the workflow (chart with arrows) is currently confusing. They
>> need to
>> be broken apart because too many lines intersect and you don't know
>> which
>> line goes where.
>>
>> Is this document a good start for adherence for all future JIRAs? Can we
>> start guiding others towards the link for adherence to our
>> requirements? Or
>> do we need to finalize it first?
>>
>> Cheers,
>>
>> Taher Alkhateeb
>>
>> On 2016-09-05 14:06 ( 0300), "Sharan [hidden email]> wrote:
>>> Hi Taher>
>>>
>>>   1 >
>>>
>>> You have raised some good actionable points here. I think you are right
>> that the Jira guidelines need be completely separated out into something
>> that is clear and can be used as an easy reference.>
>>> I will create a wiki page to start pulling the information together.>
>>>
>>> Thanks>
>>> Sharan>
>>>
>>> On 2016-09-03 07:56 ( 0200), Taher Alkhateeb <[hidden email]> wrote: >
>>>> Hi Everyone,>
>>>> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor
>> and>
>>>> 50 trivial open JIRAs and I note:>
>>>> - I think none of the blocker and critical JIRAs belong in that
>> category.>
>>>> - It is also unrealistic to have 733 major issues. it is like saying
>> we>
>>>> have that many serious problems>
>>>> - I think a realistic distribution would have a pyramid count with a
>> max>
>>>> (pyramid base) being trivial JIRAs.>
>>>> - A substantial number of jiras is old and no longer applicable.>
>>>> - A substantial number of jiras is vague and not understandable,
>> poorly>
>>>> written, without enough details to work on.>
>>>> - A substantial amount of jiras are placeholders for something to do>
>>>> without proper thinking and planning, which would make them
>>>> unrealistic
>> or>
>>>> not applicable.>
>>>> - Some JIRAs are extremely granular. For example a task broken to
>> subtasks>
>>>> each for a tiny amount of work that is not worth the time and effort
>> of>
>>>> making so many tasks.>
>>>> So I think our issue tracking system is not properly used and we have
>> many>
>>>> JIRAs that are not useful and distracting. I propose the following
>> actions:>
>>>> - Add a wiki page (if one does not exist) documenting:>
>>>>    - Guidelines for writing JIRA mentioning clarity, provision of
>> solution.>
>>>>    - A clear definition of priorities (blocker, critical, major,
>>>> minor,>
>>>> trivial) with some examples.>
>>>>    - A description of meaning of assignee and how to use it>
>>>>    - A description of other metadata and how to properly use it
>>>> (tags,>
>>>> components, affects version, etc...)>
>>>> - we need to close all old, not applicable, vague and poorly written
>> JIRAs>
>>>> as per wiki guidelines. Alternatively authors can rewrite JIRAs to
>> comply>
>>>> with guidelines.>
>>>> - We need to fix priorities of all remaining JIRAs as per wiki
>> guidelines>
>>>> This would give us a realistic view of the _real_ issues in OFBiz
>> instead>
>>>> of drowning in so many JIRAs many of which are hindering rather than>
>>>> helping.>
>>>> What do you think?>
>>>> Taher Alkhateeb>
>
>

[Sharan Foga]

Hi Michael

Responses inline.

On 2016-09-06 12:55 (+0200), Michael Brohl <[hidden email]> wrote:
> +1 on the Wiki page effort, it's great!
>
> Not sure about the issue importance: for me, this is more an indicator
> of how much this issue affects the project instead of a priority to deal
> with it. I would leave it as that and maybe introduce a new field for
> priority (if we do not already have one, haven't checked).
>

I think 'Priority' is generally about the urgency of an issue and impact is about the effect it has. Perhaps we need a field or flag for the issue impact. (I will take a look to see if one already exists that we could add to our form)

> Maybe better use a sequence diagram
> (https://en.wikipedia.org/wiki/Sequence_diagram) instead of a flow chart
> for the issue status?

The diagram I pulled out came directly out of Jira itself so if people think its a good idea to have something simpler then that's doable too.

>
> Michael
>

Thanks
Sharan

>
> Am 06.09.16 um 12:37 schrieb Taher Alkhateeb:
> > Hi Sharan, Everyone,
> >
> > Great work on the JIRA ->
> > https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+Jira
> >
> > I like the fact that you denote all issues for trunk as being either minor
> > or trivial. This does not mean they are not important or do not contain a
> > lot of hard work. Instead it means they are not urgent, which is exactly
> > the case for trunk (unstable)!
> >
> > One thing we can do to further improve the situation is to have a default
> > value of "Trivial" to all newly created JIRAs so that people intentionally
> > change it to whatever is more suitable. Another thing I note in the wiki is
> > that the workflow (chart with arrows) is currently confusing. They need to
> > be broken apart because too many lines intersect and you don't know which
> > line goes where.
> >
> > Is this document a good start for adherence for all future JIRAs? Can we
> > start guiding others towards the link for adherence to our requirements? Or
> > do we need to finalize it first?
> >
> > Cheers,
> >
> > Taher Alkhateeb
> >
> > On 2016-09-05 14:06 ( 0300), "Sharan [hidden email]> wrote:
> >> Hi Taher>
> >>
> >>   1 >
> >>
> >> You have raised some good actionable points here. I think you are right
> > that the Jira guidelines need be completely separated out into something
> > that is clear and can be used as an easy reference.>
> >> I will create a wiki page to start pulling the information together.>
> >>
> >> Thanks>
> >> Sharan>
> >>
> >> On 2016-09-03 07:56 ( 0200), Taher Alkhateeb <[hidden email]> wrote: >
> >>> Hi Everyone,>
> >>> As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor
> > and>
> >>> 50 trivial open JIRAs and I note:>
> >>> - I think none of the blocker and critical JIRAs belong in that
> > category.>
> >>> - It is also unrealistic to have 733 major issues. it is like saying
> > we>
> >>> have that many serious problems>
> >>> - I think a realistic distribution would have a pyramid count with a
> > max>
> >>> (pyramid base) being trivial JIRAs.>
> >>> - A substantial number of jiras is old and no longer applicable.>
> >>> - A substantial number of jiras is vague and not understandable,
> > poorly>
> >>> written, without enough details to work on.>
> >>> - A substantial amount of jiras are placeholders for something to do>
> >>> without proper thinking and planning, which would make them unrealistic
> > or>
> >>> not applicable.>
> >>> - Some JIRAs are extremely granular. For example a task broken to
> > subtasks>
> >>> each for a tiny amount of work that is not worth the time and effort
> > of>
> >>> making so many tasks.>
> >>> So I think our issue tracking system is not properly used and we have
> > many>
> >>> JIRAs that are not useful and distracting. I propose the following
> > actions:>
> >>> - Add a wiki page (if one does not exist) documenting:>
> >>>    - Guidelines for writing JIRA mentioning clarity, provision of
> > solution.>
> >>>    - A clear definition of priorities (blocker, critical, major, minor,>
> >>> trivial) with some examples.>
> >>>    - A description of meaning of assignee and how to use it>
> >>>    - A description of other metadata and how to properly use it (tags,>
> >>> components, affects version, etc...)>
> >>> - we need to close all old, not applicable, vague and poorly written
> > JIRAs>
> >>> as per wiki guidelines. Alternatively authors can rewrite JIRAs to
> > comply>
> >>> with guidelines.>
> >>> - We need to fix priorities of all remaining JIRAs as per wiki
> > guidelines>
> >>> This would give us a realistic view of the _real_ issues in OFBiz
> > instead>
> >>> of drowning in so many JIRAs many of which are hindering rather than>
> >>> helping.>
> >>> What do you think?>
> >>> Taher Alkhateeb>
>
>
>

[Sharan Foga]

Hi Taher

Response inline

Thanks
Sharan

On 2016-09-06 12:37 (+0200), Taher Alkhateeb <[hidden email]> wrote:

> Hi Sharan, Everyone,
>
> Great work on the JIRA ->
> https://cwiki.apache.org/confluence/display/OFBIZ/Guidelines+for+Using+Jira
>
> I like the fact that you denote all issues for trunk as being either minor
> or trivial. This does not mean they are not important or do not contain a
> lot of hard work. Instead it means they are not urgent, which is exactly
> the case for trunk (unstable)!
>

This was one of the main points I wanted to get across. For any issue system the blocking and critical issues are problems with the production system (which for us is our stable releases).

We are in transition to our next stable release - so if there is an option we could look at including any issues identified with our unreleased branches 14.12 and 15.12 at a higher priority but that could be a discussion point.


> One thing we can do to further improve the situation is to have a default
> value of "Trivial" to all newly created JIRAs so that people intentionally
> change it to whatever is more suitable.

+1  

I'm not sure what the default value is at the moment but starting it at the lowest put the responsibility on the creator to use the guidelines and prioritise it correctly.

 Another thing I note in the wiki is
> that the workflow (chart with arrows) is currently confusing. They need to
> be broken apart because too many lines intersect and you don't know which
> line goes where.
>

This diagram is a cut and paste from Jira so we could look at simplifying it to make it easier to read.

> Is this document a good start for adherence for all future JIRAs? Can we
> start guiding others towards the link for adherence to our requirements? Or
> do we need to finalize it first?
>

I'd like to tidy it up a bit more (give me a day or 2) and then start a mailing list discussion to make sure the community feels happy about adopting the guidelines.

> Cheers,
>
> Taher Alkhateeb
>
> On 2016-09-05 14:06 ( 0300), "Sharan [hidden email]> wrote:
> > Hi Taher>
> >
> >  1 >
> >
> > You have raised some good actionable points here. I think you are right
> that the Jira guidelines need be completely separated out into something
> that is clear and can be used as an easy reference.>
> >
> > I will create a wiki page to start pulling the information together.>
> >
> > Thanks>
> > Sharan>
> >
> > On 2016-09-03 07:56 ( 0200), Taher Alkhateeb <[hidden email]> wrote: >
> > > Hi Everyone,>
> > > >
> > > As of this writing, we have 3 blocker, 6 critical 733 major, 521 minor
> and>
> > > 50 trivial open JIRAs and I note:>
> > > >
> > > - I think none of the blocker and critical JIRAs belong in that
> category.>
> > > - It is also unrealistic to have 733 major issues. it is like saying
> we>
> > > have that many serious problems>
> > > - I think a realistic distribution would have a pyramid count with a
> max>
> > > (pyramid base) being trivial JIRAs.>
> > > - A substantial number of jiras is old and no longer applicable.>
> > > - A substantial number of jiras is vague and not understandable,
> poorly>
> > > written, without enough details to work on.>
> > > - A substantial amount of jiras are placeholders for something to do>
> > > without proper thinking and planning, which would make them unrealistic
> or>
> > > not applicable.>
> > > - Some JIRAs are extremely granular. For example a task broken to
> subtasks>
> > > each for a tiny amount of work that is not worth the time and effort
> of>
> > > making so many tasks.>
> > > >
> > > So I think our issue tracking system is not properly used and we have
> many>
> > > JIRAs that are not useful and distracting. I propose the following
> actions:>
> > > >
> > > - Add a wiki page (if one does not exist) documenting:>
> > >   - Guidelines for writing JIRA mentioning clarity, provision of
> solution.>
> > >   - A clear definition of priorities (blocker, critical, major, minor,>
> > > trivial) with some examples.>
> > >   - A description of meaning of assignee and how to use it>
> > >   - A description of other metadata and how to properly use it (tags,>
> > > components, affects version, etc...)>
> > > - we need to close all old, not applicable, vague and poorly written
> JIRAs>
> > > as per wiki guidelines. Alternatively authors can rewrite JIRAs to
> comply>
> > > with guidelines.>
> > > - We need to fix priorities of all remaining JIRAs as per wiki
> guidelines>
> > > >
> > > This would give us a realistic view of the _real_ issues in OFBiz
> instead>
> > > of drowning in so many JIRAs many of which are hindering rather than>
> > > helping.>
> > > >
> > > What do you think?>
> > > >
> > > Taher Alkhateeb>
> > > >
> >
>