Definition for Sakai
An error in design or implementation which directly impedes a user from achieving their expected result.
A new capability being added to Sakai.
A desired capability, for inclusion in a future release of Sakai; ideas that come with resources interested in implementing them are more likely to be developed than those offered with the hope that someone else will step forward to do the work.
<ac:structured-macro ac:name="unmigrated-wiki-markup" ac:schema-version="1" ac:macro-id="bb784981a28f1871-376b2a65-477d4ec8-bc82b661-eb4bd5bace4d70eb35404f3d"><ac:plain-text-body><![CDATA[
A community-contributed patch to a particular version of sakai. The origin of such issues may lie in Bugs or Feature Requests which Sakai has not yet evaluated for implementation. Under such circumstances a linked issue is generally created by cloning the orignal issue in order to track Sakai's work on the issue. [Use at your own risk!]
- Issue is vetted for accuracy and completeness of information.
- The issue is evaluated by the appropriate project team, just like a Feature Request or Requirement, for inclusion in a future release of Sakai.
- In some cases, a Contributed Patch may run counter to the Sakai design and cannot be incoporated, and maybe marked as Won't Fix and an explanation as to why provided. In this case, the contributor of the Patch may choose to continue developing the patch for future versions of Sakai.
- Until the patch is integrated in Sakai, the community encourages the contributor to be responsive to comments and feedback provided by other users of the patch and to continue to update the patch to current versions of Sakai.
General Workflow by Task
The Sakai community is encouraged to report issues, however, it should not consider posting issues in Jira as a primary destination for users of their own instance of Sakai to report issues. Rather, each organization running Sakai is expected to provide its own front-line support, which can post issues to Sakai's Jira on behalf of users, when the issue is deemed to affect Sakai and not just the local installation of Sakai.
- User posts an issue in Jira.
- The Affects Version should be set to the released version on which the instance of Sakai is based. For instance, if one is running a Maintenance Branch of Sakai (e.g., 2.3.x), then it should be the most recent release version (e.g., 2.3.1). Otherwise, things can get a bit confusing as the branches are moving targets, and generally any issue affecting a branch will also be an issue for the last release on that branch.
- The Fix Version should be initially set to Unknown. The project teams, when they have a chance to evaluate your issue, will set this to reflect an estimate of when they believe they will be able to address the issue.
The workflow for the requirements process is being further developed in the Sakai Working Group: Requirements Process. The general steps are:
- User posts a Feature Request or a Contributed Patch
- Simple Small requests (e.g., reword correct the grammar of this sentence, turn this red) are separated from major requests (e.g., reconfigure the interface for Resources to eliminate all the links next to each file, add a way to view all the contirbutions across tools a student has made in a site) for new or modified functionality. The small simple requests are handed off directly to project teams for consideration, where as the evaulation as to whether or not to implment. The more complex requests enter the Requirments workflow, as outlined below.
- Requirments are vetted to ensure that they are clearly stated and supported by examples and use cases. Suggestions on implementation strategies are separaeted out from the description of the requirement in order to re-inforce the need identifed in the requirement. This process may require discussion, via
- comments in Jira, with the original issue Reporter
- , members of appropriate project teams and associated working groups.
- Once a year, requirements are
- posted for a community ranking poll.
- The opinions expressed in that poll are
- shared with the community and with the project teams. The project teams are encouraged to take them into consideration when planning their work for subsequent releases
- . The community is encouraged to volunteer to help out
- with implemention of requirements that
- were important
- to them by providing resources (programmers, designers, QA,
- As new issues come in and as you periodically review the status of existing issues, use the Fix Version to indicate for what version you expect to implement a solution for the issue.
- Notes on future versions:
- Leave the Fix Version as Unknown if you are not sure what version the issue will be addressed for.
- Set the Fix Version to the first QA general release version (e.g., "2.2.1.0014.0 Tentative") to indicate an issue will be addressed for that release.
- Notes on future versions:
Addressing an Issue
- Assign a Bug or Task to yourself to work onthe issue to yourself to work on.
- If you are implementing a Feature Request, Requirement, or Contributed Patch, first use Move to covert the issue type to a Task and set the Fix Version to reflect for which version you expect to complete your work.
- Work on the issue, updating, modifying, commenting, re-asssigning, etc. as necessary to achieve resolution.
- When work is complete, and if the resolution of the issue is Fixed, then Resolve the issue as Fixed (or other appropriate resolution) and set the Fix Version to " Nightly/SVN-Trunk" (or to "Unknown", if you did not fix it.). If the resoultion is other than Fixed (e.g., Duplicate, Non-Issue, Cannot Reproduce), then set the Fix Version to Unknown.
- For Tasks, if there is nothing explicit for the QA team to test, then please Close the issue. Otherwise, for (For Bugs, just leave the issue as Resolved, and the QA team will Close it after verifying it, ( or Reopen it for further development , if they discover problemsif the original issue was not resolved.)