|
|
+1
I'm agree with you.
Marco
------
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
|
Locked
