... | ... | @@ -13,9 +13,9 @@ Each initiative (requirement) will be owned by a person. Such a person could rep |
|
|
* 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.
|
|
|
|
|
|
## Requirements
|
|
|
## Nomenclature
|
|
|
|
|
|
### Nomenclature
|
|
|
### Initiatives (aka requirements)
|
|
|
|
|
|
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.
|
|
|
|
... | ... | @@ -23,17 +23,26 @@ In different industries, requirements have different connotations and implicatio |
|
|
|
|
|
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:
|
|
|
* Essentials
|
|
|
* Initiative
|
|
|
Instead of *requirements* we will use the word *initiative*.
|
|
|
|
|
|
### Definition and relation with other items
|
|
|
Initiatives is the name assigned to the artefacts that describe the Oniro Platform user needs that the Oniro WG and projects intend to address.
|
|
|
|
|
|
Definition of requirement (essentials, scenarios)
|
|
|
There are three types of initiatives based on their main origin and/or impact:
|
|
|
* Business driven
|
|
|
* Product driven
|
|
|
* Technical driven
|
|
|
|
|
|
#### Business driven
|
|
|
|
|
|
#### Product driven
|
|
|
|
|
|
#### Technical driven
|
|
|
|
|
|
|
|
|
### Roadmap item
|
|
|
|
|
|
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:
|
|
|
|
|
|
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
|
... | ... | @@ -41,21 +50,18 @@ Requirements (essentials, scenarios) are not roadmap elements. They justify and |
|
|
* Roadmap items: Epics, features, stories, tasks.
|
|
|
* Test Compatibility Kit
|
|
|
|
|
|
## Relation between initiatives, roadmap items and other elements
|
|
|
|
|
|
### Type of essentials
|
|
|
They constitute the relation between code and specifications. Initiatives justify and drive the creation, acceptance, auditing and validation of the roadmap items.
|
|
|
|
|
|
Types of requirement (essentials, scenarios):
|
|
|
* Business driven
|
|
|
* Product driven
|
|
|
* Technical driven
|
|
|
## Roadmapping Process actors
|
|
|
|
|
|
#### Business driven
|
|
|
|
|
|
#### Product driven
|
|
|
|
|
|
#### Technical driven
|
|
|
There are three main actors in this process:
|
|
|
* Submitter
|
|
|
* Roadmap team
|
|
|
* Oniro WG SC
|
|
|
|
|
|
## Process actors
|
|
|
There is a fourth actor, the committers/PMC members, which are represented within the Roadmap Team and the Oniro WG SC as described in this section.
|
|
|
|
|
|
### Initiative Submitter
|
|
|
|
... | ... | |