Contributors mailing list archives


Re: Proposal for new workflow, incorporating "Optimistic Merging"

Groupement Régional Alimentaire de Proximité, Sylvain LE GAL
- 07/06/2016 10:38:01
Hi all,

Interesting topic indeed !

Maxime Said :
>> I think we should first agree on where to install from.

Holger said :
>> And most of this proposal actually increases work load for existing reviewers.

Well, maybe we have to changes rules, specially to avoid to frustrate new contributors.

But we should define rules, depending on the repository. You'll find attachements, OCA statistics about number of commits by repositories. Maybe current rules are ok for "popular" repositories like "account-financial-tools" (~1700 commits) / bank-payment (~ 1550 commits), but should be changed for "not very frequented" repositories (vertical repositories (vertical-edition : 25 commits) and most of the localizations (l10-china : 5 commits).

Maybe we could define two categories.
- "1rst Class / League 1" repositories with current rules (or just adapted)
- "2nd class / League 2" repositories with more simple rules, (=more Optimistic).

To define this classification, we could be based on the number of (active) contributors too. (see attachments) Ex :

- account-financial-tools : > 100 contributors / ~ 20 active contributors -> league 1
- l10-france : > 20 contributors / ~ 5 active contributors -> league 2


Sylvain LE GAL - Twitter

GRAP - Service informatique (Groupement Régional Alimentaire de Proximité)
Site Web | Facebook
3 Grande rue des Feuillants, 69001 Lyon
Bureau : (+33) - Astreinte : (+33)
Member of the OCA (Odoo Community Association)

2016-06-07 8:38 GMT+02:00 Graeme Gellatly <>:

I had a look at the blog post but could find no link to any research.  It also seems to be largely focused in the patch space, rather than features.  Is there any actual research to link to?

That said, I'm all for it for "patches", bug fixes, documentation and "ports", not so much for new functionality and modules, simply because I feel that with the former even the brand new contributor is building on the shoulders of others.  It brings a little value to a lot of people and likely to be post-reviewed.  I think that's what you were getting at anyway.

A new module which naturally brings a lot of value to a few people initially I am not so sure would get the same attention when in fact it requires it.  I think there are potentially better ways for those.

On Mon, Jun 6, 2016 at 9:38 PM, Daniel Reis <> wrote:

Hello all,

Some discussion has been going on, to try to make OCA friendlier to new contributors.
Have a peek at:

The "Optimistic Merging" strategy that can make that possible:
Instead of requesting the contributor to have perfect code,
contributions are quickly merged so that others can improve them ("crowd patching").
This provides a more satisfying experience to contributors,
and provides some "low hanging fruit" for newcomers, such as simple code style fixes.

"Optimistic Merging" has some research backing it.
Learn more about it here:

Based on these ideas, I would like to draft a proposal.

The outline of the new OCA workflow would be like this:

1) Pull Request are made for a "beta" branch. E.g. "9.0-beta".
2) Pull Request has flash code review and a fast merge
3) Pull Request diff will still be available for further discussion/collaboration
4) Imperfect code merged is "crowd patched" until suitable for stable release
5) Pull Requests made for stable branch, e.g. "9.0", extracting relevant commits form the beta branch.
6) Full code review is made, and green CI required, as per current standards.
7) Fixes to the Pull Request for stable should then be also merged into the beta branch.

Some details:

Beta branches are initially branched from the stable ones.
Pull Requests should target beta branches.
These are merged with an Optimistic Merge policy.
Merging would be expected to happen fast,
and PR comments would mostly be for discussion, rather than validating the merge.
Rarely a PR should be blocked - it must be obviously toxic, or conflicting with other PRs.
MQT needs some adaptations to be useful in this scenario, but that's not a real issue, and is a separate discussion.

The beta branches are expected to have frequent improvements from multiple contributors.
They are not guaranteed to be correct nor API stable.
Module versions are not bumped.
People using code from it should be careful pinning Git revisions.

Module stable releases should be extracted from the beta branch and proposed to stable version branches.
Similarly to ports between major versions, this has its details in order to keep history.
It would usually be done by more experienced contributors, and we can have tools to make it easier.
Module versions should be bumped in the process.

Would to hear your comments and suggestions.

Best regards
Daniel Reis



Post to:

Post to: