Request for Change

Process Overview

Beginning February 1, 2021, any development that is deemed a substantial change to Elentra ME or Elentra Mobile is required to go through a formal Request For Change ("RFC") process, which is managed by the Elentra ME Product Management Committee ("PMC").

“Substantial Change(s)” means, but is not necessarily limited to meaning:

1. A new feature or concept in the software

2. A new technology or library that is being introduced to the software

3. A feature or enhancement that breaks backward compatibility with an existing feature

4. A change that will impact the semantics or structure of the data being stored

5. A change that may affect the security, usability, or accessibility of the software

Purpose

The purpose or goal of the RFC process is to:

• help monitor and coordinate feature development in Elentra to promote sustainable development, to create features we can build on in the future, and to benefit as many consortium members as possible;

• provide a way to analyze and document all the places that a proposed change touches other parts of Elentra to better inform the initial development approach and have a clear idea of what additional work might be required in the future;

• promote intentional collaboration and development with an eye to the overall product.

Stages

Stage 1: Initial Request

In order to initiate a change within the Elentra Platform, as always, you begin by creating a Jira Issue that reflects your institution's needs (e.g., Task, Story, Bug).

PMC representatives regularly review all new Jira Issues, and if needed, an RFC Status field is set, indicating that the Issue requires additional details as part of the RFC process.

Stage 2: Provide RFC Details and Seek Community Feedback

The Jira Issue Reporter ("RFC Owner") provides the requested additional details about their change directly on their existing Jira Issue. Additionally, the RFC Owner works with the chair of the PMC to prepare a one page summary of their plan. The Product Management Committee then solicits input from the Elentra Consortium community and consults the Architecture Review Committee ("ARC") as needed.

Stage 3: Ongoing Support and Development

Once development work is complete (alongside ongoing support as-needed), the RFC Owner updates the documentation to reflect any changes made and discrepancies between their original plans and the final product. A Pull Request is then created, then reviewed and tested by the Elentra Consortium Core Team.

Overview

High-level overview of the Request For Change ("RFC") process.

Stage 1: Initial Request

In order to initiate a change within the Elentra Platform, as always, you begin by creating a Jira Issue that reflects your institution's needs (e.g., Task, Story, Bug).

PMC representatives regularly review all new Jira Issues, and if needed, an RFC Status field is set, indicating that the Issue requires additional details as part of the RFC process.

Create Jira Issue

Log into the Elentra Consortium Jira environment, and click the "Create" button at the top of the screen. The following fields are required for any new Jira Issue:

• Project Elentra ME or Elentra Mobile App

• Issue Type Task, Story, or Epic

• Summary Write a summary to capture the main purpose of your proposed change.

• Description Include the problem you are trying to solve and your proposed solution. Also include your school's priority (e.g., low, medium, high, highest).

• Component Indicate all Elentra Platform components related to this Issue.

• Team The team that will work on this Issue.

• Labels Provide any Teams (institutions) who have indicated an interest in this Issue.

The Issue Status will automatically be set to New Issue once the new Issue is saved.

Issue Review Process

Product Management Committee ("PMC") representatives will review all new Issues a minimum of every three business days and respond accordingly. Representatives may ask questions for clarification or provide an RFC Status on the Issue itself.

The RFC Status will be one of:

Not Required

• PMC representatives will provide a rationale in the comments if needed.

• The Issue will be assigned back to the creator, and the status set to To Do.

  • Jira Issue creators are strongly encouraged to continue with other communication strategies, including presenting updates at a bi-weekly consortium call, posting in the #developers or #help Slack channels, or using the [e-mail] mailing list.

Required (Pending)

• The Issue will be assigned back to the creator, and the status set to To Do with the expectation that the creator will complete the information required for RFC Stage 2.

Jira Issue Flagged for PMC Review

• PMC representatives need to consult the Product Management Committee or other stakeholders prior to making a decision whether or not this Issue requires additional documentation.

• The Issue status will remain as New Issue with an RFC Status of None and will remain flagged until further consultation is complete.

• PMC representatives will provide comments and updates, as deemed necessary.

Stage 2: Provide RFC Details and Seek Community Feedback

The Jira Issue Reporter ("RFC Owner") provides the requested additional details about their change directly on their existing Jira Issue. The Product Management Committee then solicits input from the Elentra Consortium community and consults the Architecture Review Committee ("ARC") as needed.

Providing RFC Details

The RFC Owner uses their existing Jira Issue to provide the requested additional details about their proposed change. Simply click on the RFC Details menu item and complete the five requested fields: Detailed Design, Technical Adoption Strategy, Risks, Proposed Timing, and Unresolved Questions.

Detailed Design

Information that you may wish to include in the Detailed Design section:

• Business Rules and Business Requirements (see additional information below).

• Which user groups are impacted by the change and how (e.g., Admin, Faculty, Students; what kind of training might be necessary).

• Reporting requirements (as applicable) - please include new reports you are creating or reports you foresee in the future, and/or any required updates to existing reports.

• Subject Matter Expert information/perspective (as applicable).

• Any new terminology being introduced.

• Any new technology being considered/required and justification for it (e.g., if a new library or package is being introduced or replacing existing technology, what is insufficient in the existing technology?).

• Dependencies (any interactions with other Elentra components).

• Any breaking (non-backwards-compatible) changes.

• Continuing Development: Do you anticipate continuing to build on this feature in the future? If yes, how?

• Wireframes/Mockups/Prototypes: If available, please provide a link or attach a file.

Technical Adoption Strategy

Information that you may wish to include in the Technical Adoption Strategy section:

• How will existing Elentra ME installations adopt it this change?

• Is this a breaking change?

• Will there be database migrations?

• Will there be database settings for this?

Risks

Information that you may wish to include in the Risks section:

• Are there technical risks to this?

• Are there business risks to this?

• Are there risks associated with not doing this?

Proposed Timing

Information that you may wish to include in the Proposed Timing section:

• What are your timelines and major delivery milestones?

• When should the Elentra Consortium Core Team expect to receive this work?

Unresolved Questions

Information that you may wish to include in the Unresolved Questions section:

• Optional, but recommended.

• What parts of the project and design are still TBD?

To complete your Detailed Design section, please refer to the guidelines below regarding Business Rules, Business Requirements, and Acceptance Criteria.

Business Rules

Business Rules define how users can or cannot interact with the feature being developed. Additionally, they define rules that the school or Elentra has on any topic relevant to the feature.

Answer questions like:

• Who is using the feature?

• What user groups/roles have access to the feature?

• In what capacity can the declared roles access the feature? (create/read/update/delete)

• Are there restrictions of any type on using this feature?

• Define all conditions that must be met for the feature to be used.

Some examples:

• This feature is only accessible to administrators and faculty.

• Students will use this feature while at a clinic/hospital.

• Attendance tracking must be done during a session.

Business Requirements

Business Requirements define the way users interact with the feature to satisfy the rules. This is where you should specify behavior in the feature that relates to and does not contradict the defined rules.

Some examples:

• Non-authorized users should be directed to a registration page

• Feature must have excellent UI/UX on small devices like iPads and phones

• Students can only log attendance while an event is in progress

Acceptance Criteria

Acceptance criteria is a list of items that need to be satisfied for the feature to be considered “done.” This isn’t just a “technical requirements” list. It details all aspects of the feature that would allow stakeholders to consider it done. This should always be written from the end-user standpoint.

For example:

• When I click the sign-in button, the system signs me in and takes me to the dashboard.

• When I specify a filter in the form, the system should remember my preference, so I don’t have to re-filter.

• When I navigate away from the form then back, all my entries should be maintained.

For the RFC, the PMC requests acceptance criteria be submitted when you submit a pull request.

Once the RFC Owner has submitted the RFC Details, they should update the Jira Issue Status to In Review and change the Assignee to Unassigned in order to trigger the RFC Review process.

In addition to completing the Jira ticket, the RFC Owner is expected to work with the Chair of the PMC to create a one page handout about their RFC. The purpose of this handout is to provide the Consortium community with a resource they can use to publicize the RFC and feedback opportunities to their stakeholders.

Initial RFC Response

The PMC Secretary will respond within three business days and will include the following information:

• The date of the bi-weekly Elentra Consortium Community Meeting where this RFC will be announced.

• The date that the Community Feedback Period will close.

• A link to RFC Community Feedback space within Elentra Collaborate.

• The date that the PMC will review the RFC proposal.

RFC Announcement

On the date of the Elentra Consortium Community Meeting, the PMC Secretary or the RFC Owner will announce the RFC.

The announcement should include the Issue Title, Background/User Story/Use Case, and highlights of the change being proposed. This should be no longer than 10 minutes in length. Follow-up meetings, demos, or discussions with the community are encouraged for clarification purposes where necessary.

The Chair of the PMC will work the with RFC Owner to schedule a follow-up meeting where schools can invite relevant stakeholders to discuss the RFC.

In cases where the Elentra Consortium Community Meeting must be canceled or rescheduled, the PMC can, at their discretion, circulate information about an RFC using Slack and the [e-mail] mailing list.

Consortium Community Review and Discussion

The Elentra Consortium community will have 3–10 business days following the date of the RFC announcement at the Elentra Consortium Community Meeting to review, internally discuss, and provide comments on the RFC. During this time, the community follow-up meeting should occur to provide more opportunity for discussion and detailed understanding of the RFC.

The length of time for community feedback will depend on the complexity of the RFC and will be determined by the PMC in conjunction with the RFC Owner. Community comments should be made in the relevant space on collaborate.elentra.org. You can find a quick link to the relevant discussion board in the Jira ticket RFC details under the URL field.

Final PMC Review

On the community consultation closing date or at the next scheduled meeting, the PMC will review the RFC and the associated community feedback.

PMC members will use their best judgment, subject matter expertise and seek feedback from relevant external third-parties as necessary to classify the RFC Proposal as:

Rejected: Reject the RFC.

The applicant may continue with their development, but the PMC does not commit to reviewing, testing, or merging this change into the core product.

Delayed: Request additional information.

The PMC is requesting additional information before a decision can be made.

Provisionally Accepted: Accepted, but requires additional oversight.

The PMC will provide a list of areas that require additional oversight.

Accepted: Accept and support the RFC.

Stage 3: Ongoing Support and Development

RFC Owner Status Updates to PMC

While work is ongoing for a RFC project, the PMC requests monthly status updates from the RFC Owner. These can be provided by comments in Jira so that other community members can also track progress. Please include the following information:

• Brief summary of progress to date

• Notable changes to design or implementation

• Any unforeseen obstacles and how they were addressed

• Anyone specific to be notified of changes (e.g., Core Team graphic designer, other project partners)

• Has project documentation been updated to reflect changes (e.g., mock ups, business rules, etc.)

• Any update to project timing

Submitting for Review and Testing

Once development work is complete (alongside ongoing support as-needed), the RFC Owner updates the documentation to reflect any changes made and discrepancies between their original plans and the final product. A Pull Request is then created, then reviewed and tested by the Elentra Consortium Core Team.

Documentation

Your final documentation initiative should include enough detail that someone who is competent with Elentra ME would fully understand the need for and purpose of the change and what is required to set it up and use it.

This would include:

• screenshots or screencasts

• prerequisite technologies

• new or altered system settings

• new or altered cronjobs

• prerequisite Elentra data

• new or altered ACL

Once the RFC Owner has completed the documentation, they should update the Issue Status to In Review and change the Assignee to Unassigned in order to trigger the Elentra Consortium Core Team review process.

Based on the previously-determined priority and review effort required, as well as in consideration of the previously-suggested earliest possible release, the code review and testing of the work will be scheduled by the Elentra Consortium Core Team.

Ongoing Support

Support can be offered to Consortium participants in the form of:

• UI/UX design.

• Technical support.

• Ongoing development and code review.

• Facilitating opportunities to gather additional information from the community.

• Facilitating opportunities to share work completed with the community.