Laura Stewart wrote: > The advantage to having "DOCS" or "Documentation" in the title is that > the issues are easier to track when email comments are received. The > component "documentation" is fine when you are in Jira, but does not > appear in the title of a comment to a Jira issue in email....
The summary for the jira issues get reflected in the release notes and potentially in other places, I don't want to see those cluttered with different prefixes when a component is the correct mechanism. With this precedence we could reach a situation where the subject line is something like, leaving no visibility for the actual content in an e-mail client window: [jira] Created: (DERBY-2032) DOCS IMPROVEMENT 10.2 Minor Urgent ... > which is > where I first encounter new issues. During this part of a release > cycle, I don't go to the Jira docs issues list, but work primiarliy > off of the email comments so that I can respond to the comments more > quickly. The use of Jira has to be for the whole community, not tailored towards an individual's requirements. We also have to remember that this is an open project and our bug summaries may escape far & wide. As an example changing the summary of a bug to totally change its meaning is a bad idea. E.g. DERBY-4332 insert statements don't work with 7 columns to DERBY-4332 test updateXXX.java has incorrect logic in sub-case testBinaryColumns Between the change some one shipping Derby may have included the text for DERBY-4332 in their release notes, leading to confusion when their customer looks up DERBY-4332 in the ASF Jira system. Dan. > On 8/16/06, Daniel John Debrunner <[EMAIL PROTECTED]> wrote: > >> Laura Stewart wrote: >> >> > Longer comments should not be entered into the table. Instead a Jira >> > issue should be created with DOCS as the first word in the title, >> >> There is already have a mechanism to indicate the Jira entry is for >> documentation: Component of "documentation". Let's not invent a new >> scheme.
