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.
Members of the community propose new feature or discover defects
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.
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