|
|
# Oniro WG roadmap process
|
|
|
|
|
|
## Oniro Roadmapping Process
|
|
|
|
|
|
### xxxx
|
|
|
|
|
|
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.
|
|
|
* 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.
|
|
|
* 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, a group of people formed by:
|
|
|
|
|
|
## Requirements
|
|
|
|
|
|
### 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 different industries, requirements has 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.
|
|
|
|
|
|
Instead of requirements we will use the following words, until one of them sticks:
|
|
|
* Essentials
|
|
|
* Initiative
|
|
|
|
|
|
### Definition and relation with other items
|
|
|
|
|
|
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:
|
|
|
* It allows that different profiles define the following items in different _languages_ when needed:
|
|
|
* Specifications
|
|
|
* Requirements (essentials)
|
|
|
* Roadmap items: Epics, features, stories, tasks.
|
|
|
* Test Compatibility Kit
|
|
|
|
|
|
|
|
|
|
|
|
### Type of essentials
|
|
|
|
|
|
Types of requirement (essentials, scenarios)
|
|
|
* Business driven
|
|
|
* Product driven
|
|
|
* Technical driven
|
|
|
|
|
|
#### Business driven
|
|
|
|
|
|
#### Product driven
|
|
|
|
|
|
#### Technical driven
|
|
|
|
|
|
## Process actors
|
|
|
|
|
|
## Requirement Submitter
|
|
|
|
|
|
### 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.
|
|
|
|
|
|
To achieve such goals, the Roadmap Team is formed by two groups:
|
|
|
* 2 Committers appointed by the PMC
|
|
|
* 3 People appointed by the Oniro WG SC
|
|
|
* Support by EF, as usual, when needed.
|
|
|
|
|
|
The roadmap team does not manage the technical roadmaps. That correspond to each project and it is coordinated within the PMC, according to the Eclipse Project Handbook
|
|
|
|
|
|
### Oniro WG SC
|
|
|
|
|
|
The Oniro roadmap is owned by the Oniro WG. This roadmap is referred to the business and product initiatives and items. The technical elements are owned by the project committers, coordinated by the PMC.
|
|
|
|
|
|
The Oniro WG SC initiatives and items are approved by this governance body. It 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. It also defines the initiatives that should be part of each Oniro release.
|
|
|
|
|
|
The Oniro WG SC appoints 3 members of the Roadmap team.
|
|
|
|
|
|
## Process structure and workflow
|
|
|
|
|
|
### Wish list (change the name)
|
|
|
|
|
|
### Product and Release
|
|
|
|
|
|
|
|
|
|
|
|
# Oniro Platform roadmap
|
|
|
|
|
|
# Oniro specifications roadmap |
|
|
\ No newline at end of file |
|
|
the draft is being done [here](https://gitlab.eclipse.org/groups/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/-/wikis/home) |
|
|
\ No newline at end of file |