Decision making

From OTBWiki
Jump to: navigation, search

During our first IRC PSC meeting, the PSC decided to update the decision making process, by distinguishing between Request For Comments (what is intended) and Request For Changes (what has been done and is ready to merge). The current workflow is therefore the following:

 Request for Comments -> Comments and discussions -> Developments -> Requests for changes -> Review -> Vote -> Requests for Merge -> approval by Release Manager -> Merge

Release manager

A release manager is nominated for each release. Nomination is made shortly after previous release announcement. A backup release manager is also nominated, to assist and possibly step in if the official release manager is not available. The release manager and his/her backup can be a member of the PSC, but also another member of otb-developers list willing to take the spot.

The release manager is in charge of :

  1. Listing and tracking all major features proposed for next release (from call for contribution in the early phase and then approved RFCs)
  2. Planing release date and ensures sync with RFCs execution,
  3. Approving feature branch merges (if possible, leave at least 3 days between RFC submission and merge, so that people have time to do a review)
  4. Actually merging feature branches when authors do not have commit rights (github pull request for instance)
  5. Tracking remote module that can be candidate for official inclusion in next release, and ensuring they will be included (see Contributors guidelines)
  6. Submitting the start of the release process to PSC vote
  7. Ensuring proper execution of release process

Feature freeze: Starting the release process is also called feature freeze which describes the period between the creation of the release branch and the announcement of the release. It's an important time for the RM who should ensures the proper execution of the release process and facilitate the communication between developers. The RM is among other things responsible of gathering feedback on bugs that need to be fixed before the release, making a list that is public to be able to follow progression of the release process.

Remember: all new features must be submitted by RFCs and approved by PSC. Release manager only approves the feature branches merge.

Request for Comments

A Request for Comments can be submitted by anyone, at anytime, on otb-developers mailing list (topic should start with [Request for Comments]). Its purpose is twofold:

  • Publicly announce intention to develop some new features or changes in order to increase openness of the project and coordination between developers,
  • Gather feedback and comments to assess acceptation by the community and build a stronger development plan based on its feedback (caveats, best way to do it, things not to forget, etc.)

Request for Comments are only proposed ideas, they are therefore not voted by the PSC (but the PSC is encouraged to give its opinion so as to help the author). However, anyone can express her support to Request for Comments, which will help both the author and the PSC to assess acceptation and popularity of the proposed feature.

Authors are encouraged to create a wiki page corresponding to their Request for Comments here, following this template. They should try to track comments, endorsements and feedbacks in this page.

Development should start anytime, but it is advised to wait for discussion to end so as to know if the change can be accepted in the future and how it should be best done.

Requests for Comments are not mandatory, but they will help the community to get the big picture (a Request for Comments can cover several Request for Changes) and ensure that the proposed change can get accepted.

Request for Changes

A Request for Changes describes a precise set of changes that have been made to the source code:

  • General purpose of the changes,
  • Architecture insight (how are classes affected by the changes supposed to interact),
  • Classes added or modified,
  • Tests added,
  • CMake scripts modifications,
  • ...

A Request for Change can be submitted by anyone, at anytime, on otb-developers (topic should start with [Request for Changes]). Authors should also create a wiki entry corresponding to their Request for Changes here, following this template.

Requests for Changes can refer to a former Request for Comments to explain what role it plays in a bigger picture. A Request for changes can indeed correspond to a part of a Request for Comments. It is not mandatory that a former Request for Comments exists, but it will most certainly help.

A Request for Changes refers to existing changesets, either on a feature branch or in a pull request.

A Request for Changes needs to be approved by a PSC vote, following voting rules. The purpose of the vote is to validate that the content in the set of changes is in line with project directions. A code review might be performed during the process.

The list of all Request for Changes is available here.

Request for Merge

Once a Request for Change has been formally approved by PSC, the author can issue a Request for Merge to the current release manager, by sending a mail (topic should start with [Request for Merge]), according to the release planning process.

Note that the Release Manager does not evaluate the content of the changesets themselves (this is the purpose of the PSC vote), she only decides if a merge in develop branch is possible according to the merge acceptance checklist.

There is no need for tracking Request for merge on the wiki, everything will therefore be decided on otb-developers.

Feature branch merge acceptance checklist

  1. The feature branch corresponds to an approved RFC
  2. The feature branch is synched with develop
  3. The feature branch is tested on the dashboard (see here) and has no major failure (compilation errors, tremendous amount of warning or failing tests, segfault or not executed tests)
  4. Feature branch author are available during days following the merge to analyse dashboard and fix things in case of unexpected issues after the merge

It is important to note that a feature branch should be kept relatively small and does not necessarily correspond to the full implementation of a RFC. Small consistent branches implementing parts of RFC can be merged early. Further evolutions and implementations of the RFC can be done by continuing the feature branch or opening new branches, and approval of Release Manager should be requested again before merging.

Remote branch deletion

After a feature branch is merged it should be considered "finished" and will be deleted from the remote server. We can of course make exceptions to this if the RFC author asks.