This section of the wiki is meant to communicate how the Open Horizon open-source software project (OH) accepts and handles submissions requesting new functionality. The process outlined below is intended to be complete and thorough but can always be improved. If there is a situation that this document does not cover, please bring it to the attention of a Technical Steering Committee (TSC) voting member along with a suggested resolution.
Feature Request Lifecycle
Definition of Terms
This document will use the term Feature to describe a cohesive and internally consistent collection of functionalities intended to accomplish one or more specific user outcomes (defined by Design Thinking as “Hills”). The intent of the Feature Request process is to allow anyone to propose their ideas for OH Features and to clearly communicate at least the minimum amount of information required to successfully present and evaluate the submission.
This document will use the term Feature scope, or scope, to refer to the appropriate organizational group that will have authority over a particular Feature submission. Some Feature Candidates may clearly fall within the jurisdiction of a single Working Group (WG). Others may have cross-group impacts, or even affect all WGs, and thus fall under the oversight of the TSC. The intent of this process is to properly identify the scope, and the relevant decision-maker for that scope, before the proposed Feature is deemed ready for presentation to the appropriate audience.
This document will use the term Sponsor User, or Sponsors, to refer to an individual or organization that has a vested interest in the user outcomes of the proposed Feature Candidate. The author of the submission may also be the Sponsor User.
Processes and Tools
Any proposed Feature should be described and communicated according to Design Thinking keys and processes. Feature deliverables will be stored and managed using GitHub and ZenHub tools according to a flexible/pragmatic Agile/Kanban methodology. And the Feature’s user outcomes will be decomposed into technical requirements that can be developed, merged, and activated as sub-features by feature flags as they are completed.
Overview
The Feature Request process is divided into four distinct stages, collectively comprising the Feature Request Lifecycle:
- Feature Candidate – This is the stage where an idea for one or more user outcomes is defined as a Feature, described and presented, and accepted or rejected.
- Feature Design – This is the stage where the Feature is built. The technical requirements will be decomposed into discrete tasks/issues, development will ensue, then testing and deployment.
- Feature Support – This stage covers the time when the functionality is available to the public and OH will work to fix any identified bugs.
- Feature Archive – This stage is the final resting place for obsolete, superseded, or deprecated Features that may be of historical significance but are no longer under development or supported.
Getting started
To create and submit a new Feature Request Candidate, navigate to the Feature Request listing page and click the button to get started.