These are our core values, as voted by the maintainers, in order of importance. When in doubt, these should guide our decisions.
-
Deliberate Inclusivity
We take the time to include all good-faith contributors. The project works around the lives of real people, and people shouldn’t sacrifice a reasonable livelihood to participate.
-
Intellectual Safety
We work to cultivate and maintain an environment where participants feel comfortable sharing ideas and opinions without fear of harsh judgments or repercussions. We practice blameless analyses of our missteps.
-
Transparency
We make our governance public whenever reasonable. By doing this, we are able to create a shared and sharable understanding of what we're trying to do.
-
Accountability
People need a channel for safely communicating feedback to other maintainers.
-
Shipping
We constantly strive to improve through iteration. Some ships will sink, so we build processes to accommodate expected failures as a safety net.
-
Sharing
We seek to share knowledge of the project between maintainers. We share responsibilities and seek to meet objectives as a team.
- A maintainer is anyone who plays an active role in governance.
- A collaborator is active in the community, but not in governance.
- A participant is anyone who is a maintainer or collaborator.
- A Working Group is a group of maintainers that is formed to take responsibility for certain aspects of the Electron project. Normally these groups will meet regularly but in some cases will only meet as required to fulfill their responsibilities.
- A chair is the acting leader of a Working Group that uses the Rotating Chair Model.
- A delegate is a chosen representative of a Working Group.
| Working Group | Repo | Description |
|---|---|---|
| Administrative | wg-administrative | Administrates Governance |
| Community | wg-community-safety | Handles Code of Conduct issues |
| Ecosystem | wg-ecosystem | Makes Electron app development easier |
| Outreach | wg-outreach | Grows the community |
| Releases | wg-releases | Coordinates new releases |
| Security | wg-security | Security review & response |
| Upgrades | wg-upgrades | Ongoing Node & Chromium upgrades |
| API | wg-api | API design |
All Working Groups have these core responsibilities:
- They shall decide for themselves, and publicly post, their rules, e.g. how decisions are made, when meetings are held, and who may attend.
- They shall choose a model of work to support reaching the Working Group's goals.
- They shall keep meeting notes, including agenda items, discussion points, and outcomes for everyone to review.
- They shall be collaborative and work in good faith with other Working Groups.
Group members live and work in many timezones, so synchronous meetings aren't always possible. No one should feel like they need to attend a meeting at an inconvenient time for their voice to be heard. If a group is to make a decision by voting, it shall make a reasonable effort to inform all members about the vote and give them a chance to vote outside of the meeting itself.
Working Groups with members across diverse timezones should make an effort to include all members in decisions, votes, and meetings. Such Working Groups may consider using third-party tools for this purpose, like coordinating meeting times that work for members in different timezones.
Members should have the opportunity to read a summary of the meeting and share pertinent opinions before voting is finalized.
Delegates have responsibilities to their Working Group: they represent the collective will of that group to others.
Delegates are chosen by the members of their Working Group, either when the need for one arises or for a short period of time not longer than four weeks when a delegate may be needed multiple times in rapid succession.
If an issue affects only one Working Group, that group can make decisions on its own.
If an issue affects more than one Working Group, those groups are encouraged to work towards agreement together.
If agreement cannot be reached, delegates from all involved Working Groups must try to decide the matter with a vote. A reasonable effort must be made to let all interested Working Groups participate in this, but any Working Group may choose abstain.
If agreement still cannot be reached, the issue may be brought to the Administrative Working Group which has final say.
Regardless of how agreement is reached, the participating groups must make a reasonable effort to record and post their decisions for transparency.
The Electorate is the body who holds the ability to alter the charter and appoint members of the Administrative Working Group.
The Electorate should try to balance several factors in its composition of members:
- new contributors
- long-time contributors
- corporate sponsorship
- financial contributions
- tenured contributions
Initially, the Electorate was GitHub. Designing a new Electorate is still out-of-scope for this charter. Instead, we will make the implicit status-quo explicit: the Administrative Working Group is comprised of managers from Microsoft and Slack.
There is no explicit timeline around designing a better electorate, but this charter expects it to be addressed in a reasonable timeframe.
See the Working Group README
The Administrative Working Group (AWG) is chartered with the responsibility to ensure governance is serving the best needs of the project and community. The AWG has authority to act on the project, granted by the electorate. The AWG in turn delegates its authority to all other Working Groups.
To prevent the AWG from becoming the sole political power of the project, it is expected that the AWG abstains from casting individual technical decisions that are the responsibility of other Working Groups. The AWG should principally serve as a circuit breaker. If a delegate Working Group is failing to meet its responsibilities, the AWG may intervene up to and including altering group members, or altering the groups authority, responsibilities, or existence.
Authors note: The current Electorate/AWG mix places almost all the power in the hands of a few large corporations at the outset. While not ideal to many, this was chosen because it represents the present status-quo, as of writing. The choice to delay defining an Electorate was made to ensure it was not rushed, and that we have time to balance project stakeholders large and small.
Occasionally, Electron maintainers will become inactive, or must step down from the project for personal or professional reasons. When this happens, it is important to reduce the risk to the project of compromised accounts with administrative permissions. This is not intended as a judgement on any individual member, simply a risk mitigation strategy for the project as a whole.
If a maintainer no longer wishes to be a part of a working group, they should let the working group know via Slack or by submitting a PR removing themselves from the working group in governance. If a maintainer becomes inactive, the working group may choose to vote the member out via their own process - this process will be defined by each individual working group.
For the safety and security of the project, all maintainers who have been offboarded from all working groups will be removed from GitHub member status and GSuite. They may also be moved to a multi-channel guest in the maintainer Slack.
When a former maintainer is offboarded, they will be automatically moved to Emeritus status within the governance repo. There is no minimum required period of serving as a working group member for this status - any working group member who served for any length of time, but is no longer part of the working group, is eligible.