Please do not report security vulnerabilities or proposed contributions to fix them in JIRA. See: Financials Documentation Home for how to report security vulnerabilities.
Submitting & Following Up on Proposals
If you want a contribution to be added to baseline (aka delivered, vanilla) KFS, move the appropriate JIRA from the KFS Request queue or create a new JIRA in the KFS Contribution Proposal queue if no KFS Request exists. For issues with an active contribution (ex: failing PreCommitTestSuite, missing datasets, etc.), comment on and commit against original KFS Contribution Development JIRA. If you are going to contribute a bug fix for a closed contribution move the appropriate JIRA from the KFS Request queue or create a new JIRA in the KFS Contribution Proposal queue if no KFS Request exists. If you want this contribution to be made available to others and don’t plan for it to go into baseline, or you are not sure, create a JIRA in the Kuali Sharing queue.
The Partner Contribution Contract
When you propose a contribution, you are agreeing to be responsible for that contribution until it is completed. This is particularly important to understand for enhancement contributions.
- Your functional staff must be available to write the functional specification, review with the Customer Advisory Group (CAG), and revise the specification as needed.
- Your technical staff must be available to write the technical specification, review with the project team and revise as needed.
- Your technical staff must be available to participate in agile meetings, code the contribution, provide all required technical deliverables, participate in code review(s), and revise as needed.
- Your functional staff must be available to participate in agile meetings, provide all required functional deliverables and assist with product team testing.
- Your technical staff must be available to resolve issues found in testing.
The process and deliverables are outlined in further detail below. Your CAG Representative and technical liaison are accountable to the CAG and product team for ensuring quality, remaining on schedule, and upholding this contract. The most unfortunate breach of contract that might occur without adequate planning is for coding to be completed, an issue to be found in testing, and there to be no resources available to resolve the issue. This is a waste of partner, community, and product team time: spending time on reviews, coding, and testing and then spending additional time rolling back the change, leaving the community lacking the improvement and the partner maintaining a customization.
Index
Recommendations
Partner institutions are encouraged to create KFS Contribution Proposal issues as soon as they encounter a bug or think of an enhancement that they would like to contribute. Before creating the contribution proposal, confirm that the bug still exists or the enhancement does not exist in the Foundation environments. Partner institutions are advised to contribute early and often (ideally when initially doing the work) to minimize re-work and intermediary customization upgrades.
See Development Recommendations
- Here is some documentation on how IU leverages the recommended process: IU Development Process
- Here is some documentation on Cornell’s Maven-based alternative to the delivered Ant process: Cornell Development, Cornell War Generation
Roles
Product Team
Product Manager - Work with CAG as needed to solicit input on contribution proposals. Approve scheduling of contributions.
Functional Leads - Review all functional specifications, notify the product manager when CAG input is required, provide functional approval for contributions, perform testing and integrate updates to user documentation.
Technical Leads - Provide technical support, feedback, and approval, for contributions. This includes reviewing technical specifications, managing pull requests and organizing code reviews.
Partner
See Sustainability Model Partner Roles and Partner Liaisons List
Classification
If a feature is not working as intended and agreed upon in documented requirements (functional specifications, technical specifications, user documentation, email, JIRA, meeting minutes, etc.), it is a bug. The following are clear examples of bugs: server errors, misspellings, messages at the bottom of the page, bad GL entries, bad encumbrances, inconsistencies with label names, missing lookup icons, batch reporting success when it failed, and case sensitivity issues.
Anything that is not a bug, performance improvement or code extensibility improvement is an enhancement.
Workflow - KFS Contribution Proposal
Creation of Contribution Proposal (Partner)
If there is an existing KFS Request that you want to contribute, move it to the KFS Contribution Proposal queue and provide the additional information requested; otherwise create a KFS Contribution Proposal issue from scratch.
Technical Liaison can also be the functional sponsor for contributions with no functional impact.
Functional specifications
May be as simple as a paragraph describing a bug or a formal enhancement specification.
Specifications should be updated if changes are made to the design during development.
- When formal specification documentation is requested, use the provided template: Enhancement Functional Specification Template
Technical specifications
- In certain cases (e.g. bold PO number on PO PDF) a couple of sentences in the JIRA description will suffice. But, usually a formal specification is required for enhancements.
- For certain complex performance improvements, a technical specification may be required.
- The Technical Specification should contain enough information to explain the extent of the proposed changes including impacts to existing code
- If changes are made to critical business logic (i.e Scrubbers, Posters, Year End Jobs, System module), please provide more detail on those changes.
- The Technical Specification is not a replacement for a Code Review and is not intended to be an implementation guide.
- Specifications should be updated if changes are made to the design during development.
- When formal specification documentation is requested, use the provided template: Enhancement Technical Specification Template
Open with fix version set to TBD (Partner)
Contributions that are not ready to be reviewed. When Partners are ready for a contribution to be reviewed, they should set the fix version to NOW.
Open with fix version set to NOW (Product Team)
Daily review of KFS Contribution Proposals that are ready to be reviewed.
- If more information is needed, move to Functional Roadblock or Technical Roadblock.
- If CAG input is needed, move to Customer Review.
- If no further information or review is needed, ready to Proposal Accepted.
Functional Roadblock (Partner)
Provide functional specifications or respond to questions. Once completed, select "Functional Roadblock Eliminated".
Technical Roadblock (Partner)
Provide technical specifications or respond to questions. Once completed, select "Technical Roadblock Eliminated".
Functional Review (Product Team)
Review functional specifications or responses to questions.
- If additional information required, move to Functional Roadblock.
- If CAG input is needed, move to Customer Review.
- If requires further review by product team, bring up in daily meeting.
- If no further information required, move to Technical Review.
Customer Review (All)
Product Manager works with CAG to review contributions.
- If the specification requires updates, the product manager will move to Functional Roadblock.
- If no further information required, the product manager will move to Technical Review.
Technical Review (Product Team)
Review technical specifications or responses to questions.
- If additional information required, move to Technical Roadblock.
- If requires further review by product team, bring up in daily meeting
- If no further information required, move to Proposal Accepted.
Proposal Accepted (Product Team)
Proposal is ready to transition contribution to KFS Contribution Development.
Transition Proposal to Development
Contribution is too big for one story
Agile requires that stories (Enhancements, Bugs, Code Extensibility, Performance Improvements) take no more than one to two days for the team to complete, i.e. develop, test, and document. This facilitates more accurate planning and reduces risk of not delivering working code at the end of a sprint. If the contribution proposal JIRA is too large to be completed in one to two days, the product team will transition it to an Epic issue type and work with Partners to create stories associated with that Epic to break down the work.
Contribution is properly sized
Move directly into KFS Contribution Development (no Epic needed).
Workflow - KFS Contribution Development (stories)
Stories (Enhancements, Bugs, Code Extensibility, Performance Improvements) represent deliverable functionality. Each story will be broken down into sub-tasks to represent individual tasks required to complete the story (i.e. coding, testing, documentation). The following describes how partners work with the product team to schedule contribution stories for upcoming sprints.
Open with empty Sprint (Partner)
Accepted contributions waiting to be scheduled. Partner should confirm that the JIRA has the information ready to proceed and then set Sprint to "Next Sprint" when ready to schedule contribution for an upcoming sprint.
In addition to the fields required on the jira, the following fields must be populated by partners before project team will review and schedule contributions:
- Acceptance Criteria
- Impacting Fields (API changes?, Data Structures, KFS Data, Rice Data, Rice Change Required?, Configuration Properties, Libraries)
- Development Hours (cannot be set to zero)
Open with Sprint set to "Next Sprint" (Partner & Product Team)
Partner and product team participate in recurring grooming sessions to review contributions.
- Review story: acceptance criteria, deliverables, impacting fields (API changes?, KFS Data,...), etc.
- Confirm availability of required resources (both functional and technical).
- Assign story points
- Create sub-tasks
- Schedule contribution for an upcoming sprint.
Open with an assigned Sprint (Partner & Product Team)
Story should continue to be used for discussions about the contribution, but sub-tasks will represent the work (see sub-task workflow).
Functional Roadblock (Partner)
Resolve issue and return to Open.
Technical Roadblock (Partner)
Resolve issue and return to Open.
Workflow - KFS Contribution Development (sub-tasks)
During each sprint, product team and partner will meet daily to check on status of contributions.
Stories are broken down into sub-tasks. There are several issue types available for sub-tasks:
| SUB-TASK TYPE | ASSIGNED TO | PARTNER RESPONSIBILITIES | PRODUCT TEAM RESPONSIBILITIES |
|---|---|---|---|
| Code | Contributing Developer | Complete development | Technical Leads review technical deliverables with the pull request. |
| Test | Product Team Functional Lead | Functional and technical resources available for questions | Assigned functional lead performs testing, reviews functional deliverables and creates defect sub-tasks if needed. |
| Defect | Contributing Developer | Fix bug(s) | Technical Leads review technical deliverables with the pull request. |
| Doc | Product Team Functional Lead | Functional and technical resources available for questions | Assigned functional lead updates user documentation. |
| Misc | Depends on task | Depends on task | Depends on task |
Open (n/a)
Sub-tasks ready to be picked up by next available assignee appropriate for the issue type.
In Progress (Partner or Product Team)
Work on sub-task is assigned and in progress.
Pull Requested - if needed (Product Team)
Sub-task types of Code and Defect must stop at this status to wait to be pulled into the main repository by the product team. If additional code reviews are required, this is where they would take place.
Sub-task types of Misc, Doc and Test do not stop at this status.
Functional Roadblock (Partner or Product Team)
Resolve issue and return to In Progress.
Technical Roadblock (Partner or Product Team)
Resolve issue and return to In Progress.
Testing Roadblock (Partner or Product Team)
Resolve issue and return to In Progress.
Closed (Partner or Product Team)
Work is completed.
Deliverables
Before contributing to Kuali software, an organization must have a Corporate Contributor License Agreement on file, and an individual contributor must have Contributor License Agreement on file.
Required and pending contribution deliverables will be reflected on the KFS Contribution Development issue. Here is a list of potential deliverables with some basic information about each. The sustaining team will collaborate with partners to ensure that they have the knowledge required to meet deliverable requirements for each contribution. Support from the contributing partner is required from the time the issue is created until the status of the issue is completed.
| Deliverable | When Required? | Description / Notes | Reference Documentation |
|---|---|---|---|
| Testing Scenario(s) | Always | Step-by-step testing instructions to facilitate project QA and maintenance of project testing scenarios and plans. | |
| User Documentation | Usually for Enhancements | The HTML end-user documentation that is delivered with KFS. You are not expected to write HTML or modify the word documents we use to generate it with doc-to-help directly. If your changes require modifications to existing documentation, we will provide you with a word doc containing pertinent sections and ask you to modify with revision tracking turned on. If your changes require new documentation (e.g. new document type), we will provide you with a word doc containing a similar example as a content guideline. | e.g. Cash Control Document |
| Technical Documentation | Sometimes for Enhancements | Content for our public documentation space is required for new technical infrastructure. | e.g. Batch Container |
| Code Review(s) | Usually for Enhancements | Crucible and synchronous are both options. | Financials Documentation Home |
| Liquibase Script(s) | Required for Data Structure Changes | Required when data structures are added, removed, or modified. |
|
| Approval | Required for Data Structure Changes | Data structures additions, removals, or modifications. | Financials Documentation Home |
| Bootstrap Data Approval | Required for Bootstrap Data Set Changes | Bootstrap data additions, removals, or modifications. When doing significant enhancements, you need to consider whether they do / should impact the bootstrap set. For example, the 1042S enhancement modifies a number of tables, so we need to check whether any of them are in the bootstrap data. Another good example is TEM, which added some tables that have data that no one should change and others which have data that very few would want to change (so, those tables were all added to the bootstrap data set). To see which tables are in the bootstrap data set you can look at work/db/kfs-bootstrap.sql | Financials Documentation Home |
| Rice Data Approval | Required for Rice Data Changes | Addition or modification of document types, system parameters, roles, permissions, responsibilities, etc. | Financials Documentation Home |
Additional Resources