Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  1. User searches JIRA to see if the issue already exists (Sakai Jira Search)
    • Search strategies include searching for a particular component, sorting by update date, and exporting as an MS Excel file (in Views)
  2. User searches the sakai mailing lists archives (nabble sakai lists archives)
  3. If user is not sure if the problem is a bug, they send a note to the sakai-dev mailing list first to ask
  4. User creates an issue in Jira of the appropriate #Issue Type
    • The component should be set based on where the problem appears to exist. Do not use the Performance component however. Use a 'Performance' label to flag performance related issues so there is a consistent way to filter these issues across projects.
    • The Assignee should be left as -Automatic-
    • The Affects Version should be set to the released version of the instance of Sakai being used.
    • The Fix Version should be left set to the default of Unknown. The project teams will set the Fix Version once they have had time to review the issue and estimate when they believe they will be able to address it.
    • As much of the following information should be included as possible (to avoid the issue being closed as incomplete)
      • Sakai version
      • (bugs) Steps to reproduce (detailed and step by step)
      • Environment details (DB type and version, tomcat version, OS type and version, Browser and version, etc.)
      • (bugs) URL to the page where the error occurs
      • (bugs) Stacktrace (traceback) if available
      • (bugs) relevant portions of the server logs (do not attach your entire logs, we do not have time to read through 1000s of lines of logs and figure out where the relevant parts are)
      • (bugs) Screenshots showing the error
      • (feature) Use cases and detailed requirements
      • The desired resolution

...