... | ... | @@ -4,22 +4,22 @@ |
|
|
|
|
|
### 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 Oniro Release Roadmap Process manages the elements that, at high level, describe the Oniro Platform that is or will be released by the Oniro project under the Eclipse Foundation release process. The process defines how those elements are proposed, defined discussed, agreed, approved, tracked, evolved, archived or deprecated, among other aspects like stakeholders, cadences of the main ceremonies, etc..
|
|
|
|
|
|
The following considerations apply to this process:
|
|
|
* In an open environment a roadmap needs to be kept clean for a variety of reasons:
|
|
|
* In an open environment a high level 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.
|
|
|
* Different members and engineers are interested in different parts of the Platform, expressed through the roadmap. The roadmap is a coordination tool.
|
|
|
* We expect and promote participation from community members without affiliation as well as from Oniro Members employees. The process needs to promote such participation while keeping management and housekeeping tasks or needs under control to be effective.
|
|
|
* 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. Clarity is essential for all of them.
|
|
|
* Oniro intention is to become upstream for organizations that develop products based partly or entirely on Oniro. Our roadmap is an essential product design tool for those organizations.
|
|
|
* This Oniro Platform Release Roadmap Process has been designed to have a clean roadmap as output while, at the same time, promoting interaction with as many ecosystems and community members as neccessary.
|
|
|
* 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 WGs do not develop software, the ownership is limited initiatives (high level elements). Stories and engineering tasks, including the code that is finally shipped as part of the release, are owned by the corresponding projects. Committers and the PMC as governance body hold the responsibility for those.
|
|
|
* 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.
|
|
|
* 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 Oniro Platform Release Roadmap Process should be adapted to meet Eclipse Foundation processes.
|
|
|
|
|
|
The following infographic summarises the Oniro Platform Release Roadmapping Process.
|
|
|
|
... | ... | @@ -31,7 +31,7 @@ Get the [.pdf version of the Oniro Roadmapping Process infographic](https://gitl |
|
|
|
|
|
### Roadmap items
|
|
|
|
|
|
Roadmap items is the name assigned to any element that constitute the Oniro PLatform roadmap. There are, essentially, two types:
|
|
|
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.
|
|
|
|
... | ... | @@ -39,17 +39,19 @@ In a code first organization, like Eclipse Foundation, roadmap items are express |
|
|
|
|
|
#### 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.
|
|
|
An initiative is the name assigned to any roadmap item that describes the Oniro Platform users' needs that the Oniro WG and projects intend to address.
|
|
|
* Initiatives are expressed in a templated form, including user oriented language.
|
|
|
* Initiatives are managed through Gitlab.
|
|
|
* Initiatives are always high level elements.
|
|
|
* Initiatives are the essential part of the Oniro Platform Release Roadmap, owned and managed by the Oniro WG.
|
|
|
|
|
|
Initiatives as essential part of the Oniro Release Roadmap, are owned and managed by the Oniro WG.
|
|
|
Every initiative will be owned by person. Such a person could represent one or several organizations. The main reason for this stakeholder 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.
|
|
|
|
|
|
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:
|
|
|
This Process guidelines avoids 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.
|
|
|
* When it comes to modern software products movements, the concept of requirements brings fundamental challenges we want to avoid.
|
|
|
|
|
|
There are three types of initiatives based on their main origin and/or impact:
|
|
|
* Business initiatives
|
... | ... | @@ -58,7 +60,7 @@ There are three types of initiatives based on their main origin and/or impact: |
|
|
|
|
|
##### 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.
|
|
|
Business initiatives define the reason/need behind a portfolio (or product) as well as what objectives of the organization will be fulfilled at business level by undertaking the product design, creation and commercialization according to the initiative. They are also called business or stakeholders requirements.
|
|
|
|
|
|
Considerations about business initiatives:
|
|
|
|
... | ... | @@ -74,7 +76,7 @@ Considerations about business initiatives: |
|
|
|
|
|
##### Product initiatives
|
|
|
|
|
|
Product initiatives describe needs that the product aims to satisfy. They prescribe properties of the product.
|
|
|
Product initiatives describe needs that a 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.
|
|
|
>
|
... | ... | @@ -84,7 +86,7 @@ Product initiatives describe needs that the product aims to satisfy. They prescr |
|
|
|
|
|
##### 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.
|
|
|
Technical initiatives describe architectural needs and other technical related objectives 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
|
|
|
|
... | ... | @@ -98,17 +100,17 @@ This term is defined in the [Eclipse Foundation Specification Process](https://w |
|
|
|
|
|
## 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.
|
|
|
Initiatives are an essential step between the Program Plan, the code created by the Oniro projects 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.
|
|
|
This diagram explains such relation between Initiatives and other elements at Oniro.
|
|
|
|
|
|
![](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/raw/main/Oniro_elements_relation.png)
|
|
|
|
|
|
## Roadmapping Process stakeholders
|
|
|
## Oniro Platform Release Roadmap Process stakeholders
|
|
|
|
|
|
These are main stakeholders of this process:
|
|
|
These are the main stakeholders of this process:
|
|
|
* Submitter
|
|
|
* Roadmap team
|
|
|
* Roadmap Team
|
|
|
* Oniro WG SC
|
|
|
* Sponsor
|
|
|
* Owner
|
... | ... | @@ -125,22 +127,24 @@ A submitter must have an Eclipse Foundation account. This person can be the Owne |
|
|
|
|
|
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.
|
|
|
* 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.
|
|
|
These Roadmap Team members are appointed for a single Release cycle. Their participation can be renewed by the Oniro WG SC.
|
|
|
|
|
|
The roadmap team manages 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.
|
|
|
As mentioned, 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 Oniro Platform release Roadmap Process and appoints the corresponding members of the Roadmap Team, in this case, 3 members.
|
|
|
|
|
|
The Oniro WG SC approves the Roadmapping Process and appoints the corresponding members of the Roadmap Team, in this case, 3 members.
|
|
|
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.
|
|
|
|
|
|
### Sponsor
|
|
|
|
... | ... | @@ -161,11 +165,12 @@ In the case of individuals with no affiliation to any Oniro Members or related o |
|
|
|
|
|
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:
|
|
|
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 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.
|
|
|
* 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.
|
|
|
* Such a process will be elaborated and approved by the Roadmap Team and ratified by the Oniro WG SC.
|
|
|
|
|
|
## Process structure and workflow
|
|
|
|
... | ... | |