JIRA Reform

For years, there has been an expressed desire for a overall review of JIRA workflow.  Prior to beginning

Requests 

1.  Mechanism to track i18n and L10n issues (ie checkbox). Having i18n as component makes live filters unusable when you're trying to find i18n issues related to a real component. We can keep the i18n component for the i18n utility classes and related configuration. Issues related to a component following Internationalization in alphabetical order are assigned to the i18n lead instead of being assigned to the proper tool lead. Indie projects have are defined as projects in JIRA do not have an i18n component so we cannot distinguish i18n issues in indie projects. These issues need to be distinguished because it will help us deal with questions such as:
   1. Are there translations updates in the latest release (L10n)?
   2. Are there i18n fixes in the latest release?  without having to check each i18n component issue with latest issue in Fix Version/s.
   3. Why are tool leads not assigned i18n issues in their tools?
   4. How do we distinguish i18n issues in indie projects, kernel included?
2. Extra Jira component for marketing:   I noticed that the Sakai 2 and Sakai 3 are very similar in terms of their descriptions in the running demo.  I just want to Jira that so that if we have some product differentiation and people can track. I am sure to come across more of this similar sort of market positioning stuff during the testing process. Is it OK to have a Jira component for marketing? It seems the most transparent way to communicate and track. I have already mentioned this on the Sakai 3 side to Alan Mark's.
3. Real Priority Field - as opposed to the current priority which is really severity
4. Separate fields for Fix Version and Target Version.  Depending upon the status (Open, Resolved, Closed), the fix version can mean different things.   It's hard to track intent and even harder to see what is included as JIRA's transition between the different statuses.