Versions Compared

Key

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

...

...

Issue Type

Definition for Sakai

Bug

An error in design or implementation which directly impedes a user from achieving their expected result.

Task

A new capability being added to Sakai.

Feature Request/Requirement

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="47a8d5cb0d74a6fd-6be35827-4b4043db-984497f7-f5050d5c6c363423c99d7f47"><ac:plain-text-body><![CDATA[

Contributed Patch

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 original issue in order to track Sakai's work on the issue. [Use at your own risk!]

]]></ac:plain-text-body></ac:structured-macro>

Branch

An experimental branch of code, which may or may not be merged back into the main code after the experiment completes; identified in SVN by a branch named with the Jira Key.

...

The Sakai community is encouraged to report issues and post feature requests in Jira, 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.

  1. User posts creates an issue in Jira.
    • The Affects Version should be set to the released version on which the their local instance of Sakai is based.
    • The Target Versions and Fix Version should be initially remain left set to the default of Unknown. The project teams , when will set the Target Version once they have a chance to evaluate your issue, will set this to reflect an estimate of had time to review the issue and estimate 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
  • Small requests (e.g., 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 contributions across tools a student has made in a site) for new or modified functionality. The simple requests are handed off directly to project teams for evaluation as to whether or not to implement. The more complex requests enter the Requirements workflow, as outlined below.
    • Requirements are vetted to ensure that they are clearly stated and supported by examples and use cases. Suggestions on implementation strategies are separated out from the description of the requirement in order to re-enforce the need identified 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 implementation of requirements that were important to them by providing resources (programmers, designers, QA, etc.).

...

    • it. The Fix Version will be set to the version or versions of Sakai in which the fix for the issue has been merged in to the source code.

Anchor
Developer
Developer
Developer

Planning

  1. As new issues come in and as you periodically review the status of existing issues, use the Target Version to indicate for what version you expect to implement a solution for the issue.
    • Notes on future versions:
      • Leave the Target Version as Unknown if you are not sure what version the issue will be addressed for.
      • Wiki Markup
        Set the Target Version to the *general release version* (_e.g._, "2.4.0 \[Tentative\]") to indicate an issue will be addressed for that release.

...

  1. Assign the issue to yourself to work on.
  2. 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 Target Version to reflect for which version you expect to complete your work.
  3. Work on the issue, updating, modifying, commenting, re-assigning, etc. as necessary to achieve resolution.
  4. When work is complete, and if the resolution of the issue is Fixed, then Resolve the issue and set the Fix Version to Nightly/SVN-Trunk. If the resolution is other than Fixed (e.g., Duplicate, Non-Issue, Cannot Reproduce), then set the Target and Fix Version to Unknown.
    • For Tasks, if there is nothing explicit for the QA team to test, then please Close the issue.
    • 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 the original issue was not resolved.

Maintenance Branches

See Maintenance Branch Guidelines.

Security Releases

To be filled in...

Maintenance Branches

See Maintenance Branch Guidelines.

Feature Branches

Include Page
REL:Feature Branches
REL:Feature Branches

Experimental Branches

Include Page
REL:Experimental Branches
REL:Experimental Branches

Anchor
Quality Assurance
Quality Assurance
Quality Assurance (QA)

...