OLE Contribution Information

OLE Contribution Requirements

Contribution Checklist

Proposal

1. Provide functional requirements (template) and acceptance criteria so others know how the contribution is supposed to work.

2. Note the expected delivery date for the functionality on the JIRA ticket
   

3. What technologies are being used (KIM, KNS, KRAD, other libraries, and why?).  See "Additional Resources for Contributions" below
   
4. What access would we have to the contributor for questions? - Add to note section

Contribution

1. The contributor must be available for the code review process

2. Include documented architecture

3. Provide unit tests.  Note any gaps in testing.

4. Include documentation as needed.

5. Include any known issues, gaps, bugs, etc.
6. If the code is not included in the base code, include in the JIRA notes the appropriate OLE release number

OLE Contribution Process for Enhancements and Functional Bugs

1) Contribution Proposal

The first step in contributing to OLE is to create an issue in JIRA per the following guidelines.  

If a JIRA already exists, update the JIRA ticket fields:

• Contribution
• Contributing Developer 
• Contributing Institution 

If a JIRA does not exist:

• Create the JIRA ticket in OLEFDBK
• Be sure to include information in these fields:
  • Contribution
  • Contributing Developer 
  • Contributing Institution
    

Attach all requirements or design documents to the JIRA.  A template is available, if needed.

Review planned 3rd party licenses to ensure compatibility with ECLv2 

All contribution proposals are reviewed by the QA Manager.  If approved, the OLEFDBK ticket is moved to OLE.  The status of the ticket becomes FSPEC DEV and handed off to the Implementation Team for functional review. 

2) Functional Review

The contribution development may be an iterative process with Implementation Team.

Implementation Team determines if the contribution should be part of the base code or a local option

 Considerations for making the decision:

• •  Implementors must understand the intended contribution (probably through a functional specification)
  • Approved by the Implementation team to go into the base code.
    
    • functional spec may be less formal for a bug versus an enhancement but there needs to be clear statements that SMEs and the contributor understand what the current problem is and what the fix is going to do, how it is going to look and work.

Implementation Team updates the JIRA:

• Update Contribution Type field - Local Option or Base Code
  
•  Moves JIRA to Coding status in the workflow 
• Assigns JIRA to the Contributor 

 3) Contributor Codes

If Local Option

If the contribution is determined to be a local option, contributor closes the JIRA when coding is complete.  Include access to the code, documentation and instructions in the JIRA notes.

Considerations:

1. Nice to include Acceptance Criteria and test cases.

2. Nice to meet functional standards (UI standards for example)

3. Nice to meet Technical Standards (coding design/conventions)

1. could include unit tests and show that it does not fail existing unit tests

2. could include documentation of database changes

3. could include User Documentation

If Base Code

If the contribution is determined to be part of the base code, contributor moves the JIRA to Dev Complete and issues GitHub pull request.  The ticket is then assigned to the Development Manger for the technical review.

Note - Any time you pull code to the OLE project, you must specify the *associated JIRA key (e.g. OLE-XXXX)* for the corresponding work

 4) Technical Review

 Once code is complete, the Development Manager will coordinate a code review.  There could be some changes recommended during the review steps before the contribution can be accepted (JIRA status will return to Coding). Any objections that come up during the review process must be resolved.

Considerations

1. Does it meet licensing requirements

1. Currently all code licenses must be compatible with ECL2

2. Personal and/or institutional CLA on file

2. Does it meet Technical Standards, e.g. coding design/conventions

1. Does it pass a code review

2. Does it include unit tests and show that it does not fail existing unit tests

3. Does it include documentation of database changes and an upgrade path to make those changes.

4. Must pass regression tests

3. Does it create any security risks

The Development Manager will honor the pull request (merges into base code) and moves the JIRA to QA Review

5) QA Review

The QA Manager will oversee the review.  If it fails at any time, the JIRA is returned to the contributor for corrections (Coding status).

Considerations

1. Does it include Acceptance Criteria and test cases based on that Acceptance Criteria

2. Does it pass Acceptance Testing

3. Does it meet functional standards, e.g. UI standards

The QA Manager moves the JIRA to Documentation Review upon completion.

6) Documentation Review 

Documentation Lead will conduct a review of the documentation to ensure documentation is complete.  For documentation types and instructions, see Documentation Standards and Best Practices.  Once satisfied, documentation is incorporated into the core documentation code by the Documentation Lead.

Considerations

1. Is user Documentation complete - could be joint product of contributor and SME

The JIRA remains in the status Documentation Review until all pieces are complete.  Then the ticket is closed.

Technical Bug Fixes

1. The Contributor creates an OLEFDBK JIRA AND a GitHub pull request

1. Contributor adds pull request URL to the JIRA

2. Be sure to include information in these fields:
   • Contribution
   • Contributing Developer 
   • Contributing Institution

2. The QA Manager will verify CLA or CCLA on file

3. Then, QA Manager moves the OLEFDBK JIRA to OLE and assigns ticket to Development Manager
   

4. The Development Manager determines if it’s actually a technical bug or has functional implications

1. If there are functional implications, the contribution needs to follow above contribution process

5. Development Manager determines if the contribution goes into the base code or should remain local

1. Development Manager may bring issue to SII group (and/or others) for input

6. Development Manager does a code review

7. Development Manager merges code

8. JIRA is assigned to contributor for testing/confirmation

9. If fixed, Contributor closed JIRA

Additional Resources for Contributions

• Review the License Agreement Process. 

• Follow the 3rd Party Evaluation Process if you are considering using 3rd party code in work for the Kuali OLE.

• Refer to the Kuali Application Security Working Group for security training and recommendations

Refer to the Kuali Rice Policies and Standards including the Kuali Rice Development Standards for code coherence tips.

 Other Ways to Contribute

Code contributions are not the only things we might seek from project members or outside organizations.  Documentation and testing should also be accepted.