... | ... | @@ -13,12 +13,15 @@ The following considerations apply: |
|
|
* 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 while, at the same time, promoting interaction with as many people as possible, affiliated to Oniro Members or not, being committers/participants of Oniro projects or not.
|
|
|
* 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 of the Oniro Platform roadmap correspond to the Oniro WG, as well as the management responsibility.
|
|
|
* Given that WGs do not deal with technical matters, the ownership is limited to business and product related topics. Technical topics are owned by the projects.
|
|
|
* 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 process, such coordination is even more important.
|
|
|
* This coordination materializes through the Roadmap Team, beyond the fact that Committers are represented at the Oniro WG Steering Committee.
|
|
|
* 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)
|
|
|
|
... | ... | @@ -26,24 +29,34 @@ Get the [.pdf version of the Oniro Roadmapping Process infographic](https://gitl |
|
|
|
|
|
## Terms and Definitions
|
|
|
|
|
|
### Initiatives (aka requirements)
|
|
|
### 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, 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. 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 too.
|
|
|
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.
|
|
|
|
|
|
For all these reasons, Oniro intends to avoid such a concept, understanding that, at first, it will be hard to do. The second, as a FOSS organization, we shall not impose any obligations stemming from wrongly used nomenclature.
|
|
|
#### Initiatives (aka requirements)
|
|
|
|
|
|
Instead of *requirements* we will use the word *initiative*. We are seeking a better word.
|
|
|
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 the artifacts that describe the Oniro Platform users' needs that the Oniro WG and projects intend to address. It is expressed in a templated form, using a use oriented language and managed on Gitlab through issues and, once approved, through Epics.
|
|
|
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
|
|
|
|
|
|
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.
|
|
|
|
... | ... | @@ -59,9 +72,9 @@ Considerations about business initiatives: |
|
|
>
|
|
|
> [Wikipedia](https://en.wikipedia.org/wiki/Business_requirements)
|
|
|
|
|
|
#### Product initiatives
|
|
|
##### Product initiatives
|
|
|
|
|
|
Product initiatives or requirements describe needs that the product aims to satisfy. They prescribe properties of the product.
|
|
|
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.
|
|
|
>
|
... | ... | @@ -69,33 +82,31 @@ Product initiatives or requirements describe needs that the product aims to sati |
|
|
>
|
|
|
> [Wikipedia](https://en.wikipedia.org/wiki/Business_requirements)
|
|
|
|
|
|
#### Technical/technology initiatives
|
|
|
##### Technical/technology initiatives
|
|
|
|
|
|
### Roadmap item
|
|
|
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.
|
|
|
|
|
|
We refer to roadmap item to:
|
|
|
* Initiatives that have been approved to be part of the current release process/cycle.
|
|
|
* Initiatives are managed at Working Group level and copied to the projects so the other roadmap items can be associated to them through Gitlab, so MRs.
|
|
|
* Initiatives are described (not decomposed) as user stories or engineering tasks and then decomposed in smaller actionable points if required.
|
|
|
* These elements are managed by using issues (gitlab terminology).
|
|
|
* They are managed at project level.
|
|
|
#### User Stories / engineering tasks
|
|
|
|
|
|
In a code first organization, like Eclipse Foundation, it is wise that both, initiatives (requirements) and items are expressed in a user-centric way. Such approach has a variety of benefits:
|
|
|
* It enables the definition of different elements like Specifications, initiatives, roadmap items or Test Compatibility Kit in different _languages and formats_ when needed.
|
|
|
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 initiatives, roadmap items and other elements
|
|
|
## 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.
|
|
|
|
|
|
They constitute the relation between code and specifications. Initiatives justify and drive the creation, acceptance, auditing and validation of the roadmap items.
|
|
|
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 actors in this process:
|
|
|
These are main stakeholders of this process:
|
|
|
* Submitter
|
|
|
* Roadmap team
|
|
|
* Oniro WG SC
|
... | ... | @@ -106,45 +117,45 @@ There are also others: the committers/PMC members, which are represented within |
|
|
|
|
|
### Initiative Submitter
|
|
|
|
|
|
This is a person who submits an initiative. They might submit it in representation of one or more organizations.
|
|
|
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 should have an Eclipse Foundation account. This person can be the Owner of the initiative.
|
|
|
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:
|
|
|
* Coordination between the Working Group and the projects under Oniro TLP project, around the roadmap.
|
|
|
* Management of the Oniro WG Roadmap.
|
|
|
* 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 is formed by two groups:
|
|
|
* 2 Committers appointed by the PMC
|
|
|
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, when needed.
|
|
|
* Support by EF, as usual.
|
|
|
|
|
|
The roadmap team does not manage the technical roadmap at project level. That corresponds to each project and it is coordinated within the PMC, according to the Eclipse Project Handbook. The roadmap team manages the roadmap at Oniro WG level.
|
|
|
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 the convenience and impact of each initiative on the overall product.
|
|
|
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 appoints 3 members of the Roadmap team.
|
|
|
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 or individual, like a community member, that supports the initiative in all of the following ways:
|
|
|
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 an initiative to be part of the Oniro release, it requires a sponsor. Members will assume the sponsor role for initiatives proposed by community members. The Oniro WG SC will determine the capacity/costs assigned to this purpose.
|
|
|
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 leaves or no longer assumes the expected commitments diligently, a similar process to the one described below for the Owner role will be executed.
|
|
|
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 Oniro Members or related organizations, the sponsor can be the owner. This would be the case for community driven contributions that end up being part of the coming release.
|
|
|
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
|
|
|
|
... | ... | @@ -159,10 +170,10 @@ When the owner leaves the Oniro project, no longer wants to hold such responsibi |
|
|
## Process structure and workflow
|
|
|
|
|
|
Oniro Platform roadmap is structured in two different phases:
|
|
|
* Phase 1: creation. This is the phase where initiatives are submitted, matured, reviewed and approved to become part of the Oniro Platform roadmap
|
|
|
* 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.
|
|
|
|
|
|
### Creation phase
|
|
|
### Qualification phase
|
|
|
|
|
|
#### Description
|
|
|
|
... | ... | @@ -174,7 +185,7 @@ Those initiatives that, for whatever reason, are not suitable for the evaluation |
|
|
|
|
|
#### Stages
|
|
|
|
|
|
The stages of the Roadmapping Process at the creation phase are:
|
|
|
The stages of the Roadmapping Process at the qualification phase are:
|
|
|
* Initiative.Proposal
|
|
|
* Initiative.Evaluation
|
|
|
* Initiative.Description
|
... | ... | @@ -212,7 +223,7 @@ You can see a representation of the different stages in this board: [Process Sta |
|
|
|
|
|
##### Sandbox
|
|
|
|
|
|
* If the evaluation is not successful, then the initiative remains in the creation phase.
|
|
|
* If the evaluation is not successful, then the initiative remains in the qualification phase.
|
|
|
* Initiatives at this stage are living items which can and should be updated/supplemented.
|
|
|
* The initiative can be submitted again at any time by the Submitter or any other person.
|
|
|
|
... | ... | @@ -230,11 +241,11 @@ The stages of the Roadmapping Process at the Roadmap phase are: |
|
|
|
|
|
##### Roadmap.Communication
|
|
|
|
|
|
* The initiative is adapted and promoted to become part of the Oniro Platform Release Roadmap.
|
|
|
* The issue is moved from the initiative-creation repository by promoting it (Gitlab terminology) as Epic to the subgroup initiative-release-roadmap.
|
|
|
* 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 Onbiro WG SC.
|
|
|
* 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.Backlog
|
|
|
|
... | ... | @@ -248,19 +259,26 @@ This table reflects the cadence or cycles related with each one of the stages an |
|
|
| Event | Cadence | Purpose | 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 comming from the community |
|
|
|
| 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. |
|
|
|
|
|
|
## Process management
|
|
|
## Roadmapping 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.
|
|
|
|
|
|
## Process management and implementation
|
|
|
|
|
|
### Process Management
|
|
|
|
|
|
We will manage the process relaying on the following elements:
|
|
|
* Roadmap Team as the main group of people that will take care of the process. This has been described above.
|
|
|
* Dashboards to manage the different elements
|
|
|
* Repositories/subgroups
|
|
|
|
|
|
|
|
|
### Dashboards
|
|
|
#### Dashboards
|
|
|
|
|
|
The key dashboards are the following:
|
|
|
* [Process phase](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/boards/1375): visualization of the different stages where the initiatives are.
|
... | ... | @@ -268,7 +286,7 @@ The key dashboards are the following: |
|
|
* [Priority](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/boards/1374): dashboard that reflects which are the most important initiatives that are currently in associated to the process
|
|
|
* [Initiative type](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/boards/1376): categorization of the initiatives based on its type.
|
|
|
|
|
|
### Repositories/subgroups
|
|
|
#### Repositories/subgroups
|
|
|
|
|
|
The following diagram describes the different repositories and their relation:
|
|
|
|
... | ... | @@ -279,6 +297,8 @@ The roadmapping process takes place in three different places: |
|
|
* initiative-release: under the Oniro Working Group Gitlab, this subgroup is where the approved initiatives are stored. The goal is to keep this subgroup clean of epics that are not part of the release so our roadmap can be visualized and explained to people with different profiles and backgrounds.
|
|
|
* engineering-roadmap: under the oniro-core project, this subgroup is where the epics are described as user stories and engineering tasks in order to execute them.
|
|
|
|
|
|
|
|
|
|
|
|
## Community Initiative types
|
|
|
|
|
|
To support further growth and expansion of Oniro, we provide a web-based communication interface to facilitate that endeavor (see it [here](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/issues)). We strongly believe that it is the community that is going to make this project unique and long-lived.
|
... | ... | @@ -323,16 +343,16 @@ Please also add a meaningful title, like: "Support for 400k i2c in the ABC board |
|
|
|
|
|
## Oniro Roadmapping Process approval and implementation
|
|
|
|
|
|
This Roadmapping process should 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 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 should be compatible with Eclipse Foundation processes and practices.
|
|
|
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 pooint have to be compatible with existing EF ByLaws, processes and practices.
|
|
|
* 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
|
|
|
* 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
|
|
|
|
... | ... | |