-
Notifications
You must be signed in to change notification settings - Fork 38
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Merge pull request #213 from eternoendless/update-people
Update people and roles, add working principles page
- Loading branch information
Showing
4 changed files
with
105 additions
and
58 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,40 @@ | ||
--- | ||
title: How we work | ||
--- | ||
|
||
# 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. | ||
|
||
{{< figure src="../images/council-org.png" caption="Councils' structure with example groups" >}} | ||
|
||
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. | ||
|
||
{{< figure src="../images/council-delegate.png" caption="Example of Council and delegate group" >}} | ||
|
||
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](https://community.apache.org/committers/lazyConsensus.html) 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! |
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters