Skip to end of metadata
Go to start of metadata
Placeholder - items under discussion or inclusion in charter
Process for engaging ARC in UXI requests for Rice changes
KRAD, KNS Equivalency, UXI are taking the place of the typical prioritization process in which the ARC typically engages. As such, the ARC is in a holding pattern
Formalize the PM working group, which works to manage patch release scope & slippage
Status of ARC/TRC F2F at Kuali Days - should this be a UXI meeting for the group?
 
 

 

Purpose

The Application Roadmap Committee (ARC) is responsible for setting scope and priorities for the Rice development team, maintaining the Kuali Applications Roadmap, managing requests for Rice resources and coordinating with the applications to create working groups as needed. 

Guiding Principles

1. The primary function of Rice is to support application projects. The Application Roadmap Committee will be the primary body for prioritizing and deciding new projects, ownership of shared projects, specification development efforts, etc.

2. Rice must also provide a general-purpose framework and middleware suite that can be used by any institution to build custom applications or integrations that are not specific to Kuali applications.  

3. Rice solicits investing partners to fulfill its primary and secondary functions.There are three types of partners: participants in single projects, participants in multiple projects, and participants in shared projects, such as Rice.  Partners are both individual Kuali applications and institutions that may or may not be partners in other Kuali applications. 

4. Kuali must remain up to date on its technology infrastructure over time, but technology changes that affect the application areas must be coordinated and prioritized through the application area Functional Councils and institutional partners in conjunction with consultation from technical architects. The functional needs of Kuali shall drive the technology direction.

Rice Scope and Development 

(RED = paraphrased or directly copied from Rice Charter) 

The ARC determines the functional scope of Rice, in consultation with the TRC (Technology Roadmap Committee).  The ARC will determine the relative priorities, sequence and timing of the overall development of Kuali Rice for both long-term roadmap planning and incremental major or minor release cycles. The ARC will create, publish and maintain a Kuali Rice Roadmap, which outlines the components and functionalities that are included in upcoming releases.

Functionality shall be categorized into core components that are important to the Kuali Applications for addressing any gaps in middleware and application development needs. Consideration for fulfilling these gaps will include evaluating existing best of breed open source software products, or via contributions developed from Interested Parties. Kuali Commercial Affiliates, or commercial vendors, are encouraged to review the Rice functional scope and define projects to develop software modules and services that are complementary to the core components. 

The ARC should review and consider the Strategic Directions wiki (link) during decision making and priority setting. The Kuali Rice Board of Directors will arbitrate any decisions that require escalation.  

The ARC is involved in the following development phases of Rice: 

  • Preparation and Planning:  Feature recommendations/prioritization, timeline analysis against Kuali application timelines, creation/review of change requests 
  • Application & Technology Architecture:  Cross-application impact analysis to understand connections and dependencies between Kuali applications and components

Committee Structure

Project Organization and Sustainability

The Kuali Rice project provides essential middleware services leveraged by many in the Kuali community. As such, the Rice project sustainability and governance model reflects these primary constituents:

1. Kuali Application Projects. Kuali Application projects such as KFS, KS, KC, and OLE leverage Rice middleware as well as the application development framework and UXI framework and standards under development by the Kuali User Experience Initiative (UXI). While each project leverages these elements of Rice differently, each has a vested interest setting priorities for the Rice roadmap. 

2. Investing Partners. Education institutions and companies become investing partners in Rice for a variety of reasons. Often a campus intends to leverage Rice middleware as a key part of the enterprise architecture, or enable rapid and consistent enterprise application development by leveraging Rice development and UXI framework and standards under development by the Kuali User Experience Initiative (UXI). Institutions who want to contribute directly and influence the future of Rice become investing partners.  

3. The Kuali Foundation. The Kuali Foundation has a stake in the success of Rice on behalf of its membership and on behalf of the partners in the application projects. A part of Kuali’s value depends on a high level of re-use and common technology (and user experience?) among the applications. The Rice project is key to that value, and the Rice project governance ensures that the interdependencies between the applications are managed well.

Membership

Membership shall consist of application Project Managers, a functional representative for each application with broad application experience appointed by the FC chairperson, a functional representative from each investing partner, and representation from the UXI effort. 

Roles

Name

Voting Status

Chairperson

Voting or Non-voting

Vice Chairperson

Voting or Non-voting

Project Managers

Non-Voting

Functional representative from each application

Voting

Rice Lead Architect

Voting

Functional representative Investing partner

Voting

UXI representation????

One vote per application or investing partner. Voting may be delegated to a representative of that application or investing partner. Kuali application partner votes are weighted at 51% of the overall vote. 
Rice will have one vote on the committee. Voting will be conducted using the Apache Foundation voting rules.

Proposed:  Change in the weight of application vote given the increase in partner application dues vs. investing institutions.  

Commitment 

Members of this committee are expected to participate in all calls and meetings. Each application is expected to have at least one representative on every call. Calls are expected to be once per month, though special sessions may be called in the event of time-sensitive votes on releases or other matters. Calls typically last 1 hour. In addition, members may be called upon for additional work between calls and meetings typically on the order of 2-5 hours. Work above this level may require formation of a working group.

Rice Project Management

The Project Manager reports to the ARC. (The Rice Charter shows the PM reporting to the Rice Board.  Other applications have their PM in a dual reporting to FC and Board.  What is desirable here? If the ARC is responsible for determining priority and scope...) 

The ARC sets priorities for Rice.  

The Project Manager manages the development team.

The Project Manager makes recommendations when changes in scope or timeline are necessary for ARC decision. 

The ARC votes/decides on changes in scope or timeline.  

The Rice Board resolves resource shortfalls and issues where the ARC needs executive-level input

Process

All requests for RICE resources are initiated with a JIRA. JIRAs requiring a large number of RICE resources will come to the ARC for approval and prioritization.

The ARC will create working groups as needed to assist applications with integration issues identified by members of the ARC.  

Decisions will be made on a voting membership basis. Votes require a simple majority to pass. Tie votes do not pass.

The Kuali Applications Roadmap will be updated as applications define scope and timelines. 

Issue Management

JIRA will be used to submit and track issues related to this committee. Issues will be reviewed by the Project Manager and assigned to an individual responsible for analysis.  Significant issues will be escalated to the ARC for review and prioritization, if necessary 

Action Items

The chairperson will collect action items which include a name, a description, a due date, and a status. Items will be tracked from meeting to meeting.  All decisions shall be recorded in meeting minutes.

Working Groups

Working groups will be formed by the ARC to 

  • Assist applications with integration issues identified by members of the ARC. 
  • Develop functional specifications and high level technical designs.
  • Identify issues that can't be resolved and take them forward to the Application Roadmap Committee.

Communication and Transparency

Transparency

Kuali and it's related projects are all part of a dynamic open community approach to application development. As such, it is important that business conducted by the Application Roadmap Committee be conducted in a free and open manner, accessible to all. Specifically, this means:

  1. Minutes of all calls and meetings will be kept and published in a public place (Google Docs).
  2. Final documentation produced by the committee <???> .

Communication

Communication in/out of the Application Roadmap Committee is primarily to the following:

  1. Technology Roadmap Committee
  2. Kuali Rice Board
  3. Kuali Executive Director
  4. All functional councils and boards
  5. UXI operating and steering committees 

Outgoing communication shall be:

  1. A response to a request
  2. Reports (to be determined)
  3. Internally generated questions or requests.

Incoming communication shall be:

  1. Requests from other Kuali committees or boards.
  2. Inputs can come from working groups.