OCA’s
work spans countries, industries, business functions, and apps and
modules.
To support our members OCA has a
robust framework for managing and coordinating work across all these areas. This
framework is based on Project Teams, each coordinated by a Project Steering
Committee.
There are currently five types of Project (PSC) Teams:
-
Functional Teams (accounting, marketing...)
-
Vertical Interest Teams (hotel, construction, medical...)
-
Localization Teams (by country)
-
Connector Teams (integrate Odoo with other software)
-
Community Tools Teams (providing support to members, e.g. Backport, OpenUpgrade, admin)
How do Project Teams work?
Project teams are made up of contributors, PSC Members and a PSC representative.
Contributor
A contributor is anyone who wants to contribute (code, documentation, tests, ideas, anything!) to any OCA project hosted on the OCA site. We encourage all contributors to be members of OCA. Find out how to join as a contributor.
PSA-OCA Representative
An OCA Representative is appointed by the board from PSC Members. The OCA Representative is the interface between the Board and the project.
PSC (Project Steering Committee) Members
PSC Members are elected by the Project Team to form the Project Steering Committee. PSCs provide oversight for each project on behalf of the OCA. Members of the PSC are elected from all of the members of the project team.
A PSC Member has write access to the code repository, the right to vote for project-related decisions and the right to propose an active user for committeeship. The PSC as a whole is the entity that controls the project. You do not need to be a member of the OCA to be part of a PSC, although it is encouraged.
What is the role of PSCs?
PSC members are expected to act as individuals, making decisions in 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 group of projects/repositories on Github, hosting various Odoo modules/Apps. For example, banking maintainers, responsible 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. For example: 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
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.
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.
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.
Merit
Ensuring that PSC members are mentoring 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.
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 PSCs 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:
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" - the power of those who do. This functions well in 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 this process from the Apache Foundation.
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.
We also have a set of by-laws governing the OCA – you can see them here