User:Drew Dwi/JIRA improvements

Second Life Grid Status

1. Any open secondlife grid status issues should show up as announcements on the JIRA front page to prevent the mass-filing of duplicate issues which are known about.

1. Show a list of open grid status issues after one selects bug for SVC- and have the user confirm they are not being affected by anything listed before proceeding to the next page.

Improve Component Descriptions

1. Currently components give no details when you hover over them. Tool tips are(should) able to be added to help clarify what exactly each component means.

Require the environment field for SVC- and VWR-

1. at least require it to be not empty
2. increase the size, on the create issue page it is 2 lines long and often ignored.
3. require some sort of validation, SVC must have Second Life Server in the contents, VWR-must have "Second Life Viewer" somewhere in text box.

Handling of report-status after each stable release

1. If a report has a solid repro (or is commonly known to exist), the affected versions should be updated automatically.
2. If not:

1. 1. Reports should be marked NMI, with a clear comment, including the new version to test.
   2. Issues which are older than 2-3 full releases and have not had any activity should be triaged, so they can be closed if necessary.

Priority & Status

1. Priorities are often misleading
   1. They rarely reflect the internal priority
   2. They are often the source of edit wars
   3. They often give false hope that an issue is a priority when it isn't

1. Usage of the word "Resolved". Insiders know what this means. For the unsuspecting bug-reporter it's a constant source of hostility.

Solutions

1. Priorities should be set when an issue is imported.
2. For any issue which requires more feedback, mostly NMI/Cannot Reproduce - Set status to Pending instead of Resolved.

Life after Imported or In Progress

1. see WEB-491 for initial opinion in 2008
2. JIRA's especially the VWR- branch are rarely updated after imported or set in progress
3. JIRA's are even less often set to the Linden who is assigned to work on them.
4. JIRA's are not updated when work is started, or work is completed.
5. JIRA's are not updated when the issue enters or exits internal QA
6. JIRA's are more likely to be updated when a fix is released as a beta, but not always.

The gap between Pjira and internal jira

The Pjira has a high noise-level by definition. Filtering that noise is essential for a good understanding of the issues, but it is time-consuming, and needs expert eyes. Often reports are triaged without taking enough time to go trough all the comments, at the cost of the quality of the internal jira. Devs tend to work only from the internal jira. Residents have no knowledge of what's in the internal jira. Communication between devs and residents on the jira is virtually non-existent, with some exceptions on the server-side. The lack of a closed feedback-loop often obstructs the workflow.

Solutions

1. Some issues are not suitable for in-world triages. Move them to a forum-style triage, so more people have more time to have a good look at it.
2. Each imported Pjira should have a section on top, where a Dev explains LL's current understanding and status of the issue. This in itself will reduce the noise on the Pjira (fewer but better-informed comments). And residents will be able to point out mistakes in the system. Remember, we all make mistakes.
3. Each imported jira should be assigned, so valuable information won't disappear into a void.

JIRA is too often used as a non-technical tool

1. Rants and Raves are not moderated and send to the forums for proper discussion
   1. (assumtion) Linden's rather spend time fixing problems then arguing with residents in a non-objective manner
   2. (assumtion) Due to the large amounts of non-objective comments, finding important details is often a time consuming process

Solutions

1. Link Imported issues to a thread on the forums for discussion?

Search

Finding a duplicate can be hard even for an experienced jira-user. For first time users it's even harder. It not only involves using the search tools, but also interpreting reports written by many different people.

Solutions

1. A short explanation by a dev on top of the page would help.

Feature requests

There are many feature requests, in many forms. Some are far out, and impossible to implement. Others are sensible and useful. Feature requests in general get little or no attention from devs.

Solutions

1. Have a triage for feature requests. There's even a request for this on the jira: https://jira.secondlife.com/browse/MISC-2906. It illustrates the nature of the problem: A breakdown of communication.
2. Have devs take some time to brainstorm on the jira, if a feature request has merit. Good ideas may come from it.