lexicon-community/governance
1
0
Fork 0
Code Pull Requests Activity

Adoption of the updated Governance document (#10)

Browse Source 
Signed-off-by: Nick Gerakines <12125+ngerakines@users.noreply.github.com>
Co-authored-by: Tom Sherman <the.tomsherman@gmail.com>
This commit is contained in:
Nick Gerakines
2025-03-10 21:52:10 -04:00
committed by GitHub
parent 662ea81f1a
commit 4a06a1216e
5 changed files with 234 additions and 49 deletions
Download Patch File Download Diff File Expand all files Collapse all files

2
COLLABORATOR_GUIDE.md
View File

@ -1,2 +0,0 @@
# Collaborator Guide

90
CONTRIBUTING.md Normal file
View File

@ -0,0 +1,90 @@
# Contributor Guide
This document outlines what is expected of contributors to the Lexicon Community.
## Types of Contributions
This organization is volunteer run and contributions come in many forms. Recognizing this is critical to having a diverse and inclusive organization.
* Lexicon schema file changes, including the introduction and modification of `community.lexicon.*` changes.
* Documentation and guidance on how Lexicon Community lexicons are used and referenced.
* Reference material, including proof-of-concept code and writings, that provide context and examples for others on how to use Lexicon Community lexicons.
* Policy, governance, and process contributions to improve how the Lexicon Community Technical Steering Committee and Collaborators work with the community and accomplish the project’s mission.
There are other ways that people can contribute, and this is not an exclusive list.
## Lexicon Repository
The [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon) repository is the location that contains all of the official and approved lexicon schema files.
The "main" branch contains lexicon schema files and related material that is considered “production”. Access to write to the main branch, including who has authority to merge content into it is moderated.
## Play Books
### How Do I Add A Lexicon?
Lexicon additions and changes start with the formation of a working group at the direction of the technical steering committee.
#### Working Group Formation
Before any lexicon schema development occurs, a working group is formed. A working group is a short-lived group of 1-3 people that do the initial work for the lexicon.
1. In the [lexicon-community/governance](https://github.com/lexicon-community/governance) repository, a discussion is created by a technical steering committee that states the objective of the working group. It should include what the expected deliverable is as well as a general timeline. That technical steering committee member is the directly responsible individual and is charged with ensuring the objective is met.
2. Discussion occurs among technical steering committee members to get to agreement on the objective and goals.
3. In the lexicon-community/governance repository, an issue is created to bootstrap the working group. That issue is used to track all of the tasks needed to enable the working group to be successful.
#### Working Group Day-to-Day
Once the working group is formed, it is up to it’s members to go about the business of the working group to meet the objective. Working groups are meant to be self-organizing, but use official channels.
Depending on the site and scope of the working group, a temporary repository (i.e. "wg-bookmarks-lexicon") will be forked off of [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon). Access will be limited to the technical steering committee and collaborators.
1. The working group produces the lexicon schema definition files, documentation, and reference material needed to fulfill their objective.
2. The working group reports this to the technical steering committee and during that meeting, the next steps are worked out.
Eventually the produced work takes the form of a pull-request in the [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon) repository. These pull requests will have an agreed upon "do not merge before" date to allow for adequate time for discussion.
Alternatively, if the working group concludes with no proposed changes, some form of report or discussion will be reported in the [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon) discussion indicating such.
#### Request For Feedback
After the working group pull requests are created, a call for feedback is made to the broader community of collaborators and Lexicon Community contributors.
This open, iterative process takes place publicly with discourse happening in [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon) discussions.
Once the "do not merge before" date has passed and if the changes have approval by at least 2 technical steering committee members, the changes can be merged and move forward to release.
#### Release
The release process for lexicon additions and changes includes several steps:
1. The changes are merged into the main branch.
2. The lexicon is published for discovery through official lexicon discovery paths, specifically PDS records and DNS records.
3. The lexicon is announced through the Lexicon Community social media channel
### How are Lexicons Updated?
Lexicon modifications can take two forms.
1. Non-structural changes, including documentation and reference material, can be proposed by contributors in the form of pull requests.
2. Structural changes and feedback should take place in the form of a pull request or GitHub discussion
A technical steering committee member or collaborator may make the determination that the change is large enough in scope to warrant additional discussion and scrutiny. In those cases, a working group will be formed to fully explore the change and its impact.
#### Hotfixes
An important caveat to this is the concept of a hotfix. In the event of a critical or breaking change, a technical steering committee member may create a hotfix pull request. A hotfix PR would require approval by at least two other TSC members to be merged and released.
### Lexicon Proposal Best Practices
Lexicon schemas vary in complexity and there is no single design pattern to draw from. Instead, consider how you would answer the following questions when designing and proposing lexicon changes.
What does the proposal accomplish and can it be accomplished with existing lexicons?
Are common conventions used? Compared to adjacent Lexicon Community lexicon schema definition files, are fields and types that accomplish similar things named or presented in a way that makes them easy to understand? Are fields and types vague in naming or purpose?
Do all fields and types have relevant and helpful documentation? Is there supplemental or localized documentation or writings supporting the proposal?
Does the proposal include example records to demonstrate how they are used? Are the examples based on real-world scenarios that readers can use directly?
Are there example applications or reference material in the form of code that demonstrate how records and methods are constructed and invoked?

77
COVENANT.md Normal file
View File

@ -0,0 +1,77 @@
# Contributor Covenant
## Our Pledge
We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.
We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.
## Our Standards
Examples of behavior that contributes to a positive environment for our community include:
* Demonstrating empathy and kindness toward other people
* Being respectful of differing opinions, viewpoints, and experiences
* Giving and gracefully accepting constructive feedback
* Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience
* Focusing on what is best not just for us as individuals, but for the overall community
Examples of unacceptable behavior include:
* The use of sexualized language or imagery, and sexual attention or advances of any kind
* Trolling, insulting, or derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or email address, without their explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Enforcement Responsibilities
Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.
Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.
## Scope
This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official email address, posting via an official social media account, or acting as an appointed representative at an online or offline event.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the technical steering committee. All complaints will be reviewed and investigated promptly and fairly.
All community leaders are obligated to respect the privacy and security of the reporter of any incident.
## Enforcement Guidelines
Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:
### 1. Correction
**Community Impact:** Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.
**Consequence:** A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.
### 2. Warning
**Community Impact:** A violation through a single incident or series of actions.
**Consequence:** A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.
### 3. Temporary Ban
**Community Impact:** A serious violation of community standards, including sustained inappropriate behavior.
**Consequence:** A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.
### 4. Permanent Ban
**Community Impact:** Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.
**Consequence:** A permanent ban from any sort of public interaction within the community.
## Attribution
This Code of Conduct is adapted from the Contributor Covenant, version 2.1, available at https://www.contributor-covenant.org/version/2/1/code_of_conduct.html.
Community Impact Guidelines were inspired by Mozilla’s code of conduct enforcement ladder.
For answers to common questions about this code of conduct, see the FAQ at https://www.contributor-covenant.org/faq. Translations are available at https://www.contributor-covenant.org/translations.

100
GOVERNANCE.md
View File

@ -1,73 +1,97 @@
# Project Governance
# Governance
_NOTE_: This document is not final. See [RFC: Technical Steering Committee style governance #1](https://github.com/lexicon-community/governance/discussions/1)
## The Organization
# Technical Steering Committee
The mission of the Lexicon Community is to create an effective, active blueprint for collective ownership of Lexicons in the ATMosphere and build a stable and thoughtful lexicon that can be used by application, system, and SDK developers.
This project is collectively governed by a Technical Steering Committee (TSC), which is responsible for providing high-level guidance.
It does so through a partnership between Technical Steering Committee, Collaborators, and the broad AT Protocol community to work on a shared Lexicon and provide infrastructure to support it.
The TSC has final authority over this project, including:
The [lexicon-community/governance](https://github.com/lexicon-community/governance) project contains a list of contributors.
* Technical Direction
* Project Governance and Process
* Contribution Governance
* Project infrastructure (GitHub, DNS, and ATProtocol)
* Collaborator Management
## Technical Steering Committee
Initial membership invitations to the TSC are given to individuals who have been active contributors to ATProtocol applications, libraries, and components. Membership is expected to evolve over time according to the project's needs.
This project is collectively governed by a Technical Steering Committee (TSC) that has final authority over this project, including:
For the current list of TSC members, see the project [README.md](./README.md#technical-steering-committee).
* Technical direction
* Lexicon additions and changes
* Project governance and process
* Collaborator and contribution governance
* Project infrastructure
Initial membership in the TSC was granted to individuals who have been active contributors to ATProtocol applications, libraries, and components. Membership will evolve and adapt to meet the project's needs.
See the [Consent Seeking Decision Process](#consent-seeking-decision-process) below for further details on the consensus model used for governance.
## Collaborators
The [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon) GitHub repository is maintained by the TSC and additional Collaborators who are added by the TSC on an ongoing basis.
Collaborators are individuals who contribute to the Lexicon Community. They may represent themselves or an organization.
Individuals making significant and valuable contributions are made Collaborators and given commit-access to the project. These individuals are identified by the TSC and their addition as Collaborators is discussed during the regular TSC meeting.
Collaborators' primary responsibility is contributing to the technical and non-technical discussions and proposals within the Lexicon Community. There is no requirement that collaborators are AT Protocol software developers.
_Note:_ If you make a significant contribution and are not considered for commit-access, log an issue or contact a TSC member directly and it will be brought up in the next TSC meeting.
## Working Groups
Modifications of the contents of the lexicon-community/lexicon repository are made on a collaborative basis. Anybody with a GitHub account may propose a modification via pull request and it will be considered by the project Collaborators. All pull requests must be reviewed and accepted by a Collaborator with sufficient expertise who is able to take full responsibility for the change. In the case of pull requests proposed by an existing Collaborator, an additional Collaborator is required for sign-off. Consensus should be sought if additional Collaborators participate and there is disagreement around a particular modification. See _Consensus Seeking Process_ below for further detail on the consensus model used for governance.
The work of the Lexicon Community starts with working groups. Working groups are groups of individuals selected by the technical steering committee to collaborate for a specific purpose.
Collaborators may opt to elevate significant or controversial modifications, or modifications that have not found consensus to the TSC for discussion by assigning the ***tsc-agenda*** tag to a pull request or issue. The TSC should serve as the final arbiter where required.
Additions and significant changes to the Lexicon Community schema, infrastructure, and organization start with the designation of a working group with a vote of formation by the technical steering committee. Only TSC members may propose working groups, so non-TSC members must seek sponsorship.
For the current list of Collaborators, see the project [README.md](./README.md#current-project-team-members).
There are two requirements for forming a working group:
A guide for Collaborators is maintained in [COLLABORATOR_GUIDE.md](./COLLABORATOR_GUIDE.md).
1. An objective that is documented and used by the working group to focus the scope of its work.
2. A vote by technical steering committee members.
## Membership
A working group's objective and the produced result do not need to be a finished product, and it is not expected that the produced result will be used as is.
TSC seats are not time-limited. There is no fixed size of the TSC. However, the expected target is between 6 and 12, to ensure adequate coverage of important areas of expertise, balanced with the ability to make decisions efficiently.
For example, the technical steering committee could form a working group with three volunteers to "Provide an initial lexicon schema with documentation and reference code for recipe data structures and present a recommendation to the TSC in 30 days."
There is no specific set of requirements or qualifications for TSC membership beyond these rules.
The TSC is ultimately responsible for ensuring working groups deliver on their objectives, taking further action, or disbanding working groups, and does so at its discretion.
The TSC may add additional members to the TSC by a standard TSC motion.
## Consent Seeking Decision Process
A TSC member may be removed from the TSC by voluntary resignation, or by a standard TSC motion.
Lexicon Community follows a consent-seeking decision-making model, on the model of [Sociocratic organizations](https://www.sociocracyforall.org/consent-decision-making/) and the [IETF](https://datatracker.ietf.org/doc/html/rfc7282).
Changes to TSC membership should be posted in the agenda, and may be suggested as any other agenda item (see "Meetings" below).
After a discussion of an agenda item, the moderator goes around each voting party and asks, "Do you have any objection to the proposal?". If a valid objection is raised, the proposal cannot move forward as is, and must be amended until no objections are left. Amendments might include adding trial periods, reducing the scope of the proposal, or further research.
No more than 1/3 of the TSC members may be affiliated with the same employer. If removal or resignation of a TSC member, or a change of employment by a TSC member, creates a situation where more than 1/3 of the TSC membership shares an employer, then the situation must be immediately remedied by the resignation or removal of one or more TSC members affiliated with the over-represented employer(s).
A decision is made when there is no objection left.
## Meetings
### Valid Objections
The TSC meets no less than quarterly. A meeting can be called by a TSC member The meeting is run by a designated moderator approved by the TSC. Each meeting should be published to an accessible, public video hosting service.
In consent-seeking decision-making, valid objections cannot be a matter of personal preference, but must represent a potential harm to the group’s purpose or strategy. By raising an objection, a person signals that the current proposal is outside their range of tolerance, and poses a risk they believe the group cannot afford to take.
Items are added to the TSC agenda which are considered contentious or are modifications of governance, contribution policy, TSC membership, or release process.
By not raising an objection, each participant agrees the proposal is:
The intention of the agenda is not to approve or review all patches. That should happen continuously on GitHub and be handled by the larger group of Collaborators.
* "Good enough for now," moving the Lexicon Community towards its stated objectives.
* "Safe enough to try," not causing irreparable or disproportionate harm to the Lexicon Community’s mission.
Any community member or contributor can ask that something be added to the next meeting's agenda by logging a GitHub Issue. Any Collaborator, TSC member or the moderator can add the item to the agenda by adding the ***tsc-agenda*** tag to the issue.
### Overriding Objections
Prior to each TSC meeting, the moderator will share the Agenda with members of the TSC. TSC members can add any items they like to the agenda at the beginning of each meeting. The moderator and the TSC cannot veto or remove items.
Since each objection is a signal that someone thinks irreparable harm might come to the group’s goals, it is paramount that the group listens to objections and deeply tries to understand the reasoning behind them, even when they might not seem to make sense at first.
The TSC may invite persons or representatives from certain projects to participate in a non-voting capacity.
Overriding an objection should be a last resort, and might by itself harm the goals of the group in the long term. Should it become necessary, an objection can be overridden by majority vote.
The moderator is responsible for summarizing the discussion of each agenda item and sending it as a pull request after the meeting.
## Announcements and News
## Consensus Seeking Process
The Technical Steering Committee communicates official news and announcements in two ways:
The TSC follows a [Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) decision making model.
1. Through "Announcement" categorized discussions in the [lexicon-community/governance](https://github.com/lexicon-community/governance) and [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon) GitHub discussions
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.
2. Through social media posts on the official [@lexicon.community](https://hopper.at/?aturi=at%3A%2F%2Flexicon.community) account.
If an agenda item cannot reach a consensus, a TSC 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 approved by a majority of the TSC or else the discussion will continue. Simple majority wins.
## General Discourse
The Technical Steering Committee and collaborators encourage and moderate collaboration with the intention of producing tangible contributions to the Lexicon Community.
Discourse takes several forms, but official channels include:
* GitHub Discussions, Issues, and Pull-Requests
* Discord
* Email
Any comments, opinions, or writings of technical steering committee members and collaborators are their own and not of Lexicon Community unless explicitly indicated within the writing at the time.
## Contributor Guide and Covenant
The Lexicon Community organization does not limit contributions to technical steering committee members and collaborators, but there are guidelines that everyone must follow.
See [Contributor Guide](CONTRIBUTING.md) and [Contributor Covenant](COVENANT.md).
Community members who refuse to adhere to the Contributor Guide or Contributor Covenant may be expelled from the project.

14
README.md
View File

@ -3,20 +3,16 @@
This repository contains governance documentation and information:
* [GOVERNANCE.md](./GOVERNANCE.md) contains the governance bylaws for the technical steering committee (TSC).
* [COLLABORATOR_GUIDE.md](./COLLABORATOR_GUIDE.md) contains a guide for collaborators who have write access to the [lexicon-community/lexicon](https://github.com/lexicon-community/lexicon) repository.
* [CONTRIBUTING.md](./CONTRIBUTING.md) is a guide to contributing to Lexicon Community.
* [COVENANT.md](./COVENANT.md) is the contributor covenant and code of conduct.
[Governance Discussions](https://github.com/lexicon-community/governance/discussions) is used for announcements, technical steering committee activity, and governance discussions.
# Technical Steering Committee
* Boris Mann `@bmann.ca`
* Ms Boba `@essentialrandom.bsky.social`
* Nick Gerakines `@ngerakines.me`
* Rudy Fraser `@rudyfraser.com`
* Tom Sherman `@tom.frontpage.team`
* Ryan Barrett `@snarfed.org`
# Current Project Team Members
* Nick Gerakines `@ngerakines.me`
* Rudy Fraser `@rudyfraser.com`
* Tom Sherman `@tom.frontpage.team`
* Ryan Barrett `@snarfed.org`
* Tom Sherman `@tom.sherman.is`