thegridprotocol/docs/governing-body.md

182 lines
10 KiB
Markdown
Raw Permalink Blame History

This file contains ambiguous Unicode characters!

This file contains ambiguous Unicode characters that may be confused with others in your current locale. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to highlight these characters.

# Governing Body
## Scope
This document will outline the high level concepts and guidance principles of the governing body of The Grid that will
be used for the articles of constitution.
This document will NOT go into details of how day-to-day management will happen, which will be left to the discretion
of the Governing Body.
## Legal entity
The Governing Body will be a non-profit organisation, funded in Luxembourg, as an Association sans but lucratif by Max
Dor (author of this document), Daily Manager of Kamax Sarl, and two other people (TBC, people that are known personally,
but not necessarily technical), as legally required.
Non-profit status will ensure that all activities and incomes must be legally targeted to fulfil the missions of the
non-profit without being subdued by making a profit for its shareholders, as opposed to a for-profit which its sole
purpose is to make profit and distribute it to its shareholders.
Non-profit gives a better framework for donations or voluntary work, without the need for extensive accounting or legal
requirements overall, giving much more freedom in the day-to-day running of the organisation and helps keeping management
costs to a minimum, which would otherwise add up to several thousands Euro per year.
The legal entity will be used to centralize ownership of various protocol IP materials, like Internet domains, trademarks,
logos. The source code of any tools built by or on request of the legal entity will remain the IP of their respective owners.
## Missions
The Governing Body will have the following missions:
### Regular protocol specification releases
A protocol is only defined by its specification, and its delivery in a clear, comprehensive, validated and usable format
by the widest technical audience is the most important mission.
The Governing Body exists in fine for the sole purpose of this deliverable and should be judged on it.
### Provide adequate environment, tools and hosting
The Governing Body will provide:
- A documented vision for the protocol
- What is reasonably necessary for its boards to fulfill their responsibilities
- What is reasonably expected from the community about such entity with a similar mission
- End-users software, tools and services to showcase the protocol usage and goals
- Development software, tools, documentation and services to ensure independent implementations are possible and straightforward, following [BCP 9](https://datatracker.ietf.org/doc/rfc6410/?include_text=1).
- Means and services to discuss, exchange, and learn about the protocol
- Guidelines and processes for protocol changes and community contributions, ensuring these are always welcoming,
as easy as possible, and as rewarding as possible.
### Community management
Ensure:
- A Community Manager which will always be available and reachable
- The community is proactively kept up to date of changes and achievements
- Officially-managed places are properly and timely moderated
- Feedback from The Community, however bad or good, is always taken into consideration
### Protocol fostering
Proactively engage into activities to:
- Make the protocol known by as many people as possible (website, social medias, conferences, etc.)
- Convince end-users to use the protocol (demos, webcast, etc.)
- Convince developers to build on the protocol
- Grow the community at large
## Funding
The Governing Body should only be founded on donations from the community. This will be a critical dynamic for this
project, as it will ensure the community has a clear and straightforward way to show its support and general agreement
with how well the Governing Body is doing.
All donations will be listed and made public. Donors that have made a donation with significant amount (> X€ over X months)
must be publicly disclosed as they can use it as leverage to achieve their own goals. Donations MUST NOT be conditional
to any delivery, service or related item. Donations MUST be without any string attached.
While sponsoring is occasionally acceptable, full disclosure about the transaction, including the contract, MUST be
publicly disclosed. Contracts that conflict with this full public disclosure clause MUST be refused. Signatures, emails,
contact numbers will be removed before public disclosure.
Sales of goods and services are acceptable, as long as:
- They are legally acceptable for the non-profit
- The majority of income is not tied to a minority of customers
- Do not interfere or take priority in any way with the missions and responsibility of the Governing Body outlined in this document
The Governing Body will give full disclosure about incomes on a regular basis (TBD, quarterly?), so it can be audited by the community at large.
## Financing
The Governing Body will be allowed to use its funds to:
- Pay a regular salary to management board members
- Give financial compensation to technical board members, after approval from management board and technical lead, to
ensure they can afford dedicated time and give an incentive to remain a member
- Pay for the various fundamental technical services (Domains, web hosting, etc.)
- Finance trips and related expense to social events which are relevant for the boards missions (e.g. FOSDEM stand)
- Finance individual missions with independent contractors/orgs that may have dedicated knowledge into one area, to further
progress the protocol (e.g. a security/crypto consultant for end-to-end encryption, or security audit)
The Governing Body WILL NOT be allowed to provide funds to any entity listed as an employer or of significant involvement
with any of the boards members. This will ensure no board member will have an incentive to redirect the Governing Body
money for its own profit.
The Governing Body will give full disclosure about spending on a regular basis (TBD, quarterly?), so it can be audited
by the community at large.
## Leadership
The leadership of the non-profit will be divided into two boards:
- Management board
- Technical board
Membership of those boards are not mutually exclusive, and one person can be a member of both. Each board will have
specific, non-overlapping responsibilities.
We recognize and even value that no one can be 100% neutral and therefore might try to push their own agenda, even if
unconsciously. We see this as a driving force as members would have a reason and a motivation to be there and is not a
negative thing on its own.
As a user, developer, sysadmin, member or donator, it is very important to be able to make an informed decision about
whether one should continue contributing in its own way to the project. This starts by knowing who the people in charge
are, what allegiance they might have and the laws they are bound to.
Therefore, every member of each board must disclose the following on public record:
* Name (not necessarily full legal name, but not an obscure nickname either, like “l33t1337”)
* Employment status with position and employer if applicable
* Significant (paid and/or with decision making level) involvements in other organisations of any kind
* Country of legal residence
Members will be listed on the main website of the protocol project page, along with the latest up to date information.
### Management board
This board will be made from members of the legal entity and will take on the following responsibilities:
- Management of the non-profit legal entity
- Accounting
- Finances
- Promotion of The Grid
- Ensure the governing bodys missions are fulfilled
- Functional (high-level, non-technical) steering of the protocol
- Community management
Eligibility:
- Legal member of the non-profit
Membership starts:
- By vote of all current board members
Membership ends if either of the following occurs:
- Of their own will, at any time
- By vote of all other board members
### Technical Board
This board will be made of people who have written implementations of the protocol and thus can have an informed,
knowledgeable and authoritative view about the technical choices to be made and decisions to be taken.
This boards members will be made of:
- One lead member, called “The Lead”
- An number of other members, called “The Members”
The board will decide on a tie-breaking mechanism for decisions.
The lead will take on a “back-seat” role, only giving his final opinion/choice/vote after everyone else has. The Lead
will have a special role as a spokesperson of the technical board, both towards the management board and the community.
The lead can only be voted in by the management board which MUST seek a written list candidates from the technical board.
The lead can only be voted out by the technical board and MUST, prior to voting, seek a written opinion about it from the management board.
This will ensure that both boards agree on The Lead being a good fit for the role and that potential abuse is kept under control.
The board CANNOT contain more than one member that have financial ties with a specific entity. This will ensure the board
cannot be taken over in the long term by a single employer/corporation/organisation.
Responsibilities:
- Production of the protocol Specification
- Production and maintenance of an implementation validation tool to certify those implementations as protocol compliant
- Technical steering of the protocol, to fulfil the functional goals
- Review of community proposals
- Proactively ensure enough implementations exist to keep the protocol validated
Eligibility:
- Be the main author of at least one maintained (compliant with the current or previous version of the protocol) component implementation
- Submitted at least one protocol change that has been accepted in the official documentation in the last X months
- Commitment to be available X business days per week, except when on justified leave
Membership starts:
- By vote of all current technical board members
Membership ends if either of the following occurs:
- Of their own will, at any time
- By vote of all current technical board members
- By failure to disclose any potential conflict of interest, enforced by the management board if necessary
- By failure to be available as required, enforced by the management board if necessary
- By failure to keep their implementation maintained, enforced by the management board if necessary