Organization
How are we ruled?
Introduction
OCA is managed by Project Steering Committees (PSCs), comprised of committers elected within a specific OCA project community to provide oversight for the project for the OCA and to decide the release strategy for the project. PSC members are expected to act as individuals, making decisions for the best interest of the project when acting on PSC or development lists.
Each project's PSC is independent and responsible for a given scope, generally a bunch of projects/repositories on github hosting various Odoo modules/Apps. An example is the banking maintainers, reponsible for a set of project/Github repositories, each of them hosting various modules/Apps.
PSCs are free to set community and technical direction for their project, and are directly responsible for overseeing releases and the healthy development of their communities.
PSCs are responsible for ensuring their project follows certain core requirements set by the board, like following Legal, conventions, and Infrastructure related requirements, along with ensuring their community operates within the basic outline of the OCA Way.
PSC members nominate new contributors to the project, and PSC members cast votes on electing PSC members to the project. PSC members also have binding votes on any project matters.
Communication
PSC members should always be subscribed to their project's public list, and to at least the contributors@ list to be aware of the other collaboration and contributions. Virtually all PSC communication should happen on the project’s public list.
Ensuring that PSC discussions about the future of the project are held on the public lists ensures that all of the community - including non-members - can follow the discussion and comment on issues. While only PSC members have binding votes on project matters, healthy PSCs certainly work with the larger community of their project.
Merit
Ensuring that PSC members are helping to mentor helpful new contributors to their projects helps to ensure a healthy and growing project community.
PSCs are free to set the bar for merit within their projects, as long as decision making is done in a collaborative fashion as in the OCA Way. Healthy PSCs will regularly review contributions from non-committers - both specific code patches, bugs reported or commented on, or just helpful interaction on their project lists - to evaluate contributors as potential committers. PSCs are solely responsible for managing votes and granting commit privileges for new committers; however new PSC members elected must always signed the OCA CLA.
Merit within one PSC is not transferable to other PSCs; each project's committer list is independently managed by its own PSC. There are many PSCs who work closely with other PSCs, and have correspondingly large intersection in personnel; but the merit on each PSC is independent.
Although the plain sense of the word "committer" is "someone who can create new revisions in the source repository", the notion of "committership" is a social one—someone is a committer if they have been invited by the PSC to be a committer, and have accepted the invitation.
Community
While only PSC members have binding votes on project releases, in general PSC members participate equally with their project committers and contributors on the contributors@ list. PSC members can help to ensure a healthy and diverse project community by ensuring the project's mailing lists are welcoming newcomers and that community standards are promoted on its mailing lists.
While there are many projects with overlapping communities - and therefore some shared personal or technical relationships - fundamentally each project is its own community in terms of the bulk of project work.
PSCs are expected to report on the health and diversity of their project's community to the board. While there are no strict requirements on the makeup of PSC members (in terms of employment or affiliation of the individuals on the PSC), the board does expect PSCs to operate independently of outside commercial influence. PSCs that are unable or unwilling to ensure their actions are on behalf of the whole community - or act in ways targeted to specific commercial interests - will be contacted by the board and required to make corrections.
Project Management and Collaboration
The OCA projects are managed using a collaborative, consensus-based process. We do not have a hierarchical structure. Rather, different groups of contributors have different rights and responsibilities in the organization.
Since the appointed PSC have the power to create their own self-governing rules, there is no single vision on how PSCs should run a project and the communities they host.
At the same time, while there are some differences, there are a number of similarities shared by all the projects:
Communication
Communication is done via mailing lists. These identify "virtual meeting rooms" where conversations happen asynchronously, which is a general requirement for groups that are so geographically distributed to cover all time zones.
Some projects additionally use more synchronous messaging (for example, IRC or instant messaging). Voice communication is extremely rare, normally because of costs and the language barrier (speech is harder to understand than written text).
In general, asynchronous communication is much more important because it allows archives to be created and it's more tolerant on the volunteer nature of the various communities.
Documentation
Each project is responsible for its own project website (e.g. connector-magento), Github page (e.g. maintainer-tools) and Apps description on odoo Apps store and should comply with OCA Conventions and infrastructure services
Decision Making
Projects are normally auto governing and driven by the people who volunteer for the job. This is sometimes referred to as "do-ocracy" -- power of those who do. This functions well for most cases. When coordination is required, decisions are taken with a lazy consensus approach: a few positive votes with no negative vote is enough to get going.
Voting is done with numbers:
+1 -- a positive vote
0 -- abstain, have no opinion
-1 -- a negative vote
The rules require that a negative vote includes an alternative proposal or a detailed explanation of the reasons for the negative vote.
The community then tries to gather consensus on an alternative proposal that resolves the issue. In the great majority of cases, the concerns leading to the negative vote can be addressed.
This process is called "consensus gathering" and we consider it a very important indication of a healthy community.
You can learn more on the following Apache Fondation page: detailed voting rules.
Philosophy
While there is not an official list, these six principles have been cited as the core beliefs of philosophy behind the association, which is normally referred to as "The OCA Way":
collaborative software development
commercial-friendly standard license
consistently high quality software
respectful and honest interaction
faithful implementation of standards
All of the OCA projects share these principles.
Operation
All projects are composed of volunteers and nobody (not even members or officers) are paid directly by the association for their job. There are many examples of committers that are paid to work on the projects, but never by the association themselves, but rather by companies or institutions that use the software and want to enhance it or maintain it. The OCA may promote crowdfunding campaign made by contributors to finance some developments. In that case, the campaign will have clear objectives and the financed people will be known in advance.
Note that the OCA does contract out various services, including administratives tasks, accounting, press, media relations, and infrastructure.
Individuals compose the OCA
All of the OCA including the board, the other officers, the committers, and the members, are participating as individuals. That is one strength of the OCA, affiliations do not cloud the personal contributions.
Unless they specifically state otherwise, whatever they post on any mailing list is done as themselves. It is the individual point-of-view, wearing their personal hat and not as a mouthpiece for whatever company happens to be signing their paychecks right now.
All of those OCA people implicitly have multiple hats, especially the Board, the other officers, and the OCA representative. They sometimes need to talk about a matter of policy, so to avoid appearing to be expressing a personal opinion, they will state that they are talking in their special capacity. However, most of the time this is not necessary, personal opinions work well.
Role
Contributor
A contributor is anyone who wants to contribute (code, documentation, tests, ideas, anything!) to any OCA project hosted here at the Odoo Community Association (OCA). He's generally subscribed to the contributors@ mailing list. Note: if you are interested in contributing financially, please see the sponsorship program page.
PSC Member
A PSC member is someone that was elected due to merit for the evolution of the project and demonstration of commitment. They have write access to the code repository, the right to vote for the project-related decisions and the right to propose an active user for committership. The PSC as a whole is the entity that controls the project, nobody else. It is not required to be a member of the association to be part of a PSC.
OCA Representative
The OCA representative is appointed by the Board from the PSC Members. The PSC as a whole is the entity that controls and leads the project. The OCA Representative is the interface between the Board and the Project. OCA Representative have specific duties.