...
- You can search and view content in Jira without an account, but are required to have one to comment or create issues. Jira accounts are available through self-registration (Jira and Confluence share accounts)
- Sakai uses the Atlassian JIRA to track bugs, propose features and track progress on releases. The Sakai Project Jira and Confluence both use your Atlassian Cloud login. You will need to login to Atlassian Cloud and then request access to Sakai Jira and/or Confluence. Existing Sakai Project users may also send you an invite to one or both products. You may need to request an upgrade to your permissions to use other features of Jira. Please email sakaicoordinator@apereo.org to get your account upgraded.
- People who want to submit issues, after creating their account, should review the Workflow.
- If you have questions regarding this tracking software (Jira), please send them to jira-admins@collab.sakaiproject.org.
- For Developers: Maintenance Branch Guidelines | Feature Branches | Jira Branches
- Sakai Community Servers are accessed from here (you'll test on them before creating a community Jira: http://nightly2.sakaiproject.org/ ).
...
- Anyone with a JIRA account creates an Issue (please see #Create Issue Detailed Instructions first)
- Issue is automatically assigned to a Awaiting Review status
- A Sakai Core team member, and/or anyone who wants to participate in "JIRA Triage" weekly calls, verifies the issue for accuracy (i.e. is it an actual issue) and completeness of details.
- Complete and valid issues are set to status Open and assigned to a user or group (e.g. Samigo Team or Sakai Core Team) who can resolve it.
- The team member may resolve the issue as Duplicate , Incomplete , or Cannot Reproduce if appropriate (see #Resolution).
- It may also be set to Awaiting Information if it doesn't contain enough information to Open for work.
- Once Open, developers ideally pick up the work and assign themselves to it as "Assignee." When they begin work, they selects Start Progress and begin to work on the issue (as time and priorities allow)
- The Assignee selects Stop Progress if they are not going to work on the issue anymore for a few days and it is not resolved
- The Assignee sets the issue to Resolved with the relevant #Resolution when work is completed
- For tasks, if there is nothing explicit for the QA team to test, then the issue is Closed without testing.
- The QA team (potentially you!) selects Start QA and begins verifying the issue
- QA team member selects Stop QA if they are not going to complete the testing on the issue within a short time frame
- The QA team verifies resolution of the issue and adds a comment with details of the testing results and process.
- If verification fails, then it is Reopened for further work (automatically re-assigned to the user who resolved it)
- If verification succeeds then QA marks the status as Verified (indicating it has been Tested)
- The Release Manager merges the issue (if it is a bug) to previous supported and affected releases
- The associated version merge status is set to Resolved (see #MergeStatus )
- The issue is Closed by the Release Manager when the last merge has been completed
...
- You search 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)
- You might also check the sakai mailing lists archives.
- Searching sakai-dev archives may help if you get too many results
- If you're not sure if the problem is a bug, then send a note to the sakai-dev mailing list first to ask
- You then create 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. Only 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)
- If disambiguation is necessary, include Expected Results and Actual Results
- 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 or Screencasts showing the error
- (feature) Use cases and detailed requirements
- The desired resolution
...
- (Awaiting Review)
- Contributed patches should receive priority treatment.
- The issue should be linked to other related issues.
- Check the is assigned to a user or group (e.g. Samigo Team or Sakai Core Team) who can resolve it.
- Adjust the Priority depending on overall project and release goals
- Other attributes should be changed as needed, ( Components , Affects Version , Security Level , Original Estimate , etc.)
- (Open)
- Open tickets should be worked on within 90 days or assigned back to Unassigned
- Open tickets which have seen no activity in 180 days will be moved back to Awaiting Review status
- (Resolved) - General
- Resolved tickets which have had no activity in 180 days will be Closed without testing
- Details in #Resolution
- (Tested) QA is complete on this ticket.
- (Closed) No other activity should or will happen on this ticket
...