Skip to end of metadata
Go to start of metadata

Description

Contributions committed to trunk are supported and maintained by the Kuali Student Project Team. These contributions are considered "core" contributions. A contribution that is not committed to trunk and lives outside of KS, the Contributor owns support and maintenance. These type of contributions are considered "non-core" contributions.

Process

Gliffy Zoom Zoom KS Contribution Support Process

Process Steps

Process

Description

0. Discover

Members of the community propose new feature or discover defects

1. Log

Members of the community log new feature / defects in JIRA (using Project: Select KS QA Tracker (KSLAB)). To log a JIRA, members must have a Kuali Information System Account. Members must adhere to the KS Defect Information Standard when filling out the JIRA ticket. https://wiki.kuali.org/display/STUDENT/Defect+Information+Standard.
Is it possible that the community member submits a patch at the same time they submit the Jira ticket (shown in red).

2. Triage

The KS Project Team leads the discussion and makes recommendations on what to accept / fix for a patch release. The purpose of the Triage Process is to prioritize what features are accepted / what defects need to be fixed and provide guidance on release. The Triage Process is described here: https://wiki.kuali.org/display/STUDENT/KS+Triage+Process

3. Core or Non-Core Asset?

The type of asset, Core or Non-Core, determines who works on the jira and may influence to some degree the timing.

4. Contributor Development

The Contributor will fix defects found in non-core assets that he or she contributed. When they get fixed is up to the contributor.

5. KS Project Team Development

The KS Project team will either 1) build new feature / fix defects found in core code based on the decision from the triage process when the KS staffing level allow, or 2) will coordinate with the Contributor to accept the patch containing the new feature / fix and start the QA process (see below).

6. Perform Quality Check

All contributions for core assets are checked for quality at different stages of the development process including compilation, build, JUnit, deployment, smoke, functional and regression testing. Performance testing is done on an as needed basis. We recommend that non-core assets adhere to similar quality rigor.

7. Release Patch

KS Project team determines the rhythm and scope for patch releases. To release, the code must achieve a basic level of quality listed in the Release Checklist: https://wiki.kuali.org/display/STUDENT/Release+Criteria+Checklist

1 Comment

  1. Sean Phillips, the same KS Defect Information Standard is linked here as well.