... | ... | @@ -7,19 +7,18 @@ |
|
|
The roadmapping process defines how the elements that form the Oniro Platform roadmap are proposed, described, discussed, agreed, tracked, evolved, approved, deprecated...
|
|
|
|
|
|
The following considerations apply:
|
|
|
* A roadmap in an open environment needs to be kept clean for a variety of reasons:
|
|
|
* In an open environment a rodamap 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 particpation while keeping management and housekeeping needs under control.
|
|
|
* We are in 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 organization 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 kee the roadmap clean.
|
|
|
* The roadmap is owned by the Working Group, according to the Oniro WG Charter, that follows the Eclipse Working Groups Process.
|
|
|
* Given that WGs do not deal with technical matters, the ownership is limited to business and product related items.
|
|
|
* Technical content is owned by the projects. Coordination is required so committers should get involved.
|
|
|
* Given that operating systems and platforms are tightly coupled systems and that we are in early stages of the development process, a strong coordination is required among the following two groups: those behind the business/product elements of the roadmap and those behind the technical ones. This process contemplates such need.
|
|
|
* This coordination materializes within the Roadmap Team.
|
|
|
* This process will kick off as soon as it is approved by the Oniro WG SC, which will happen after Oniro Platform Initiatives for the Goofy release are approved. The process will start by governing the changes on Goofy's release roadmap.
|
|
|
* 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 commiters/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.
|
|
|
* 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.
|
|
|
|
|
|
![](https://gitlab.eclipse.org/eclipse-wg/oniro-wg/roadmap-oniro-wg/wishlist-roadmap/wishlist-repo/-/raw/main/oniro_roadmapping_process_infographic.png)
|
|
|
|
... | ... | @@ -317,3 +316,16 @@ Finally, filling in all necessary information in the form: |
|
|
![image](uploads/404f0bc2c58e98eb284b0e3bf6c7cf37/image.png)
|
|
|
|
|
|
Please also add meaningful title, like: "Support for 400k i2c in the ABC board", to ease further communication.
|
|
|
|
|
|
## 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 socialised among both, the WG and the projects. Feedback from the PMC, committers and particpants is essential.
|
|
|
|
|
|
This Oniro roadmapping process should to be compatible with Eclipse Foundation processes and practices.
|
|
|
|
|
|
Oniro acknowledge 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 to 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.
|
|
|
* 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 relase roadmap is created, around 2023Q1 |
|
|
\ No newline at end of file |