... | @@ -4,28 +4,28 @@ |
... | @@ -4,28 +4,28 @@ |
|
|
|
|
|
The roadmapping process defines how the elements that form the Oniro Platform roadmap are proposed, described, discussed, agreed, tracked, evolved, approved, deprecated... considering the following:
|
|
The roadmapping process defines how the elements that form the Oniro Platform roadmap are proposed, described, discussed, agreed, tracked, evolved, approved, deprecated... considering the following:
|
|
* The roadmap is owned by the Working Group, in agreement with the Oniro WG Charter, that follows the Eclipse Working Groups Process.
|
|
* The roadmap is owned by the Working Group, in agreement with the Oniro WG Charter, that follows the Eclipse Working Groups Process.
|
|
* Given that WGs do not deal with technical matters, the ownership limits to business and product related items
|
|
* Given that WGs do not deal with technical matters, the ownership limits to business and product related items
|
|
* Projects own their technical roadmap. If coordination is required, it is the PMC's responsibility to do so.
|
|
* Projects own their technical roadmap. If coordination is required, it is the PMC's responsibility to do so.
|
|
* Given that operating system and platform is a tightly coupled system and we are in early stages of the development process, a strong coordination is required among the two groups, behind the business/product elements of the roadmap and those behind the technical ones. This process contemplates this.
|
|
* Given that operating system and platform is a tightly coupled system and we are in early stages of the development process, a strong coordination is required among the two groups, behind the business/product elements of the roadmap and those behind the technical ones. This process contemplates this.
|
|
* This coordination materializes within the roadmap team
|
|
* This coordination materializes within the roadmap team
|
|
|
|
|
|
Each initiative (requirement) will be owned by a person. Such person could represent one or several organizations.
|
|
Each initiative (requirement) will be owned by a person. Such a person could represent one or several organizations.
|
|
* The main reason for this is that initiative should always be able to be challenged in the future and the best way to do it is by knowing who is responsible for it.
|
|
* The main reason for this is that initiative should always be able to be challenged in the future and the best way to do it is by knowing who is responsible for it.
|
|
* In general, the initiative will be owned by the submitter. Additional people can be assigned as owners.
|
|
* In general, the initiative will be owned by the submitter. Additional people can be assigned as owners.
|
|
|
|
|
|
## Requirements
|
|
## Requirements
|
|
|
|
|
|
### Nomenclature
|
|
### Nomenclature
|
|
|
|
|
|
In a code first organization as well that in an Open Source development process, the word requirements has connotations that go against the culture that drives the decision processes and commonly accepted development practices.
|
|
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 has different connotations and implications too. When it comes to software products movements, the concept of requirements brings fundamental challenges too.
|
|
In different industries, requirements have different connotations and implications too. When it comes to software products movements, the concept of requirements brings fundamental challenges too.
|
|
|
|
|
|
For all these reasons, Oniro intends to avoid such concept, understanding that, at first, it will be hard to do.
|
|
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.
|
|
|
|
|
|
Instead of requirements we will use the following words, until one of them sticks:
|
|
Instead of *requirements* we will use the following words, until one of them sticks:
|
|
* Essentials
|
|
* Essentials
|
|
* Initiative
|
|
* Initiative
|
|
|
|
|
|
### Definition and relation with other items
|
|
### Definition and relation with other items
|
|
|
|
|
... | @@ -33,18 +33,19 @@ Definition of requirement (essentials, scenarios) |
... | @@ -33,18 +33,19 @@ Definition of requirement (essentials, scenarios) |
|
|
|
|
|
|
|
|
|
|
|
|
|
Requirements (essentials, scenarios) are not roadmap elements. They justify and drive the creation, acceptance, auditing and validation of those roadmap elements. They constitute the relation between code and specifications. In a code first organization, like Eclipse Foundation, it is wise that both, requirements (essentials) and roadmap elements are expressed in a user-centric way. Such approach has a variety of benefits:
|
|
Requirements (essentials, scenarios) are not roadmap elements. They justify and drive the creation, acceptance, auditing and validation of those roadmap elements. They constitute the relation between code and specifications. In a code first organization, like Eclipse Foundation, it is wise that both: requirements (essentials) and roadmap elements are expressed in a user-centric way. Such approach has a variety of benefits:
|
|
|
|
|
|
* It allows that different profiles define the following items in different _languages_ when needed:
|
|
* It allows that different profiles define the following items in different _languages_ when needed:
|
|
* Specifications
|
|
* Specifications
|
|
* Requirements (essentials)
|
|
* Requirements (essentials)
|
|
* Roadmap items: Epics, features, stories, tasks.
|
|
* Roadmap items: Epics, features, stories, tasks.
|
|
* Test Compatibility Kit
|
|
* Test Compatibility Kit
|
|
|
|
|
|
|
|
|
|
|
|
|
|
### Type of essentials
|
|
### Type of essentials
|
|
|
|
|
|
Types of requirement (essentials, scenarios)
|
|
Types of requirement (essentials, scenarios):
|
|
* Business driven
|
|
* Business driven
|
|
* Product driven
|
|
* Product driven
|
|
* Technical driven
|
|
* Technical driven
|
... | @@ -59,11 +60,13 @@ Types of requirement (essentials, scenarios) |
... | @@ -59,11 +60,13 @@ Types of requirement (essentials, scenarios) |
|
|
|
|
|
### Initiative Submitter
|
|
### Initiative Submitter
|
|
|
|
|
|
This is the person who submits an initiative. She might submit it in representation of one or more organizations.
|
|
This is the person who submits an initiative. They might submit it in representation of one or more organizations.
|
|
|
|
|
|
When that person leaves the Oniro project or no longer wants to own the inittiative it will be considered orphan and a new owner will be assigned through a call for ownership process.
|
|
When that person leaves the Oniro project, or no longer wants to own the initiative, it will be considered an orphan and a new owner will be assigned through a call for ownership process.
|
|
* Such process will be elaborated and approved by the roadmap team and ratified by the Oniro WG SC.
|
|
* Such process will be elaborated and approved by the roadmap team and ratified by the Oniro WG SC.
|
|
|
|
|
|
|
|
A submitter is supposed to be a registered member of the Eclipse Foundation.
|
|
|
|
|
|
### Roadmap team
|
|
### Roadmap team
|
|
|
|
|
|
The roadmap team has two main goals:
|
|
The roadmap team has two main goals:
|
... | @@ -82,7 +85,7 @@ The roadmap team does not manage the technical roadmaps. That correspond to each |
... | @@ -82,7 +85,7 @@ The roadmap team does not manage the technical roadmaps. That correspond to each |
|
## Process structure and workflow
|
|
## Process structure and workflow
|
|
|
|
|
|
Oniro Platform roadmap is structured in two different spaces:
|
|
Oniro Platform roadmap is structured in two different spaces:
|
|
* Space 1: this is the space where initiatives are submitted, matured and reviewed by the Oniro WG SC.
|
|
* Space 1: this is the space where initiatives are submitted, matured and reviewed by the Oniro roadmap team
|
|
* Space 2: this is the space where initiatives approved by the Oniro WG SC will be hosted.
|
|
* Space 2: this is the space where initiatives approved by the Oniro WG SC will be hosted.
|
|
|
|
|
|
### Space 1
|
|
### Space 1
|
... | @@ -97,4 +100,36 @@ Those initiatives that, for whatever reason, are not suitable for the evaluation |
... | @@ -97,4 +100,36 @@ Those initiatives that, for whatever reason, are not suitable for the evaluation |
|
|
|
|
|
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.
|
|
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.
|
|
|
|
|
|
|
|
## Templates provided
|
|
|
|
|
|
|
|
At the moment, we have 3 possible community message types to influence further extension and development. They are:
|
|
|
|
|
|
|
|
- feature requests
|
|
|
|
- enhancement requests
|
|
|
|
- general feedbacks
|
|
|
|
|
|
|
|
### Feature requests
|
|
|
|
|
|
|
|
These are clearly written descriptions for new features that the Oniro project could possibly develop. Those new gains might be related to some specific/missing features as well as to general optimizations, throughput boosts, new hardware ports, new operating systems supported, new architecture components integrated etc.
|
|
|
|
|
|
|
|
### Enhancement requests
|
|
|
|
|
|
|
|
These requests are related to *existing* features. The request should consider the context within which it is based on e.g. software version, hardware used, configuration used etc.
|
|
|
|
|
|
|
|
### General feedbacks
|
|
|
|
|
|
|
|
That communication channel is supposed to be used for any comments, feedbacks, that are related to the technical Oniro matters, however, they don't fit into two previous categories.
|
|
|
|
|
|
|
|
## Procedure
|
|
|
|
|
|
|
|
Any member of the Eclipse foundation is entitled to file any of above requests using [this](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/issues) interface. This is done by creating a new GitLab issue:
|
|
|
|
|
|
|
|
![image](uploads/e6e1a43c1818d6e48e2f0adbc1024df2/image.png)
|
|
|
|
|
|
|
|
Once a new issue's form popups up, one can select the request type:
|
|
|
|
|
|
|
|
![image](uploads/56e4455cd542f6a85a5ad2c52d661107/image.png)
|
|
|
|
|
|
|
|
Finally, filling all necessary information in the form:
|
|
|
|
|
|
|
|
![image](uploads/53b1087317dc5f6cc17311e9882495ee/image.png) |