Contributors mailing list archives


Initiating into OCA workflow

Open Source Integrators, Daniel Reis
- 14/11/2015 20:17:23

It was not the point of the original thread, but I feel that it's worth discussing so I'm opening a new thread. This is not intended to be specifically for you, but for everyone else that might be confused on where to start to collaborate with the OCA.

> I've been working hard to understand the OCA flow so not so visible till now.

Probably I'm too inside OCA to see the difficulties.
Maybe that means that we need to hear closely newcomers, so bear with me:

OCA provides a collection of Git repositories: pick the branch you want, clone, use fork, whatever.
In the 9.0 branch modules from 8.0 not yet ported are there but not marked as installable.
That mentioned in the README, and once you learn about it, it's the same for all repos.
Any additional issues here?

To contribute you use exactly the same Git flow as all other GitHub project: fork, change, make a pull request, and go through a peer review.
Your code is required to follow Odoo official guidelines plus strict PEP8. Additionally the README and manifest files must follow some specific requirements. That's it.
TravisCI and reviewers will help you fixing what's not OK, so you're not expected to know everything.

I would say that the best way to learn about it is to go through a PR review process.
If you find something specific that could be improved, propose the change. People are receptive to improve what is not working.

> I am not at all focused on branch 9 but I have to work hard to not trip over it  in my explorations.
> On a basic level in one has to always be aware of the "toggling" to 9.0 now that it is default.  

OCA is no different from Odoo: 9.0 is the default branch, and you need to pick form the list if you want another one. Of course, remember to check if the module is already ported.

> When reading 8.0 documentation it is somewhat confounding.  
> (All good, GitHub Desktop is fine for documentation and I will get my Shell based "commit comment"
methods wired as well)

Commit messages are not a good documentation on what code does, they rather document why or how the code came to be like it is.
To sole documentation for OCA modules lies in their README files.
Developers authoring modules are seldom good at documentation, so PRs improving them are surely welcome.

As a final note, I recommend newcomers to first start by collaborating. You will certainly have people guiding you if something is not being done as it should. After understanding how it works, then suggest improvements on the processes.

I hope this is helpful!