Difference between revisions of "User:Drew Dwi/JIRA improvements"

From Second Life Wiki
Jump to navigation Jump to search
(jira thoughts/scratch pad)
 
Line 17: Line 17:
# require some sort of validation, SVC must have Second Life Server in the contents, VWR-must have "Second Life Viewer" somewhere in text box.
# require some sort of validation, SVC must have Second Life Server in the contents, VWR-must have "Second Life Viewer" somewhere in text box.


=== Mass NMI after each stable release ===
=== Handling of report-status after each stable release ===


# After each stable release, all issues affecting the previous version and not marked as affecting the newest version should be marked NMI and request the user download the newest viewer and test their issue again.
# If a report has a solid repro (or is commonly known to exist), the affected versions should be updated automatically.
# If not:


# Issues which are older than 2-3 full releases and have not had any activity should be closed.
## Reports should be marked NMI, with a clear comment, including the new version to test.
## 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 ===
=== Priority ===

Revision as of 18:29, 30 April 2010

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. 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

  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 isnt'

Solutions

  1. Priorities should be set when an issue is imported.


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.

Solutions

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?