OFBiz › OFBiz - Dev

Proposal of guidelines for the creation of Jira issues

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

20 messages Options

Jacopo Cappellato

Proposal of guidelines for the creation of Jira issues

I would like to discuss with you some guidelines for Jira issue creation.
The idea is to limit the noise in Jira and prevent the creation of Jira
issues with low informative value that will stay open forever.

Here are some ideas:

1) If you already have a patch for an improvement/fix then create a Jira
issue (if there is not one already) and attach your patch to it

2) If you don't have a patch, and you have discovered a *bug*, create a
Jira issue (if there is not one already) providing as much details as
possible (including the rev. number and the environment you are using,
and the step to recreate the bug)

3) If you don't have a patch, and you have want to suggest an
enhancement or new feature, then discuss this in the dev mailing list
instead of creating a Jira issue; at the end of the discussion, the
community will consider if a summary of the thread should be saved in a
new Jira issue, to facilitate future development

4) If you don't have a patch, but you are planning to work on it, and
you want to share your design details with the community, you should
discuss this in the mailing list instead of creating a Jira issue; if,
on the other hand, you don't have time to do this, you have already
decided that you want to implement your patch following your design
notes, and you just want to let the community know about the upcoming
patch, you can create a Jira issue (to which you will attach your patch
when it is ready);

Summarizing:

* bugs: always create a new Jira issue everytime you find a new bug
* new features/enhancements: create new Jira issue only if you have a
patch (or if you plan to submit it very soon)

What do you think?

Jacopo

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

what is your time frame for soon?
what if the person followed your criteria and sometime effected the
submission time?

Jacopo Cappellato sent the following on 12/23/2007 12:34 AM:

> I would like to discuss with you some guidelines for Jira issue creation.
> The idea is to limit the noise in Jira and prevent the creation of Jira
> issues with low informative value that will stay open forever.
>
> Here are some ideas:
>
> 1) If you already have a patch for an improvement/fix then create a Jira
> issue (if there is not one already) and attach your patch to it
>
> 2) If you don't have a patch, and you have discovered a *bug*, create a
> Jira issue (if there is not one already) providing as much details as
> possible (including the rev. number and the environment you are using,
> and the step to recreate the bug)
>
> 3) If you don't have a patch, and you have want to suggest an
> enhancement or new feature, then discuss this in the dev mailing list
> instead of creating a Jira issue; at the end of the discussion, the
> community will consider if a summary of the thread should be saved in a
> new Jira issue, to facilitate future development
>
> 4) If you don't have a patch, but you are planning to work on it, and
> you want to share your design details with the community, you should
> discuss this in the mailing list instead of creating a Jira issue; if,
> on the other hand, you don't have time to do this, you have already
> decided that you want to implement your patch following your design
> notes, and you just want to let the community know about the upcoming
> patch, you can create a Jira issue (to which you will attach your patch
> when it is ready);
>
> Summarizing:
>
> * bugs: always create a new Jira issue everytime you find a new bug
> * new features/enhancements: create new Jira issue only if you have a
> patch (or if you plan to submit it very soon)
>
> What do you think?
>
> Jacopo
>
>
>
>

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by Jacopo Cappellato

as a side note, on a project that effects many components and with some
of the changes that happen in the trunk, it is requires re-work of the
code then testing. this may significantly extend the period till
submitting of a patch.

Jacopo Cappellato sent the following on 12/23/2007 12:34 AM:

Jacques Le Roux

Re: Proposal of guidelines for the creation of Jira issues

Administrator

In reply to this post by Jacopo Cappellato

+1

I would just add a requirement, especially for "(if there is not one already)" below but not only. Before creating any Jira issue
check, using some related key words, if a similar issue does not exist already. For that you can 1st use the quich search at top
right of Jira pages and after refine your search using relevant informaation. For instance by default all projects are scanned, you
may then search only in OFBiz, etc.

Jacques

From: "Jacopo Cappellato" <[hidden email]>

>I would like to discuss with you some guidelines for Jira issue creation.
> The idea is to limit the noise in Jira and prevent the creation of Jira issues with low informative value that will stay open
> forever.
>
> Here are some ideas:
>
> 1) If you already have a patch for an improvement/fix then create a Jira issue (if there is not one already) and attach your patch
> to it
>
> 2) If you don't have a patch, and you have discovered a *bug*, create a Jira issue (if there is not one already) providing as much
> details as possible (including the rev. number and the environment you are using, and the step to recreate the bug)
>
> 3) If you don't have a patch, and you have want to suggest an enhancement or new feature, then discuss this in the dev mailing
> list instead of creating a Jira issue; at the end of the discussion, the community will consider if a summary of the thread should
> be saved in a new Jira issue, to facilitate future development
>
> 4) If you don't have a patch, but you are planning to work on it, and you want to share your design details with the community,
> you should discuss this in the mailing list instead of creating a Jira issue; if, on the other hand, you don't have time to do
> this, you have already decided that you want to implement your patch following your design notes, and you just want to let the
> community know about the upcoming patch, you can create a Jira issue (to which you will attach your patch when it is ready);
>
> Summarizing:
>
> * bugs: always create a new Jira issue everytime you find a new bug
> * new features/enhancements: create new Jira issue only if you have a patch (or if you plan to submit it very soon)
>
> What do you think?
>
> Jacopo
>
>

cjhowe

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by Jacopo Cappellato

I realize that many of us are process minded people and so Jira issues that are left open indefinitely tend to irk us a bit. However, Jira can have some benefit as a repository of ideas and not simply as a workflow tool. Discussion in a mailing list tends to be time period driven and not so much issue driven. If you're looking for a guideline to satisfy that process mined mentality, I would suggest that 3) and 4) be replaced with:

3') If an issue that is not a bug is left open for 30 days without a patch, it be closed with the resolution of "Later"
4') If an issue has been in the resolution of "Later" has been without activity for 365 days, change the resolution to "Won't fix"

or some such

----- Original Message ----
From: Jacopo Cappellato <[hidden email]>
To: [hidden email]
Sent: Sunday, December 23, 2007 2:34:04 AM
Subject: Proposal of guidelines for the creation of Jira issues

I would like to discuss with you some guidelines for Jira issue
creation.
The idea is to limit the noise in Jira and prevent the creation of Jira

issues with low informative value that will stay open forever.

Here are some ideas:

1) If you already have a patch for an improvement/fix then create a
Jira
issue (if there is not one already) and attach your patch to it

2) If you don't have a patch, and you have discovered a *bug*, create a

Jira issue (if there is not one already) providing as much details as
possible (including the rev. number and the environment you are using,
and the step to recreate the bug)

3) If you don't have a patch, and you have want to suggest an
enhancement or new feature, then discuss this in the dev mailing list
instead of creating a Jira issue; at the end of the discussion, the
community will consider if a summary of the thread should be saved in a

new Jira issue, to facilitate future development

4) If you don't have a patch, but you are planning to work on it, and
you want to share your design details with the community, you should
discuss this in the mailing list instead of creating a Jira issue; if,
on the other hand, you don't have time to do this, you have already
decided that you want to implement your patch following your design
notes, and you just want to let the community know about the upcoming
patch, you can create a Jira issue (to which you will attach your patch

when it is ready);

Summarizing:

* bugs: always create a new Jira issue everytime you find a new bug
* new features/enhancements: create new Jira issue only if you have a
patch (or if you plan to submit it very soon)

What do you think?

Jacopo

Jacopo Cappellato

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by BJ Freeman

BJ Freeman wrote:
> what is your time frame for soon?
> what if the person followed your criteria and sometime effected the
> submission time?

Nothing will happen... these are guidelines, not strict rules... no
penalties ;-)

Jacopo

>
> Jacopo Cappellato sent the following on 12/23/2007 12:34 AM:
>> I would like to discuss with you some guidelines for Jira issue creation.
>> The idea is to limit the noise in Jira and prevent the creation of Jira
>> issues with low informative value that will stay open forever.
>>
>> Here are some ideas:
>>
>> 1) If you already have a patch for an improvement/fix then create a Jira
>> issue (if there is not one already) and attach your patch to it
>>
>> 2) If you don't have a patch, and you have discovered a *bug*, create a
>> Jira issue (if there is not one already) providing as much details as
>> possible (including the rev. number and the environment you are using,
>> and the step to recreate the bug)
>>
>> 3) If you don't have a patch, and you have want to suggest an
>> enhancement or new feature, then discuss this in the dev mailing list
>> instead of creating a Jira issue; at the end of the discussion, the
>> community will consider if a summary of the thread should be saved in a
>> new Jira issue, to facilitate future development
>>
>> 4) If you don't have a patch, but you are planning to work on it, and
>> you want to share your design details with the community, you should
>> discuss this in the mailing list instead of creating a Jira issue; if,
>> on the other hand, you don't have time to do this, you have already
>> decided that you want to implement your patch following your design
>> notes, and you just want to let the community know about the upcoming
>> patch, you can create a Jira issue (to which you will attach your patch
>> when it is ready);
>>
>> Summarizing:
>>
>> * bugs: always create a new Jira issue everytime you find a new bug
>> * new features/enhancements: create new Jira issue only if you have a
>> patch (or if you plan to submit it very soon)
>>
>> What do you think?
>>
>> Jacopo
>>
>>
>>
>>

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by cjhowe

on the point of time periods, I would like the process minded and bean
counting people to realize we are not in a static but a dynamic environment.
I can see, for instance, in the branch, of having the written in stone
time frame, since it is a static, for all intent and purposes.
However the trunk just went through a major revision not more than a
month ago that reset the time frame, as of that point, for projects that
were being worked, on before that point.
They were revisions, that though good, were not discussed or warned
about so those projects in progress could evaluate and make corrections
as the changes were discussed.

Chris Howe sent the following on 12/23/2007 5:58 AM:

> I realize that many of us are process minded people and so Jira issues that are left open indefinitely tend to irk us a bit. However, Jira can have some benefit as a repository of ideas and not simply as a workflow tool. Discussion in a mailing list tends to be time period driven and not so much issue driven. If you're looking for a guideline to satisfy that process mined mentality, I would suggest that 3) and 4) be replaced with:
>
> 3') If an issue that is not a bug is left open for 30 days without a patch, it be closed with the resolution of "Later"
> 4') If an issue has been in the resolution of "Later" has been without activity for 365 days, change the resolution to "Won't fix"
>
> or some such
>
> ----- Original Message ----
> From: Jacopo Cappellato <[hidden email]>
> To: [hidden email]
> Sent: Sunday, December 23, 2007 2:34:04 AM
> Subject: Proposal of guidelines for the creation of Jira issues
>
>
> I would like to discuss with you some guidelines for Jira issue
> creation.
> The idea is to limit the noise in Jira and prevent the creation of Jira
>
> issues with low informative value that will stay open forever.
>
> Here are some ideas:
>
> 1) If you already have a patch for an improvement/fix then create a
> Jira
> issue (if there is not one already) and attach your patch to it
>
> 2) If you don't have a patch, and you have discovered a *bug*, create a
>
> Jira issue (if there is not one already) providing as much details as
> possible (including the rev. number and the environment you are using,
> and the step to recreate the bug)
>
> 3) If you don't have a patch, and you have want to suggest an
> enhancement or new feature, then discuss this in the dev mailing list
> instead of creating a Jira issue; at the end of the discussion, the
> community will consider if a summary of the thread should be saved in a
>
> new Jira issue, to facilitate future development
>
> 4) If you don't have a patch, but you are planning to work on it, and
> you want to share your design details with the community, you should
> discuss this in the mailing list instead of creating a Jira issue; if,
> on the other hand, you don't have time to do this, you have already
> decided that you want to implement your patch following your design
> notes, and you just want to let the community know about the upcoming
> patch, you can create a Jira issue (to which you will attach your patch
>
> when it is ready);
>
> Summarizing:
>
> * bugs: always create a new Jira issue everytime you find a new bug
> * new features/enhancements: create new Jira issue only if you have a
> patch (or if you plan to submit it very soon)
>
> What do you think?
>
> Jacopo
>
>
>
>
>
>
>

Christopher L

RE: Proposal of guidelines for the creation of Jira issues

In reply to this post by cjhowe

IMHO, 30 days is a bit tight. I like to leave my issues open for comment for at least a week or two before I implement them. Then add in delays for miscellaneous stuff and time to implement, and I'm way beyond 30 days.

My issues also tend to interest a subset of users and I think my issues would get lost in the traffic on the list.

I don't object to periodic cleaning of jira. Jira does perform a valuable service for me, keeping track of my issues so I don't have to go trolling through the list archives. Admittedly, this system will work well for the main contributors, but it will keep lower volume, intermittent contributors, such as myself, out of the system. I don't think that's the intended result.

My 2c.

Chris

> Date: Sun, 23 Dec 2007 05:58:06 -0800
> From: [hidden email]
> Subject: Re: Proposal of guidelines for the creation of Jira issues
> To: [hidden email]
>
> I realize that many of us are process minded people and so Jira issues that are left open indefinitely tend to irk us a bit. However, Jira can have some benefit as a repository of ideas and not simply as a workflow tool. Discussion in a mailing list tends to be time period driven and not so much issue driven. If you're looking for a guideline to satisfy that process mined mentality, I would suggest that 3) and 4) be replaced with:
>
> 3') If an issue that is not a bug is left open for 30 days without a patch, it be closed with the resolution of "Later"
> 4') If an issue has been in the resolution of "Later" has been without activity for 365 days, change the resolution to "Won't fix"
>
> or some such
>
> ----- Original Message ----
> From: Jacopo Cappellato <[hidden email]>
> To: [hidden email]
> Sent: Sunday, December 23, 2007 2:34:04 AM
> Subject: Proposal of guidelines for the creation of Jira issues
>
>
> I would like to discuss with you some guidelines for Jira issue
> creation.
> The idea is to limit the noise in Jira and prevent the creation of Jira
>
> issues with low informative value that will stay open forever.
>
> Here are some ideas:
>
> 1) If you already have a patch for an improvement/fix then create a
> Jira
> issue (if there is not one already) and attach your patch to it
>
> 2) If you don't have a patch, and you have discovered a *bug*, create a
>
> Jira issue (if there is not one already) providing as much details as
> possible (including the rev. number and the environment you are using,
> and the step to recreate the bug)
>
> 3) If you don't have a patch, and you have want to suggest an
> enhancement or new feature, then discuss this in the dev mailing list
> instead of creating a Jira issue; at the end of the discussion, the
> community will consider if a summary of the thread should be saved in a
>
> new Jira issue, to facilitate future development
>
> 4) If you don't have a patch, but you are planning to work on it, and
> you want to share your design details with the community, you should
> discuss this in the mailing list instead of creating a Jira issue; if,
> on the other hand, you don't have time to do this, you have already
> decided that you want to implement your patch following your design
> notes, and you just want to let the community know about the upcoming
> patch, you can create a Jira issue (to which you will attach your patch
>
> when it is ready);
>
> Summarizing:
>
> * bugs: always create a new Jira issue everytime you find a new bug
> * new features/enhancements: create new Jira issue only if you have a
> patch (or if you plan to submit it very soon)
>
> What do you think?
>
> Jacopo
>
>
>
>

cjhowe

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by Jacopo Cappellato

I'm just tossing out 30 days. But even if it were such a time period, if there was activity with it after 30 days, you would simply reopen the issue.

----- Original Message ----
From: Christopher L <[hidden email]>
To: [hidden email]
Sent: Sunday, December 23, 2007 2:19:01 PM
Subject: RE: Proposal of guidelines for the creation of Jira issues

IMHO, 30 days is a bit tight. I like to leave my issues open for
comment for at least a week or two before I implement them. Then add in
delays for miscellaneous stuff and time to implement, and I'm way beyond
30 days.

My issues also tend to interest a subset of users and I think my issues
would get lost in the traffic on the list.

I don't object to periodic cleaning of jira. Jira does perform a
valuable service for me, keeping track of my issues so I don't have to go
trolling through the list archives. Admittedly, this system will work
well for the main contributors, but it will keep lower volume,
intermittent contributors, such as myself, out of the system. I don't think
that's the intended result.

My 2c.

Chris

> Date: Sun, 23 Dec 2007 05:58:06 -0800
> From: [hidden email]
> Subject: Re: Proposal of guidelines for the creation of Jira issues
> To: [hidden email]
>
> I realize that many of us are process minded people and so Jira
issues that are left open indefinitely tend to irk us a bit. However, Jira
can have some benefit as a repository of ideas and not simply as a
workflow tool. Discussion in a mailing list tends to be time period driven
and not so much issue driven. If you're looking for a guideline to
satisfy that process mined mentality, I would suggest that 3) and 4) be
replaced with:
>
> 3') If an issue that is not a bug is left open for 30 days without a
patch, it be closed with the resolution of "Later"
> 4') If an issue has been in the resolution of "Later" has been
without activity for 365 days, change the resolution to "Won't fix"

>
> or some such
>
> ----- Original Message ----
> From: Jacopo Cappellato <[hidden email]>
> To: [hidden email]
> Sent: Sunday, December 23, 2007 2:34:04 AM
> Subject: Proposal of guidelines for the creation of Jira issues
>
>
> I would like to discuss with you some guidelines for Jira issue
> creation.
> The idea is to limit the noise in Jira and prevent the creation of

Jira

>
> issues with low informative value that will stay open forever.
>
> Here are some ideas:
>
> 1) If you already have a patch for an improvement/fix then create a
> Jira
> issue (if there is not one already) and attach your patch to it
>
> 2) If you don't have a patch, and you have discovered a *bug*, create

a
>
> Jira issue (if there is not one already) providing as much details as

> possible (including the rev. number and the environment you are
using,
> and the step to recreate the bug)
>
> 3) If you don't have a patch, and you have want to suggest an
> enhancement or new feature, then discuss this in the dev mailing list

> instead of creating a Jira issue; at the end of the discussion, the
> community will consider if a summary of the thread should be saved in
a
>
> new Jira issue, to facilitate future development
>
> 4) If you don't have a patch, but you are planning to work on it, and

> you want to share your design details with the community, you should
> discuss this in the mailing list instead of creating a Jira issue;
if,
> on the other hand, you don't have time to do this, you have already
> decided that you want to implement your patch following your design
> notes, and you just want to let the community know about the upcoming

> patch, you can create a Jira issue (to which you will attach your
patch
>
> when it is ready);
>
> Summarizing:
>
> * bugs: always create a new Jira issue everytime you find a new bug
> * new features/enhancements: create new Jira issue only if you have a

> patch (or if you plan to submit it very soon)
>
> What do you think?
>
> Jacopo
>
>
>
>

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

That is another point that has me confused.
since we can re-open a issue, I am confused by the statement to open
another issue when ready.

Chris Howe sent the following on 12/23/2007 12:25 PM:

> I'm just tossing out 30 days. But even if it were such a time period, if there was activity with it after 30 days, you would simply reopen the issue.
>
> ----- Original Message ----
> From: Christopher L <[hidden email]>
> To: [hidden email]
> Sent: Sunday, December 23, 2007 2:19:01 PM
> Subject: RE: Proposal of guidelines for the creation of Jira issues
>
>
> IMHO, 30 days is a bit tight. I like to leave my issues open for
> comment for at least a week or two before I implement them. Then add in
> delays for miscellaneous stuff and time to implement, and I'm way beyond
> 30 days.
>
> My issues also tend to interest a subset of users and I think my issues
> would get lost in the traffic on the list.
>
> I don't object to periodic cleaning of jira. Jira does perform a
> valuable service for me, keeping track of my issues so I don't have to go
> trolling through the list archives. Admittedly, this system will work
> well for the main contributors, but it will keep lower volume,
> intermittent contributors, such as myself, out of the system. I don't think
> that's the intended result.
>
> My 2c.
>
> Chris
>
>> Date: Sun, 23 Dec 2007 05:58:06 -0800
>> From: [hidden email]
>> Subject: Re: Proposal of guidelines for the creation of Jira issues
>> To: [hidden email]
>>
>> I realize that many of us are process minded people and so Jira
> issues that are left open indefinitely tend to irk us a bit. However, Jira
> can have some benefit as a repository of ideas and not simply as a
> workflow tool. Discussion in a mailing list tends to be time period driven
> and not so much issue driven. If you're looking for a guideline to
> satisfy that process mined mentality, I would suggest that 3) and 4) be
> replaced with:
>> 3') If an issue that is not a bug is left open for 30 days without a
> patch, it be closed with the resolution of "Later"
>> 4') If an issue has been in the resolution of "Later" has been
> without activity for 365 days, change the resolution to "Won't fix"
>> or some such
>>
>> ----- Original Message ----
>> From: Jacopo Cappellato <[hidden email]>
>> To: [hidden email]
>> Sent: Sunday, December 23, 2007 2:34:04 AM
>> Subject: Proposal of guidelines for the creation of Jira issues
>>
>>
>> I would like to discuss with you some guidelines for Jira issue
>> creation.
>> The idea is to limit the noise in Jira and prevent the creation of
> Jira
>>
>> issues with low informative value that will stay open forever.
>>
>> Here are some ideas:
>>
>> 1) If you already have a patch for an improvement/fix then create a
>> Jira
>> issue (if there is not one already) and attach your patch to it
>>
>> 2) If you don't have a patch, and you have discovered a *bug*, create
> a
>>
>> Jira issue (if there is not one already) providing as much details as
>
>> possible (including the rev. number and the environment you are
> using,
>> and the step to recreate the bug)
>>
>> 3) If you don't have a patch, and you have want to suggest an
>> enhancement or new feature, then discuss this in the dev mailing list
>
>> instead of creating a Jira issue; at the end of the discussion, the
>> community will consider if a summary of the thread should be saved in
> a
>>
>> new Jira issue, to facilitate future development
>>
>> 4) If you don't have a patch, but you are planning to work on it, and
>
>> you want to share your design details with the community, you should
>> discuss this in the mailing list instead of creating a Jira issue;
> if,
>> on the other hand, you don't have time to do this, you have already
>> decided that you want to implement your patch following your design
>> notes, and you just want to let the community know about the upcoming
>
>> patch, you can create a Jira issue (to which you will attach your
> patch
>>
>> when it is ready);
>>
>> Summarizing:
>>
>> * bugs: always create a new Jira issue everytime you find a new bug
>> * new features/enhancements: create new Jira issue only if you have a
>
>> patch (or if you plan to submit it very soon)
>>
>> What do you think?
>>
>> Jacopo
>>
>>
>>
>>
>
>
>
>
>
>

David E Jones

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by cjhowe

Jira might not be the best place for new ideas and desired features
that won't be acted on in the near future. I think the point Jacopo is
making is that the issue tracker is more about issues, about things
that need attention in the near future.

After a brief discussion on the mailing list, or even without that, I
think a great place to organize thoughts around new enhancements or
ideas for things is the wiki section of the Confluence server (OFBIZ
space on docs.ofbiz.org). Things are much more flexible there, can be
hierarchical more naturally, and can live for a long time as part of
research and such by multiple people.

Does that strike anyone as a good or bad idea?

-David

On Dec 23, 2007, at 12:25 PM, Chris Howe wrote:

> I'm just tossing out 30 days. But even if it were such a time
> period, if there was activity with it after 30 days, you would
> simply reopen the issue.
>
> ----- Original Message ----
> From: Christopher L <[hidden email]>
> To: [hidden email]
> Sent: Sunday, December 23, 2007 2:19:01 PM
> Subject: RE: Proposal of guidelines for the creation of Jira issues
>
>
> IMHO, 30 days is a bit tight. I like to leave my issues open for
> comment for at least a week or two before I implement them. Then
> add in
> delays for miscellaneous stuff and time to implement, and I'm way
> beyond
> 30 days.
>
> My issues also tend to interest a subset of users and I think my
> issues
> would get lost in the traffic on the list.
>
> I don't object to periodic cleaning of jira. Jira does perform a
> valuable service for me, keeping track of my issues so I don't have
> to go
> trolling through the list archives. Admittedly, this system will work
> well for the main contributors, but it will keep lower volume,
> intermittent contributors, such as myself, out of the system. I
> don't think
> that's the intended result.
>
> My 2c.
>
> Chris
>
>> Date: Sun, 23 Dec 2007 05:58:06 -0800
>> From: [hidden email]
>> Subject: Re: Proposal of guidelines for the creation of Jira issues
>> To: [hidden email]
>>
>> I realize that many of us are process minded people and so Jira
> issues that are left open indefinitely tend to irk us a bit.
> However, Jira
> can have some benefit as a repository of ideas and not simply as a
> workflow tool. Discussion in a mailing list tends to be time period
> driven
> and not so much issue driven. If you're looking for a guideline to
> satisfy that process mined mentality, I would suggest that 3) and 4)
> be
> replaced with:
>>
>> 3') If an issue that is not a bug is left open for 30 days without a
> patch, it be closed with the resolution of "Later"
>> 4') If an issue has been in the resolution of "Later" has been
> without activity for 365 days, change the resolution to "Won't fix"
>>
>> or some such
>>
>> ----- Original Message ----
>> From: Jacopo Cappellato <[hidden email]>
>> To: [hidden email]
>> Sent: Sunday, December 23, 2007 2:34:04 AM
>> Subject: Proposal of guidelines for the creation of Jira issues
>>
>>
>> I would like to discuss with you some guidelines for Jira issue
>> creation.
>> The idea is to limit the noise in Jira and prevent the creation of
> Jira
>>
>> issues with low informative value that will stay open forever.
>>
>> Here are some ideas:
>>
>> 1) If you already have a patch for an improvement/fix then create a
>> Jira
>> issue (if there is not one already) and attach your patch to it
>>
>> 2) If you don't have a patch, and you have discovered a *bug*, create
> a
>>
>> Jira issue (if there is not one already) providing as much details as
>
>> possible (including the rev. number and the environment you are
> using,
>> and the step to recreate the bug)
>>
>> 3) If you don't have a patch, and you have want to suggest an
>> enhancement or new feature, then discuss this in the dev mailing list
>
>> instead of creating a Jira issue; at the end of the discussion, the
>> community will consider if a summary of the thread should be saved in
> a
>>
>> new Jira issue, to facilitate future development
>>
>> 4) If you don't have a patch, but you are planning to work on it, and
>
>> you want to share your design details with the community, you should
>> discuss this in the mailing list instead of creating a Jira issue;
> if,
>> on the other hand, you don't have time to do this, you have already
>> decided that you want to implement your patch following your design
>> notes, and you just want to let the community know about the upcoming
>
>> patch, you can create a Jira issue (to which you will attach your
> patch
>>
>> when it is ready);
>>
>> Summarizing:
>>
>> * bugs: always create a new Jira issue everytime you find a new bug
>> * new features/enhancements: create new Jira issue only if you have a
>
>> patch (or if you plan to submit it very soon)
>>
>> What do you think?
>>
>> Jacopo
>>
>>
>>
>>
>
>
>

smime.p7s (3K) Download Attachment

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

+1
lot of times I want to toss something out and get feedback.
Don't see the Dev list or Jira the most appropiate but the only resouces
currently.
Up till now I have seen the wiki more as a resources of information
that does not fit into other constructs.

David E Jones sent the following on 12/23/2007 12:59 PM:

>
> Jira might not be the best place for new ideas and desired features that
> won't be acted on in the near future. I think the point Jacopo is making
> is that the issue tracker is more about issues, about things that need
> attention in the near future.
>
> After a brief discussion on the mailing list, or even without that, I
> think a great place to organize thoughts around new enhancements or
> ideas for things is the wiki section of the Confluence server (OFBIZ
> space on docs.ofbiz.org). Things are much more flexible there, can be
> hierarchical more naturally, and can live for a long time as part of
> research and such by multiple people.
>
> Does that strike anyone as a good or bad idea?
>
> -David
>
>
> On Dec 23, 2007, at 12:25 PM, Chris Howe wrote:
>
>> I'm just tossing out 30 days. But even if it were such a time period,
>> if there was activity with it after 30 days, you would simply reopen
>> the issue.
>>
>> ----- Original Message ----
>> From: Christopher L <[hidden email]>
>> To: [hidden email]
>> Sent: Sunday, December 23, 2007 2:19:01 PM
>> Subject: RE: Proposal of guidelines for the creation of Jira issues
>>
>>
>> IMHO, 30 days is a bit tight. I like to leave my issues open for
>> comment for at least a week or two before I implement them. Then add in
>> delays for miscellaneous stuff and time to implement, and I'm way beyond
>> 30 days.
>>
>> My issues also tend to interest a subset of users and I think my issues
>> would get lost in the traffic on the list.
>>
>> I don't object to periodic cleaning of jira. Jira does perform a
>> valuable service for me, keeping track of my issues so I don't have to go
>> trolling through the list archives. Admittedly, this system will work
>> well for the main contributors, but it will keep lower volume,
>> intermittent contributors, such as myself, out of the system. I don't
>> think
>> that's the intended result.
>>
>> My 2c.
>>
>> Chris
>>
>>> Date: Sun, 23 Dec 2007 05:58:06 -0800
>>> From: [hidden email]
>>> Subject: Re: Proposal of guidelines for the creation of Jira issues
>>> To: [hidden email]
>>>
>>> I realize that many of us are process minded people and so Jira
>> issues that are left open indefinitely tend to irk us a bit. However,
>> Jira
>> can have some benefit as a repository of ideas and not simply as a
>> workflow tool. Discussion in a mailing list tends to be time period
>> driven
>> and not so much issue driven. If you're looking for a guideline to
>> satisfy that process mined mentality, I would suggest that 3) and 4) be
>> replaced with:
>>>
>>> 3') If an issue that is not a bug is left open for 30 days without a
>> patch, it be closed with the resolution of "Later"
>>> 4') If an issue has been in the resolution of "Later" has been
>> without activity for 365 days, change the resolution to "Won't fix"
>>>
>>> or some such
>>>
>>> ----- Original Message ----
>>> From: Jacopo Cappellato <[hidden email]>
>>> To: [hidden email]
>>> Sent: Sunday, December 23, 2007 2:34:04 AM
>>> Subject: Proposal of guidelines for the creation of Jira issues
>>>
>>>
>>> I would like to discuss with you some guidelines for Jira issue
>>> creation.
>>> The idea is to limit the noise in Jira and prevent the creation of
>> Jira
>>>
>>> issues with low informative value that will stay open forever.
>>>
>>> Here are some ideas:
>>>
>>> 1) If you already have a patch for an improvement/fix then create a
>>> Jira
>>> issue (if there is not one already) and attach your patch to it
>>>
>>> 2) If you don't have a patch, and you have discovered a *bug*, create
>> a
>>>
>>> Jira issue (if there is not one already) providing as much details as
>>
>>> possible (including the rev. number and the environment you are
>> using,
>>> and the step to recreate the bug)
>>>
>>> 3) If you don't have a patch, and you have want to suggest an
>>> enhancement or new feature, then discuss this in the dev mailing list
>>
>>> instead of creating a Jira issue; at the end of the discussion, the
>>> community will consider if a summary of the thread should be saved in
>> a
>>>
>>> new Jira issue, to facilitate future development
>>>
>>> 4) If you don't have a patch, but you are planning to work on it, and
>>
>>> you want to share your design details with the community, you should
>>> discuss this in the mailing list instead of creating a Jira issue;
>> if,
>>> on the other hand, you don't have time to do this, you have already
>>> decided that you want to implement your patch following your design
>>> notes, and you just want to let the community know about the upcoming
>>
>>> patch, you can create a Jira issue (to which you will attach your
>> patch
>>>
>>> when it is ready);
>>>
>>> Summarizing:
>>>
>>> * bugs: always create a new Jira issue everytime you find a new bug
>>> * new features/enhancements: create new Jira issue only if you have a
>>
>>> patch (or if you plan to submit it very soon)
>>>
>>> What do you think?
>>>
>>> Jacopo
>>>
>>>
>>>
>>>
>>
>>
>>
>

Jacopo Cappellato

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by David E Jones

I agree with David about the Wiki site being a better tool to prepare
design notes with the community rather than Jira.

About time frames: I'm not against having Jira issues that stay open for
a long time (months, years), and I don't want to put pressure on
contributors (that is why I don't think that setting strict rules, such
as a fixed number of days, is a good idea).

However I think that we should not use the OFBiz Jira as our own diary
for hobby programming (done in the spare time).
Also, if we create an issue (not for a bug) without a patch, then we
should make sure that the issue's content has some informative value in
it (design notes, results of a research, a summary of comments from the
mailing lists etc...): unfortunately there are a lot of issues that are
not interesting, for example:

1) "the screen XY needs to be converted to the widgets": this is not
useful, because we already know that we need to convert (possibly all)
the ftl templates to the widgets... there is no need to create separate
issues for each of them

2) "quotes are only implemented for customers, not for suppliers": this
is not useful, because there are several processes that are still not
implemented (especially if you consider specific industries and
processes) and we don't want to record all of them in Jira

Jacopo

David E Jones wrote:

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

how do you determine this
> However I think that we should not use the OFBiz Jira as our own diary for hobby programming (done in the spare time).

Jacopo Cappellato sent the following on 12/23/2007 9:54 PM:

> I agree with David about the Wiki site being a better tool to prepare
> design notes with the community rather than Jira.
>
> About time frames: I'm not against having Jira issues that stay open for
> a long time (months, years), and I don't want to put pressure on
> contributors (that is why I don't think that setting strict rules, such
> as a fixed number of days, is a good idea).
>
> However I think that we should not use the OFBiz Jira as our own diary
> for hobby programming (done in the spare time).
> Also, if we create an issue (not for a bug) without a patch, then we
> should make sure that the issue's content has some informative value in
> it (design notes, results of a research, a summary of comments from the
> mailing lists etc...): unfortunately there are a lot of issues that are
> not interesting, for example:
>
> 1) "the screen XY needs to be converted to the widgets": this is not
> useful, because we already know that we need to convert (possibly all)
> the ftl templates to the widgets... there is no need to create separate
> issues for each of them
>
> 2) "quotes are only implemented for customers, not for suppliers": this
> is not useful, because there are several processes that are still not
> implemented (especially if you consider specific industries and
> processes) and we don't want to record all of them in Jira
>
> Jacopo
>
>
> David E Jones wrote:
>>
>> Jira might not be the best place for new ideas and desired features
>> that won't be acted on in the near future. I think the point Jacopo is
>> making is that the issue tracker is more about issues, about things
>> that need attention in the near future.
>>
>> After a brief discussion on the mailing list, or even without that, I
>> think a great place to organize thoughts around new enhancements or
>> ideas for things is the wiki section of the Confluence server (OFBIZ
>> space on docs.ofbiz.org). Things are much more flexible there, can be
>> hierarchical more naturally, and can live for a long time as part of
>> research and such by multiple people.
>>
>> Does that strike anyone as a good or bad idea?
>>
>> -David
>>
>>
>> On Dec 23, 2007, at 12:25 PM, Chris Howe wrote:
>>
>>> I'm just tossing out 30 days. But even if it were such a time
>>> period, if there was activity with it after 30 days, you would simply
>>> reopen the issue.
>>>
>>> ----- Original Message ----
>>> From: Christopher L <[hidden email]>
>>> To: [hidden email]
>>> Sent: Sunday, December 23, 2007 2:19:01 PM
>>> Subject: RE: Proposal of guidelines for the creation of Jira issues
>>>
>>>
>>> IMHO, 30 days is a bit tight. I like to leave my issues open for
>>> comment for at least a week or two before I implement them. Then add in
>>> delays for miscellaneous stuff and time to implement, and I'm way beyond
>>> 30 days.
>>>
>>> My issues also tend to interest a subset of users and I think my issues
>>> would get lost in the traffic on the list.
>>>
>>> I don't object to periodic cleaning of jira. Jira does perform a
>>> valuable service for me, keeping track of my issues so I don't have
>>> to go
>>> trolling through the list archives. Admittedly, this system will work
>>> well for the main contributors, but it will keep lower volume,
>>> intermittent contributors, such as myself, out of the system. I
>>> don't think
>>> that's the intended result.
>>>
>>> My 2c.
>>>
>>> Chris
>>>
>>>> Date: Sun, 23 Dec 2007 05:58:06 -0800
>>>> From: [hidden email]
>>>> Subject: Re: Proposal of guidelines for the creation of Jira issues
>>>> To: [hidden email]
>>>>
>>>> I realize that many of us are process minded people and so Jira
>>> issues that are left open indefinitely tend to irk us a bit.
>>> However, Jira
>>> can have some benefit as a repository of ideas and not simply as a
>>> workflow tool. Discussion in a mailing list tends to be time period
>>> driven
>>> and not so much issue driven. If you're looking for a guideline to
>>> satisfy that process mined mentality, I would suggest that 3) and 4) be
>>> replaced with:
>>>>
>>>> 3') If an issue that is not a bug is left open for 30 days without a
>>> patch, it be closed with the resolution of "Later"
>>>> 4') If an issue has been in the resolution of "Later" has been
>>> without activity for 365 days, change the resolution to "Won't fix"
>>>>
>>>> or some such
>>>>
>>>> ----- Original Message ----
>>>> From: Jacopo Cappellato <[hidden email]>
>>>> To: [hidden email]
>>>> Sent: Sunday, December 23, 2007 2:34:04 AM
>>>> Subject: Proposal of guidelines for the creation of Jira issues
>>>>
>>>>
>>>> I would like to discuss with you some guidelines for Jira issue
>>>> creation.
>>>> The idea is to limit the noise in Jira and prevent the creation of
>>> Jira
>>>>
>>>> issues with low informative value that will stay open forever.
>>>>
>>>> Here are some ideas:
>>>>
>>>> 1) If you already have a patch for an improvement/fix then create a
>>>> Jira
>>>> issue (if there is not one already) and attach your patch to it
>>>>
>>>> 2) If you don't have a patch, and you have discovered a *bug*, create
>>> a
>>>>
>>>> Jira issue (if there is not one already) providing as much details as
>>>
>>>> possible (including the rev. number and the environment you are
>>> using,
>>>> and the step to recreate the bug)
>>>>
>>>> 3) If you don't have a patch, and you have want to suggest an
>>>> enhancement or new feature, then discuss this in the dev mailing list
>>>
>>>> instead of creating a Jira issue; at the end of the discussion, the
>>>> community will consider if a summary of the thread should be saved in
>>> a
>>>>
>>>> new Jira issue, to facilitate future development
>>>>
>>>> 4) If you don't have a patch, but you are planning to work on it, and
>>>
>>>> you want to share your design details with the community, you should
>>>> discuss this in the mailing list instead of creating a Jira issue;
>>> if,
>>>> on the other hand, you don't have time to do this, you have already
>>>> decided that you want to implement your patch following your design
>>>> notes, and you just want to let the community know about the upcoming
>>>
>>>> patch, you can create a Jira issue (to which you will attach your
>>> patch
>>>>
>>>> when it is ready);
>>>>
>>>> Summarizing:
>>>>
>>>> * bugs: always create a new Jira issue everytime you find a new bug
>>>> * new features/enhancements: create new Jira issue only if you have a
>>>
>>>> patch (or if you plan to submit it very soon)
>>>>
>>>> What do you think?
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>
>
>
>

Jacopo Cappellato

Re: Proposal of guidelines for the creation of Jira issues

BJ Freeman wrote:
> how do you determine this
>> However I think that we should not use the OFBiz Jira as our own diary for hobby programming (done in the spare time).
>

What do you mean? Sorry, I don't understand.

Jacopo

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

how do you determine that someone is hobby programming.

Jacopo Cappellato sent the following on 12/23/2007 10:40 PM:

> BJ Freeman wrote:
>> how do you determine this
>>> However I think that we should not use the OFBiz Jira as our own
>>> diary for hobby programming (done in the spare time).
>>
>
> What do you mean? Sorry, I don't understand.
>
> Jacopo
>
>
>

Jacopo Cappellato

Re: Proposal of guidelines for the creation of Jira issues

BJ Freeman wrote:
> how do you determine that someone is hobby programming.

Should I do this?

Jacopo

>
> Jacopo Cappellato sent the following on 12/23/2007 10:40 PM:
>> BJ Freeman wrote:
>>> how do you determine this
>>>> However I think that we should not use the OFBiz Jira as our own
>>>> diary for hobby programming (done in the spare time).
>> What do you mean? Sorry, I don't understand.
>>
>> Jacopo
>>
>>
>>

BJ Freeman

Re: Proposal of guidelines for the creation of Jira issues

it was your original statement, I was wondering how this would be
determined. since you stated it, I figured you had a criteria.

Jacopo Cappellato sent the following on 12/24/2007 9:27 AM:

> BJ Freeman wrote:
>> how do you determine that someone is hobby programming.
>
> Should I do this?
>
> Jacopo
>
>>
>> Jacopo Cappellato sent the following on 12/23/2007 10:40 PM:
>>> BJ Freeman wrote:
>>>> how do you determine this
>>>>> However I think that we should not use the OFBiz Jira as our own
>>>>> diary for hobby programming (done in the spare time).
>>> What do you mean? Sorry, I don't understand.
>>>
>>> Jacopo
>>>
>>>
>>>
>
>
>
>

Jacopo Cappellato

Re: Proposal of guidelines for the creation of Jira issues

What I wrote is simply this:

"However I think that we should not use the OFBiz Jira as our own diary
for hobby programming (done in the spare time)."

I don't have any intention or interest to determine this; and of course
it is completely fine to consider OFBiz as an hobby (it is actually one
of my hobbies, and also my profession).

Jacopo

BJ Freeman wrote:

> it was your original statement, I was wondering how this would be
> determined. since you stated it, I figured you had a criteria.
>
> Jacopo Cappellato sent the following on 12/24/2007 9:27 AM:
>> BJ Freeman wrote:
>>> how do you determine that someone is hobby programming.
>> Should I do this?
>>
>> Jacopo
>>
>>> Jacopo Cappellato sent the following on 12/23/2007 10:40 PM:
>>>> BJ Freeman wrote:
>>>>> how do you determine this
>>>>>> However I think that we should not use the OFBiz Jira as our own
>>>>>> diary for hobby programming (done in the spare time).
>>>> What do you mean? Sorry, I don't understand.
>>>>
>>>> Jacopo
>>>>
>>>>
>>>>
>>
>>
>>

Bilgin Ibryam

Re: Proposal of guidelines for the creation of Jira issues

In reply to this post by Jacopo Cappellato

+1

Bilgin