|
|
[[_TOC_]]
|
|
|
|
|
|
## Oniro Release Roadmap process (WIP)
|
|
|
|
|
|
### Description
|
|
|
|
|
|
The Oniro Release Roadmap Process manages the elements that at high level describe the Oniro Platform that is or will be released are proposed, life cycle, that is, the process define how those elements are proposed, defined discussed, agreed, approved, tracked, evolved, archived or deprecated.
|
|
|
|
|
|
The following considerations apply to this process:
|
|
|
* In an open environment a roadmap needs to be kept clean for a variety of reasons:
|
|
|
* The roadmap is a business development tool.
|
|
|
* Different members and engineers are interested in different parts of the Platform. The roadmap is a coordination tool.
|
|
|
* We expect and promote participation from community members without affiliation to Oniro Members. The process needs to promote such participation while keeping management and housekeeping needs under control.
|
|
|
* We are in the early stages of Oniro's development life cycle. Still, a high number of developers and managers from a variety of organizations are involved.
|
|
|
* Our intention is to become upstream of organizations that develop products based partly or entirely on Oniro. Our roadmap is an essential product design tool for them.
|
|
|
* This Roadmapping Process has been designed to have a clean roadmap as output while, at the same time, promoting interaction with as many ecosystem and community members as possible, as well as other.
|
|
|
* As stated at the [Oniro WG Charter](https://www.eclipse.org/org/workinggroups/oniro-charter.php)... "_Define and manage a product roadmap that brings together the Oniro developer's community and the platform consumers' expectations and needs, helping the adoption of Oniro technologies by the Working Group Members as well as the wider industry._", the definition and management of the Oniro Platform Release Roadmap correspond to the Oniro WG.
|
|
|
* Given that WGs do not deal with technical matters, the ownership is limited to business and product related topics. Technical topics, including the code that is finally shipped as part of the release, are owned by the projects so committers and the PMC as governance body assume hold the responsibility.
|
|
|
* Given that business and product topics affect, and sometimes drive, technical topics (the opposite is also true), coordination between business/product people (Working Group) and technical people (Projects) is required to define and manage the roadmap.
|
|
|
* Given that operating systems (and HW/SW platforms) are tightly coupled systems, and that Oniro is currently in an early stage of its development life cycle, such coordination is even more important.
|
|
|
* This coordination materializes when it comes to the Oniro Platform Release Roadmap at the Roadmap Team, beyond the fact that Committers are represented at the Oniro WG Steering Committee through an elected representative, according to the [Eclipse Foundation Working Group Process](https://www.eclipse.org/org/workinggroups/process.php).
|
|
|
* This process meets the Eclipse Foundation legal and IP framework as well as the Working Group and Projects principles and processes. In case of conflict or doubts in the interpretation, this Roadmapping Process should be adapted to meet Eclipse Foundation processes.
|
|
|
|
|
|
The following infographic summarises the Oniro Platform Release Roadmapping Process.
|
|
|
|
|
|
![](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/raw/main/oniro_roadmapping_process_infographic.png)
|
|
|
|
|
|
Get the [.pdf version of the Oniro Roadmapping Process infographic](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/blob/main/oniro_roadmapping_process_infographic.pdf)
|
|
|
|
|
|
## Terms and Definitions
|
|
|
|
|
|
### Roadmap items
|
|
|
|
|
|
Roadmap items is the name assigned to any element that constitute the Oniro PLatform roadmap. There are, essentially, two types:
|
|
|
* Initiatives: high level items that represent what the Oniro Working Group would like to see as part of the product being released.
|
|
|
* User stories/engineering tasks: items that describe at lower level needs, features and activities that engineers should address at project level required to meet those high level items.
|
|
|
|
|
|
In a code first organization, like Eclipse Foundation, roadmap items are expressed through a user-centric language. The goal is to enable the description of different elements (specifications, roadmap items, Test Compatibility Kit, etc.) in a way that could be understood by people with different profiles and backgrounds.
|
|
|
|
|
|
#### Initiatives (aka requirements)
|
|
|
|
|
|
An initiative is the name assigned to the roadmap item that describe the Oniro Platform users' needs that the Oniro WG and projects intend to address. It is expressed in a templated form, including user oriented language, and managed through Gitlab. Initiatives are always high level elements.
|
|
|
|
|
|
Initiatives as essential part of the Oniro Release Roadmap, are owned and managed by the Oniro WG.
|
|
|
|
|
|
Every initiative will be owned by a person. Such a person could represent one or several organizations. The main reason for this is that any initiative could potentially be challenged at any time and the best way to do it is by knowing who is responsible for it.
|
|
|
|
|
|
We have avoided the usage of the word *requirement* for a variety of reasons:
|
|
|
* In a code first organization, as well as in an Open Source development process, the word *requirement* has connotations that go against the culture that drives the decision processes and commonly accepted development practices.
|
|
|
* As a FOSS organization, we shall not impose any obligations stemming from wrongly used nomenclature.
|
|
|
* In different industries, requirements have different connotations and implications too.
|
|
|
* When it comes to modern software products movements, the concept of requirements brings fundamental challenges.
|
|
|
|
|
|
There are three types of initiatives based on their main origin and/or impact:
|
|
|
* Business initiatives
|
|
|
* Product initiatives
|
|
|
* Technical/technology initiatives
|
|
|
|
|
|
##### Business initiatives
|
|
|
|
|
|
Business initiatives define the reason behind a portfolio or product (needs) and what objectives of the performing organization will be fulfilled by undertaking the product design, creation and commercialization. They are also called business or stakeholders requirements.
|
|
|
|
|
|
Considerations about business initiatives:
|
|
|
|
|
|
> * Business initiatives/requirements are not objectives, but rather meet objectives (i.e., provide value) when satisfied.
|
|
|
> * Business initiatives/requirements _whats_ do not decompose into product/system/software requirement hows. Rather, products and their initiatives/requirements represent a response to business initiatives/requirements — presumably, _how_ to satisfy _what_.
|
|
|
> * Business requirements exist within the business environment and must be discovered, whereas product requirements are human-defined (specified).
|
|
|
> * Business requirements are not limited to high-level existence, but need to be driven down to detail.
|
|
|
> * Regardless of their level of detail, however, business requirements are always business deliverable whats that provide value when satisfied; driving them down to detail never turns business requirements into product requirements.
|
|
|
>
|
|
|
> In system or software development projects, business initiatives/requirements usually require authority from stakeholders. This typically leads to the creation or updating of a product, system, or software.
|
|
|
>
|
|
|
> [Wikipedia](https://en.wikipedia.org/wiki/Business_requirements)
|
|
|
|
|
|
##### Product initiatives
|
|
|
|
|
|
Product initiatives describe needs that the product aims to satisfy. They prescribe properties of the product.
|
|
|
|
|
|
> It is a broad concept that could speak to any necessary (or sometimes desired) function, attribute, capability, characteristic, or quality of a system for it to have value and utility to a customer, organization, internal user, or other stakeholder.
|
|
|
>
|
|
|
> The product/system/software requirements usually consist of both functional requirements and non-functional requirements. Although typically defined in conjunction with the product/system/software functionality (features and usage), non-functional requirements often actually reflect a form of business initiatives/requirements which are sometimes considered constraints. These could include necessary performance, security, or safety aspects that apply at a business level.
|
|
|
>
|
|
|
> [Wikipedia](https://en.wikipedia.org/wiki/Business_requirements)
|
|
|
|
|
|
##### Technical/technology initiatives
|
|
|
|
|
|
Technical initiatives describe architectural needs and other technical related needs that the product needs to consider in order to support any of the other requirements. They prescribe technical properties of the product.
|
|
|
|
|
|
#### User Stories / engineering tasks
|
|
|
|
|
|
These roadmap items are owned and managed within the projects. In most cases, they are inherited from Initiatives relating those with actual code, artifacts or any other elements to be released.
|
|
|
|
|
|
Since they are owned by the projects, this process does not define how they should be described, managed or related to the Initiatives. It will be the PMC who will provide such descriptions. Such process will be referenced to this roadmapping process for convenience.
|
|
|
|
|
|
### Technology Compatibility Kit (TCK)
|
|
|
|
|
|
This term is defined in the [Eclipse Foundation Specification Process](https://www.eclipse.org/projects/efsp/#efsp-terms) as "Software and/or documented requirements that support the testing of implementations to ensure that they are compatible with the Specification."
|
|
|
|
|
|
## Relation between roadmap items and other elements
|
|
|
|
|
|
Initiatives are a key element. They are an essential step between the Program Plan, the code and the specifications to be released Initiatives justify and drive the creation, acceptance, auditing and validation of the roadmap items created, owned and managed by the different Oniro projects.
|
|
|
|
|
|
This diagram explains such relation.
|
|
|
|
|
|
![](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/raw/main/Oniro_elements_relation.png)
|
|
|
|
|
|
## Roadmapping Process stakeholders
|
|
|
|
|
|
These are main stakeholders of this process:
|
|
|
* Submitter
|
|
|
* Roadmap team
|
|
|
* Oniro WG SC
|
|
|
* Sponsor
|
|
|
* Owner
|
|
|
|
|
|
There are also others: the committers/PMC members, which are represented within the Roadmap Team and the Oniro WG SC as described in this section.
|
|
|
|
|
|
### Initiative Submitter
|
|
|
|
|
|
This is a person who submits an initiative for the consideration of the Roadmap Team and the potential approval of the Oniro Working Group. The submitter might act in representation of one or more organizations or community members.
|
|
|
|
|
|
A submitter must have an Eclipse Foundation account. This person can be the Owner of the initiative.
|
|
|
|
|
|
### Roadmap team
|
|
|
|
|
|
The roadmap team has two main goals:
|
|
|
* Management of the Oniro WG Release Roadmap.
|
|
|
* Coordination between the Working Group and the projects under Oniro TLP project, around the Oniro PLatform Release Roadmap.
|
|
|
|
|
|
To achieve such goals, the Roadmap Team composition is:
|
|
|
* 2 Committers/Participants appointed by the PMC
|
|
|
* 3 People appointed by the Oniro WG SC
|
|
|
* Support by EF, as usual.
|
|
|
|
|
|
The roadmap team manage the Initiatives, associated to the Oniro Platform Release Roadmap, not the rest of the roadmap items. That corresponds to each project and it is coordinated within the PMC, according to the [Eclipse Project Handbook](https://www.eclipse.org/projects/handbook/). The roadmap team manages the roadmap at Oniro WG level.
|
|
|
|
|
|
### Oniro WG SC
|
|
|
|
|
|
The Oniro roadmap is owned by the Oniro WG.
|
|
|
|
|
|
The Oniro WG SC approves the initiatives that belong to the current Roadmap cycle. This Governance Body provides guidelines to the roadmap team on what kind of information is required for them to evaluate as well as the convenience and impact of each initiative on the overall product.
|
|
|
|
|
|
The Oniro WG SC approves the Roadmapping Process and appoints the corresponding members of the Roadmap Team, in this case, 3 members.
|
|
|
|
|
|
### Sponsor
|
|
|
|
|
|
This is an organization(s) or individual(s), like a community member, that supports the initiative in all of the following ways:
|
|
|
* Assuming the execution costs associated to the initiative.
|
|
|
* Assuming the maintenance costs associated to the initiative.
|
|
|
* Assuming the management costs derived from the above activities.
|
|
|
* Assuming the communication costs related with the initiative including promotion, community management, etc.
|
|
|
* Support those entitled to develop, maintain and manage the initiative in whatever they need to keep the initiative, associated code and artifacts healthy.
|
|
|
|
|
|
In other words, in order for any initiative to be part of the Oniro release roadmap, it requires a sponsor. Members will assume the sponsor role for initiatives proposed by community members in case they are not willing or able to do it. The Oniro WG SC will determine the capacity/costs assigned to this purpose.
|
|
|
|
|
|
If during the life cycle of the initiative, the sponsor(s) leaves or no longer assumes the expected commitments diligently, a similar process to the one described below for the Owner role will be executed by the Roadmap Team.
|
|
|
|
|
|
In the case of individuals with no affiliation to any Oniro Members or related organizations, the sponsor can be the owner. This could be the case for community driven contributions that end up being part of the coming release.
|
|
|
|
|
|
### Owner
|
|
|
|
|
|
The owner is the main point of contact of an Approved Initiative. Ideally, is a subject expert.
|
|
|
|
|
|
When the owner leaves the Oniro project, no longer wants to hold such responsibility or does not meet the expectations derived from the assignment, the initiative will be considered an orphan and a new owner will be assigned either:
|
|
|
* Through a call for ownership process.
|
|
|
* Appointed by the Roadmap team.the initiative sponsor will propose a candidate.
|
|
|
* It is expected the support of the Sponsor in this process.
|
|
|
* Such a process will be elaborated and approved by the roadmap team and ratified by the Oniro WG SC.
|
|
|
|
|
|
## Process structure and workflow
|
|
|
|
|
|
Oniro Platform roadmap is structured in two different phases:
|
|
|
* Phase 1: qualification. This is the phase where initiatives are submitted, matured, reviewed and approved to become part of the Oniro Platform roadmap
|
|
|
* Phase 2: roadmap. This is the phase where the initiatives are structured and decomposed into actionable items. A significant part of this phase takes place in the projects.
|
|
|
|
|
|
### Qualification phase
|
|
|
|
|
|
#### Description
|
|
|
|
|
|
This is the space where project participants, company representatives, third parties or any individual with an Eclipse Foundation account can submit initiatives to be considered by Oniro.
|
|
|
|
|
|
Such submitted initiatives are matured in this space through a process determined by the Oniro Roadmap Team, driven by the submitter and supported by the Oniro Roadmap Team.
|
|
|
|
|
|
Those initiatives that, for whatever reason, are not suitable for the evaluation of the Oniro WG SC or, being evaluated, they have not been approved, will remain in this space.
|
|
|
|
|
|
#### Stages
|
|
|
|
|
|
The stages of the Roadmapping Process at the qualification phase are:
|
|
|
* Initiative.Proposal
|
|
|
* Initiative.Evaluation
|
|
|
* Initiative.Description
|
|
|
* Initiative.Assessment
|
|
|
* Initiative.Approval
|
|
|
* Sandbox
|
|
|
|
|
|
You can see a representation of the different stages in this board: [Process Stages board](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/boards/1375)
|
|
|
|
|
|
##### Initiative.Proposal
|
|
|
|
|
|
* Submitter submits an Initiative as issue (Gitlab terminology).
|
|
|
* The Roadmap team processes it.
|
|
|
* The roadmap team supports the Submitter to put the initiative in a state where the initiative can be evaluated.
|
|
|
|
|
|
##### Initiative.Evaluation
|
|
|
|
|
|
* The Roadmap Team evaluates if the proposed initiative should be part of the product roadmap.
|
|
|
|
|
|
##### Initiative.Description
|
|
|
|
|
|
* With the support of the Roadmap Team, the Submitter will add additional required information.
|
|
|
* When the Roadmap Team considers it ready, the initiative is proposed to the Oniro WG SC for its assessment as a potential part of the release.
|
|
|
|
|
|
##### Initiative.Assessment
|
|
|
|
|
|
* The Oniro SC WG evaluates if the Initiative is suitable to become part of the Release and additional effort should be invested to potentially approve it or not.
|
|
|
* If the assessment is positive, the initiative needs to be complemented with additional information focusing on capacity availability, assignment, impact on existing roadmap items, completion projections, etc.
|
|
|
* The Sponsor is involved in this information gathering.
|
|
|
* Based on the above information, the Roadmap Team provides its evaluation as input for the decision to be taken by the Oniro WG SC.
|
|
|
|
|
|
##### Initiative.Approval
|
|
|
|
|
|
* The Oniro WG SC evaluates the information and potentially approves the initiative as part of the next Oniro Release.
|
|
|
|
|
|
##### Sandbox
|
|
|
|
|
|
* If the evaluation is not successful, then the initiative remains in the qualification phase. The sandbox is the stage at which they will remain until it is deprecated/archive or re-submitted.
|
|
|
* Initiatives at this stage are living items which can and should be updated.
|
|
|
* If the initiative has not been considered by the Oniro WG SC before, it can be submitted again at any point in time by the former Submitter or any other person.
|
|
|
* If the initiative has been considered before by the Oniro WG SC, it can be submitted again by the Submitter or any other person. Given the nature of the initiative at this point, since it includes a deep analysis involving capacity, resources, timing... the Roadmap Team should support such re-submission.
|
|
|
* If the initiative has been already approved by the Oniro WG SC but, for whatever reason, the initiative should be changed, merged, updated... in order to be re-submitted, the Roadmap Team will be in charge of such process.
|
|
|
|
|
|
### Roadmap phase
|
|
|
|
|
|
#### Description of this phase
|
|
|
|
|
|
The approved initiatives will become part of the Roadmap. They are described as roadmap items as part of the Release backbone.
|
|
|
|
|
|
#### Stages
|
|
|
|
|
|
The stages of the Roadmapping Process at the Roadmap phase are:
|
|
|
* Roadmap.Communication
|
|
|
* Roadmap.Backbone
|
|
|
|
|
|
##### Roadmap.Communication
|
|
|
|
|
|
* The initiative content and metadata is adapted to become part of the Oniro Platform Release Roadmap.
|
|
|
* The issue is moved from the initiative-qualification repository by promoting it (Gitlab terminology) as Epic to the subgroup initiative-release-roadmap.
|
|
|
* The initiative is adapted to be part of the Release Roadmap so it is consistent with other initiatives and it gets ready to be copied automatically into the engineering-roadmap subgroup at oniro-core project.
|
|
|
* The new initiative is communicated widely across the community through both mailing lists, oniro-wg and oniro-dev.
|
|
|
* If for whatever reason, the initiative will not make the release or needs to be redefined, the Roadmap Team will move it to the sandbox and communicate it widely across the project, including the Oniro WG SC.
|
|
|
|
|
|
##### Roadmap.Backbone
|
|
|
|
|
|
* The newly promoted initiative as epic is copied automatically to the engineering-roadmap subgroup at oniro-core project, so it can be described and decomposed in roadmap items (user stories, engineering tasks) by committers and participants.
|
|
|
* These roadmap items are owned by the projects.
|
|
|
|
|
|
## Oniro Platform Release Roadmap Process Cadence
|
|
|
|
|
|
This table summarises the cadence or cycles of the main events of the Oniro Platform Roadmap process, especially those involving decision making processes.
|
|
|
|
|
|
| Event | Cadence | Purpose | Group | Notes |
|
|
|
| ------ | ------ | ------ | ------ | ------ |
|
|
|
| Initiative.Evaluation | bi-weekly | Coordination, reviews and approvals | | |
|
|
|
| Initiative.Assessment | monthly | evaluation done by the Oniro WG SC on monthly basis of the proposed initiatives | | 10% of new features coming from the community |
|
|
|
| Initiative.Approval | bi-monthly | Strategic/pivoting functionalities reviewed, risks/opportunities evaluated | | |
|
|
|
| Release evaluation | on every major milestone | Feature delivered, tests passed, lessons learnt | | done by the Oniro WG SC based on the Roadmap Team report. |
|
|
|
|
|
|
These cadences should be shorten, when possible, by applying measures that partly move the process away from being committee driven into a more asynchronous approach.
|
|
|
|
|
|
## Oniro Platform Release Roadmap Process modifications approval
|
|
|
|
|
|
This process is owned by the Oniro Working Group so, after a discussion widely across Oniro's ecosystem and community, it is approved by the Oniro Working Group Steering Committee.
|
|
|
|
|
|
We acknowledge that, at first, modifications of this process will be needed in order to meet the expectations. Such modifications can come from any ecosystem or community member, as well as the Eclipse Foundation itself. They will be collected, processed and managed by the Roadmap Team. They will present the modifications to the Oniro WG Steering Committee for its evaluation and potential approval.
|
|
|
|
|
|
## Oniro Roadmapping Process approval and implementation
|
|
|
|
|
|
This Roadmapping process must be approved by the Oniro WG Steering Committee. Given its nature, it is expected to be socialized among both the WG and the projects. Feedback from the PMC, committers and participants is essential.
|
|
|
|
|
|
This Oniro roadmapping process must be compatible with Eclipse Foundation processes and practices.
|
|
|
|
|
|
Oniro acknowledges that the implementation of this process should serve its purpose in an effective and efficient way, which will take time.
|
|
|
* The process will need to be put up to test so a critical thinking attitude will be associated with its definition and implementation.
|
|
|
* Before onboarding into Eclipse Foundation, the Members had procedures and practices to create and manage the roadmap. The onboarding of Oniro as a fully functional Eclipse Foundation project requires an evolutive approach from the previous state to one fully embracing EF ByLaws, processes and practices. In any case the starting point have to be compatible with existing EF ByLaws, processes and practices.
|
|
|
* This process will be put in place once the current release roadmap process is approved, not before that event.
|
|
|
* From that moment on, this process will apply governing any change in any of its high level elements (initiatives).
|
|
|
* The goal is to have an oiled Oniro Platform Release Roadmapping process by the time the next release roadmap is created, around 2023Q1
|
|
|
|
|
|
### Contacts and feedback
|
|
|
|
|
|
In order to ask questions or provide feedback, please contact the Roadmap Team.
|
|
|
|
|
|
Note: until the first version of the Oniro PLatform Release Roadmap Process is approved by the Oniro WG SC, the contact people are:
|
|
|
* Agustin Benito Bethencourt @toscalix
|
|
|
* Sebastian Serewa @sserewa
|
|
|
* Jarek Marek @jmarek |