... | ... | @@ -12,6 +12,9 @@ |
|
|
</tr>
|
|
|
</table>
|
|
|
|
|
|
In our humble opinion, a good developer is not just someone who follows a programming workflow and writes high-quality code. A good developer knows how to deliver code for review and make the whole code review process effortless for the reviewer.
|
|
|
A good merge request should solve a specific task. We suggest not including more than one feature in one merge request. It would be much better if you created several merge requests instead.
|
|
|
|
|
|
|
|
|
## Merge Request Workflow Presentation ##
|
|
|
|
... | ... | @@ -74,8 +77,6 @@ The outcome of the review is in 2 parts: |
|
|
The 2 first levels will allow the contribution to be approved.
|
|
|
- A recommendation status : the reviewer provides the contributor with suggestions to enhance/improve his/her work for the current merge or in the future
|
|
|
|
|
|
We highly recommend to submit small granular contributions rather than large ones.
|
|
|
The goal is to make the review and integration loop as short as possible.
|
|
|
|
|
|
When preparing a contribution that is larger than average, the developer is responsible for warning the OAI team, so that the review work can start as early as possible and run in parallel to the contribution finalization. Failing to do so, there is a risk that the integration of his/her work remains on hold/under review for a longer time.
|
|
|
|
... | ... | |