Welcoming new contributions, Favoring innovation
I have the great pleasure to announce one of the greatest changes for our community since the move from Launchpad to Github! At the end of the last year, I wrote you a little word about our vision for the future. In this letter, something was really important to me and to the whole board: Making things easier for people to contribute their work under the OCA umbrella.
The challenge was to find a way to do that without losing the great quality we have in our repositories and contributions. With this, any contributor can request for his work to be included under the OCA umbrella more easily and with less constraints than ever. Here is how we did it!
First of all, we’re moving toward smaller repositories that contain a set of modules that make sense all-together. You’ll be welcome to propose new repositories for your work and ask to be the maintainer of it (just drop a mail to: contribute AT odoo-community DOT org). The current repositories (with lots of modules in them) will continue to live for some time for the current code base and maintainers will be named at module level.
Then, maturity levels will be introduced at module level as well, allowing people to push their job earlier with less constraints and progressively bring them to a mature level. The more stable and mature a module gets, the more the OCA quality requirements will be strong to keep end user confidence in our work.
We believe this move will allow people to move the repositories and modules they currently host in their own repositories under the OCA umbrella to favor collaboration even more.
Our goals with those changes
Maintain a state-of-the-art quality over our work
Communicate clearly to end users on the quality level of each module, by providing clear information in the descriptions
Anyone having signed the CLA will be able to propose his work as alpha or beta levels in an easy manner
Benefit from OCA infrastructure (Runbot, CI, Pypi and Debian packaging,..) for all your work, even for alpha and beta levels
Bring more traction on your work with less constraints than you have onmature modules
Share your drafts and concepts at early stage and enjoy the leverage of the community
OCA Module Maturity Levels
Easier to publish your work early, giving you chances to create a community
The requirements to merge code into OCA projects depend on the module’s maturity level. The OCA uses the following maturity levels for the modules stored in the Github repository and published in PyPi platform:
-
Alpha: Unstable, for development or testing purpose
-
Beta: Pre-production quality but with potential instability
-
Production/Stable: suitable for production environment
-
Mature: In Production level since more than one version and actively maintained.
This is consistent with the terminology used on PyPi, and the allowed values are the same as the ones used by PyPi. A module maturity level is stored in the development_status key of the module’s manifest, __manifest__.py.
For better visibility of the development level, it will be highlighted in the module README file. To not put a bigger burden on the Contributor’s shoulders, the module README file can be automatically generated by a nightly script. It compiles all the separate RST fragments in a readme subdirectory, to create a single README.rst file, with the appropriate maturity level badge, along with all the OCA boilerplate info. You can see all the details in the module template. The module was used to showcase the resulting README.
Modules of all development status are hosted in the same repositories and branches, so you will find Beta modules alongside Stable ones: for this reason, you have to make sure to check the README or manifest before deciding to use a module in production environment. When no development_status is set in the manifest, Beta is assumed.
All modules, regardless of their development status, will be published on PyPi and on the Odoo AppStore.
A module’s development_status can be different for different versions. A “mature” or “stable” module in a version can start as “stable” or “beta” in the next branch, as a step towards maturity.
A document was prepared, explaining what each ‘development status’ means, what can be expected by users, and what are the requirements for modules to be assigned each maturity level. Follow the link below to get into all the details.
OCA Maintainer Role
One coordinator per module that rules its contributions
A Maintainer is responsible to ensure the coordination of specific addon modules in order to ensure the quality and consistency of the contributions. For a particular repository, this could be one, a few, or even all the modules in that repository.
Typically, the maintainer role for OCA repositories is expected to be done by the Project Steering Committee (PSC) members. Project Steering Committees are defined by the OCA Bylaws, section V.c), and from an Association perspective their main role is project oversight. A PSC can be responsible for one or more project repositories.
In large repositories it is sometimes difficult to identify who are the active maintainers of a given addon. This creates the following problems:
-
the maintainer does not easily notice PR and Issues concerning his/her addons;
-
when addons have no active maintainers, PSC members must take care of it, but they may be too busy or may not feel concerned by all addons in their repositories;
-
it is difficult for contributors to detect addons which have no active maintainer.
The maintainer role has been introduced to overcome the above issues.
Being the maintainer of an addon module will bring you the write access on it and will bear some responsibilities towards your contributors.