How we work

The project’s leadership is organized around project councils: self-organized, lightweight groups whose mission is to facilitate decision-making. Each council has authority over a defined domain.

• Technical Council – decides on technical subjects, including architecture and implementation choices.
• Product Council – decides on product management subjects, including what features belong in the project, specifications, UI/UX guidelines, and wordings.
• Quality Council – decides on quality assurance subjects, including quality processes, verification of pull requests, and bug triage.
• Leadership Council – oversees the other councils, decides on strategy matters and provides alignment.

Councils are not meant to pronounce themselves on every single tiny decision, but rather be summoned when an important decision needs to be made, then produce guidelines and recommendations for contributors to follow from that point on.

Councils are generally free to organize themselves independently as they see fit in order to perform efficiently. For example, a Council might grant day-to-day decisions to a delegate group, like maintainers currently do with committers for code review and merge. Another Council might choose to self-divide into working groups by expertise or project.

Membership to councils is invite-only, but not necessarily based on employer affiliation. Contributors may get invited in (or out) of councils mainly on the basis of trust, reputation, and engagement level. Depending on their skills, a person may be invited and sit in more than one Council at a time.

Each Council has a lead. Council leads are responsible for ensuring that the Council is effectively pronouncing on decisions, providing guidance for his or her council colleagues, and guaranteeing that subjects move forward coherently. For that, leads benefit from a power of veto and override over their own Council’s decisions – to be used sparingly, of course.

The Leadership Council is in charge of providing structure and a general direction for the project. To that end, it oversees the other Councils and has final authority over them and their decisions, including the right to appoint and remove leads. With great power comes great responsibility, and so its authority is to be exercised wisely.

For the time being, the project’s main sponsor, PrestaShop SA, reserves the right to appoint the Leadership Council’s lead.

Working principles

This organization delegates most of the decision-making to individuals that are expected to make decisions together. The key to Councils working efficiently is avoiding the committee’s trap, where the more members there are in a group, the harder and slower it is to reach a consensus and make a decision that satisfies everyone.

With that in mind, and inspired on the first principle of the agile manifesto, “individuals and interactions over processes and tools”, a small number of ground rules, or “working principles” have been set up:

• Admittance in a Council or delegate group is mainly based on good will, mutual trust, reputation, engagement, and convergence toward common goals. We work in small groups and we trust each other to work in the project’s best interest.
• We optimize for efficacy and not for thoroughness. We set up lean processes, only when such processes are a necessity. Not everything needs to be written in stone for an action to take place.
• We use lazy consensus to accelerate decision-making, notably by specifically stating short (but reasonable) timeframes for providing feedback on a proposal.
• We cherish the humility to ask when we don’t know, recognize when we are wrong, accept when we have made a mistake, learn from it, and improve.
• Less is more. We strive not to overthink things!