This document describes how the Tessel Project is organized.
The Tessel project follows the mission and philosophies outlined here.
The Tessel project is organized in a tiered system, as illustrated in this Venn diagram:
Steering Committee members are included in the pool of Team Members, who are all in the pool of Contributors, etc.
Anyone is welcome to be a Contributor and add to the discussion or to technical assets.
Team Members, chosen by the Steering Committee, manage the day-to-day of community management and technical review.
Members of the Steering Committee jointly govern and give high-level guidance to the project.
These roles and the Project’s processes are outlined in more detail below.
The Tessel project is jointly governed by a Steering Committee (SC), which is responsible for high-level guidance of the project.
The SC has final authority over and responsibility to this project including:
- Community management
- Technical direction
- Project governance and process (including this policy)
- Branding, domains, and trademarks not managed by an outside foundation
- Contribution policy
- GitHub repository hosting
- Conduct guidelines
- Operations, including manufacturing and distribution of physical goods
- Maintaining the list of additional Team Members
Membership in the SC is expected to evolve over time according to the needs of the project. See the SC Membership section below for details.
For the current list of SC members, see Team.
All assets of the Tessel project not managed by an outside foundation, including website and GitHub repository, are maintained by the SC and additional Team Members who are added by the SC on an ongoing basis.
The SC identifies individuals making significant and valuable contributions to the project and adds them as Team Members in the standard decision-making process (see Consensus Seeking Process below).
A full description of a Team Member and their responsibilities and privileges is kept in Team Members
For the current list of Team Members, see Team.
Contributors are encouraged to join the conversation taking place on the forums. Anyone may propose a modification to assets via pull request, though in the case of hardware, discussion on the forums is advised first. Pull requests will be considered by the project Team Members. All pull requests must be reviewed and accepted by a Team Member with sufficient expertise who is able to take full responsibility for the change. In the case of pull requests proposed by an existing Team Member, an additional Team Member is required for sign-off.
Team Members may opt to elevate significant or controversial modifications, or modifications that have not found consensus, to the SC for discussion by assigning the sc-agenda tag to a pull request or issue. The SC should serve as the final arbiter where required.
The Contribution Guide can be found in the README.
Contributors, Team Members, and SC members are all governed by the Code of Conduct and can be banned for violations.
SC seats are not time-limited. There is no fixed size of the SC. However, the expected target is between 6 and 9, to ensure adequate coverage of important areas of expertise, balanced with the ability to make decisions efficiently.
There is no specific set of requirements or qualifications for SC membership beyond these rules.
The SC may add additional members to the SC by a standard SC motion.
A SC member may be removed from the SC by voluntary resignation, or by a standard SC motion, as defined in the “Consensus Seeking Process” section below.
Changes to SC membership should be posted in the agenda, and may be suggested as any other agenda item (see "SC Meetings" below).
In order to make sure all parts of the Tessel project are managed and moving forward, the SC will assign management of each of the following areas at the end of each meeting:
- SC Meeting Moderator for the next meeting
- Administrator: Meta & Administrative Work about the Tessel Project
- Hardware Development & Documentation
- Software Development & Documentation
- Community & Events
Areas are assigned to SC members. More than one area can be assigned to the same SC member.
Managing an area means that you are responsible to report back to the SC on the progress of that field at the next meeting.
The SC meets weekly on a Google Hangout. The meeting is run by a designated Moderator approved by the SC at the previous meeting. Notes should be submitted via PR to the Meeting Minutes folder.
Items are added to the SC agenda which are considered contentious or are modifications of governance, contribution policy, SC membership, or release process.
Any community member or contributor can ask that something be added to the next meeting's agenda by logging a GitHub Issue on this repo. Any Team Member, SC member, or the Moderator can add the item to the agenda by adding the sc-agenda tag to the issue.
Prior to each SC meeting, the Moderator will share the Agenda with members of the SC. SC members can add any items they like to the agenda any time before the meeting begins. The Moderator and the SC cannot veto or remove items.
The Moderator is responsible for summarizing the discussion of each agenda item and releasing it as a pull request to the Meeting Minutes folder after the meeting.
Meeting attendance is restricted to members of the Steering Committee.
The SC follows a Consensus Seeking decision making model.
When an agenda item has appeared to reach a consensus the Moderator will ask "Does anyone object?" as a final call for dissent from the consensus.
If an agenda item cannot reach a consensus a SC member can call for either a closing vote or a vote to table the issue to the next meeting. The call for a vote must be seconded by a majority of the SC or else the discussion will continue. 2/3 majority wins in a vote.
The Steering Committee has full discretion over physical and intellectual property generated by the Tessel Project.