-
Notifications
You must be signed in to change notification settings - Fork 53
Way of Working
This page describes the overall process for OpenCSD project that
covers all the major aspects of the project life. Changes to this
document are also expected to be done using the process described on
this page.
This project is a community project that is initially bootstrapped by a team of engineers and people supporting those sponsored by Linaro and Linaro member companies during the first two phases of the project.
During the third and any further phases it would be a community project with a community governance model that is decided to be suitable for the project.
The project consists of three phases outlined in the subsections below. Currently project is at the first phase.
During this phase the project team resembles a traditional development team that consists of the engineers assigned by participating companies, which is working according to a prioritized backlog.
The governing body for the project is the project board, which is comprised of technical management representatives from all the participating boards (project sponsors).
The priorities for backlog items are set by the project board. As team members are reporting to their respective managers, who in turn have authorized the project manager to lead this project, the direction and pace of the project is determined by the joint decisions of the project manager and the project board.
Changes for the process can be proposed by any participant of the project and are reviewed and approved by the project board.
As during this phase the codebase is being created, rules for change review are less strict comparing to the later phases. Each project engineer is working on his/her own branch on Project's GitHub repository. Changes are developed by each engineer and committed to their respective branches, one functional change at a time. Ideally, any change in git revision log should be compilable, runnable and bringing no regressions for the code it's based on.
Bootstrapping phase continues until:
- at least one of the engineers, participating in the project, volunteers for the maintainership of the product being developed (multiple volunteering co-maintainers also qualify in this case);
and at the same time at least one of the conditions listed below is met:
- the project team implements the initial set of features as defined by the project board;
- project gets at least two active external participants on top of the project team as defined by the participating member companies and Linaro.
The change of phase for the project is requested by any of the project participants and is approved by the project board. Transitioning to the next phase is done right after the project team makes a release of the code developed during this phase. During the transition between the phases an official public announcement about switching over to the community phase is published to the project’s mailing lists as well as wiki site. Same announcement also names the maintainer(s) of the community project.
In the beginning of this phase the development team starts transforming itself into a group of self-driven engineers independent from each other, who are working on such aspects and features of the product that are deemed feasible by them (or their employers/sponsors represented by them).
During this phase decisions about inclusion of the code produced by the community members into the project codebase are made by the maintainer (or multiple co-maintainers) based on their personal vision and understanding of the community needs. All the governance that was set up for the bootstrapping phase is dismissed and project is switching to a “maintainer within community” governance model. Member companies become community members in this phase. They keep influencing the direction of the project’s development by providing resources for the project and communicating their needs to project maintainer(s).
During this phase the process is starting to be closer to the final, community friendly process, which is defined by the project maintainer(s) with help of Linaro people with relevant experience. Changes to the process can be proposed by anyone related to the project. Such changes are not approved by the project board anymore. Those are reviewed and accepted by the project maintainer(s) instead.
During this phase code changes are proposed by project participants and reviewed using GitHub's pull request funtionality. It's up to project maintainer(s) to decide whether a particular change is a good addition into the codebase, whether it is formatted properly, corresponds to the coding guidelines for the project, etc. As a final step of review a pull request gets accepted or cancelled, with comments resulting from a completed review describing the changes needed to get it accepted.
This phase’s duration is one release cycle. The formal project is deemed completed as soon as the project team makes a release of the code developed during this phase. Linaro will continue providing the infrastructure support, including keeping CI loop running for as long as required, relevant and possible.
Details of this phase and all the further phases of the project are to be defined by the maintainer(s) of the project together with the community.
Traditionally community projects are governed by a governing body, which is ranging from a single person (maintainer) for a small projects to an elected project board for large projects. This project is proposed ot be governed by its maintainer(s) based on the consensus within the community (if that can be reached in reasonable amount of time). The feasibility of the engineering decisions is to be verified based on the actual code (be that a prototype level of quality or a final one). The proverbial "talk is cheap, show me the code" describes the approach quite well.
Community consists of independent engineers as well as engineers working for some companies (and representing those), the overall goal for the project is to satisfy all the reasonable requirements of the community. As requirements can be mutually contradictory and consensus would not be reachable in such a case, the ultimate decision making authority for the project is its maintainer (or a group of maintainers).
This will definitely be revised later, perhaps during the second phase of the project.
Same as above.
Same as above.
All the project artifacts are owned by their authors and are licensed under the BSD 3Clause license. No copyright assignment is required for the contributions into this project.