From ba2a4d2fe29aa580cc0b7167a9bd2b60715802cc Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Mon, 2 Aug 2021 16:21:08 -0700 Subject: [PATCH 01/13] Community Team RFC initial draft --- rfcs/0000-community-team.md | 190 ++++++++++++++++++++++++++++++++++++ 1 file changed, 190 insertions(+) create mode 100644 rfcs/0000-community-team.md diff --git a/rfcs/0000-community-team.md b/rfcs/0000-community-team.md new file mode 100644 index 000000000..6d36f99f0 --- /dev/null +++ b/rfcs/0000-community-team.md @@ -0,0 +1,190 @@ +--- +feature: community-team +start-date: 2021-07-31 +author: Irenes (Irene Knapp) +co-authors: ashkitten +shepherd-team: (names, to be nominated and accepted by RFC steering committee) +shepherd-leader: (name to be appointed by RFC steering committee) +related-issues: (will contain links to implementation PRs) +--- + +# Summary +[summary]: #summary + +Establish an official community team to make moderation decisions, model social norms, and mediate interpersonal problems. + +# Motivation +[motivation]: #motivation + +There is not currently any official mechanism for moderation action. It's not sustainable to have to call on Graham any time there's a spammer or conflict that requires moderation, and we'd like to help the community become more self-regulating. + +# Goals +[goals]: #goals + +* Model and enforce social norms +* Mediate disputes when doing so is beneficial to the community +* Respect the privacy of community members +* Foster newcomers and develop their leadership potential +* Moderate all places where community members interact, including Discourse, Matrix, and GitHub +* Ensure that collaboration on shared technical goals is possible +* Ensure that the Nix community is a welcoming space for people from marginalized backgrounds +* Do not allow the Nix community to be a place for spreading ideas rooted in fascism or bigotry +* Ensure that people in positions of authority within the community, whether technical or otherwise, promote community participation in all things and use their authority in ways that are consistent with the community's values +* Don't be overly driven by the personalities of a small set of people +* Maintain a good ratio of experienced members of the community team to newcomers, such that newcomers can gain experience as they work +* Avoid excessive churn on the community team + +# Non-Goals +[non-goals]: #non-goals + +* Provide technical leadership +* Create a hierarchical power structure + +# Detailed design +[design]: #detailed-design + +The community team is not an elected position, it is a collection of people who are interested in helping the community thrive. Membership is not permanent, and all community members are encouraged to participate at some point regardless of previous community moderation experience. It isn't important whether or not members are the best suited for the position, we want to avoid making it an exclusive position or a position associated with only certain people. We also want to avoid having people on the community team get overly attached to their personal role. + +Being on the community team does not make you "more right" or prevent anyone from giving feedback on your behavior. Community team members as well as all other community members are expected to take feedback from anyone regardless of their status on any team. + +Experienced members are expected to help those less experienced (whether on the team or not) to become more knowledgeable about community dynamics, how and when to take moderation action, and how to recognize and stop all forms of abuse and trolling. The *primary* task of experienced members should be training less experienced members. + +Being on the community team is a public service to the whole community, and it is both a responsibility and a privilege. Although the community team wields formal authority, that authority should *not* be understood as establishing a hierarchy of power. Community members will naturally rotate onto and off of the community team over time. All community members should always try to set the best example they can for others, with or without formal power. All community members should have a voice in important decisions, with or without formal power. + +## Lifecycle of a community team member +[team-member-lifecycle]: #team-member-lifecycle + +It is expected that the typical course of events, from the perspective of any specific community member, will be as follows. First, they will participate in the community, learn its ideals and social norms, and contribute in whatever ways they see fit. Second, at some point they will apply for membership on the community team. If accepted, they will work closely with other members of the community team to perform their duties and develop their leadership skills. + +At some point, when members of the commmunity team are able to perform their duties reliably and to everyone's satisfaction, their role within the team should shift to being less about directly carrying out decisions and more about mentoring newer members. There is no specific expectation for how long members will stay on as mentors, but it should be long enough to provide ideological continuity, and not so long that the team risks becoming overly driven by any one member's personality. + +Eventually, when they are no longer needed or no longer want the burden, team members should graduate and return to being ordinary members of the community. Former team members should still be aware that their behavior sets an example for others, and do their best to make it a good example. Former team members should not attempt to exert strong control over the direction of the community team, at least not to any greater extent than any community member could, but may make themselves available for advice at the discretion of the team. + +The preceding outline is not intended to be treated as a precise guide, only as a general one. Some team members may already have relevant outside experience when they join the team. It is permissible for community members to take multiple rotations on the team should the needs of the team require it. In general, when evaluating unusual situations, the goal should be to always be empowering a new set of leaders while maintaining ideological continuity. If a decision would lead to vesting too much power in the same people indefinitely, or if it would lead to too much ideological drift from the community's values, it should be looked on with skepticism. + +## Rules vs. principles +[rules-vs-principles]: #rules-vs-principles + +The code of conduct and statement of values will set forth the goals of the community and the general principles by which it is moderated. There will not be a focus on trying to specify *exact* rules with legalistic precision. + +It is the position of these authors that spelling rules out in precise, formal detail invites people to treat the rules as a game and try to find ways to use the letter of the rules against the spirit of them. By focusing on principles and appealing to community members to live up to those ideals, we hope to make such "gaming" as difficult as possible. + +Making this system work without precise rules requires mutual trust between members of the community and the community team. The community team will make their best effort to explain why moderation decisions are being made and to tie those decisions to the statement of values. These explanations will typically be given by the team member who made the decision, but this is an obligation for the team as a whole, not for any single team member. It is understood that explanations are time-consuming, and that demanding them can be a tool for harassment or for undermining the team's authority; placing the obligation on the team as a whole is an attempt to balance those risks against the need for public accountability. There is no specific requirement that explanations be provided rapidly; the community team's workload may not always permit this. Explanations will never disclose private information, whether about community members or about anyone else. + +Although feedback on moderation practices and philosophy is encouraged, community team decisions are to be disputed only through the process set forth in this document (see the contact section). Community members are expected to respect that there is a difference between giving feedback and attempting to re-litigate a decision in the court of public opinion. It is okay to respectfully disagree, in private or in public; it is not okay to prolong such a discussion unnecessarily or turn it into personal attacks. + +It is important for communities that are seeking to make the world better to have clear values, to articulate those values, and to be willing to stand up for them when necessary. Furthermore, since the Nix community is large and ideologically diverse, it is important that there be transparency as to what the community team is trying to accomplish. The preceding paragraphs are an attempt at finding this delicate balance. + +To those who might oppose any public statement of values: Isn't it better to have it up front, so you don't have to wonder? + +To those who might say that any statement of values is merely performative and that the proof is in actions, not words: These authors fully agree, but we're saying the words anyway. Please hold us accountable for living up to them. + +## How new members join and leave the community team +[joining-and-leaving]: #joining-and-leaving + +1. New members may apply to join the community team, and existing team members will decide on these applications. The team will evaluate applicants by the length of time they've been part of the Nix community, by their good character, by their demonstrated ability to exercise good judgement, and by their commitment to public service and a willingness to be self-critical. To form the initial team, the founding members will be appointed by Graham at his sole discretion. + + The community team may decide to reach out to active community members they think would be a good fit for the team, if the member has not already applied to the team. The community team should keep internal records of what such outreach has been done so as to not duplicate efforts or reach out to members who have expressed disinterest prior. + + The team's focus should be on developing leadership from within, not on bringing in experienced people from outside. This is important to maintaining ideological continuity. + +2. Community team members may resign at any time. Such resignations are effective immediately. In exceptional circumstances, members may also be removed by decision of the team; it is hoped that this will never be needed. + +3. The community team will decide on new members by consensus. That is, new members will be added to the team if and only if every then-current team member is in favor of adding them. In the event of removing members, the team will decide by a 2/3 majority vote, with the permissible votes being "yes" and "no". All team members are required to participate in membership decisions. + + The rationale for using consensus as the basis of adding members is that it will lead to conservative decisions, which is expected to help with the goal of ideological continuity. This will also make it harder for a hostile takeover to succeed. Removing members is slightly easier than adding them, for the same reasons. + + The formal decision-making process is intended only as a way to resolve membership questions and other long-term questions about the direction of the team; it is neither required nor recommended for routine moderation decisions. + +4. The team should attempt to maintain a sufficient size such that there are enough members to cover all the community spaces without major gaps. On no account should the team ever be so large that members can't all know each other, or can't keep each other in the loop on decisions. + +5. Members are expected to remain in regular communication with each other and develop their social bonds; it is understood that social bonds among team members are vitally important to doing the job properly. The arrival of new members should be celebrated, and the team should maintain a low-latency communication channel where members can easily reach each other for discussions that are private from the community at large. Retired team members should leave that channel. + +6. There will be a formal ceremony to onboard new members and graduate retiring members. Ceremonies will take place on video calls attended by all current team members and any interested members of the community. Nobody will be required to show their face or voice, but team members must listen and actively participate, even if only through text. + + In exceptional circumstances it is permissible for team members not directly involved in the proceedings to miss them, but these authors do consider this ceremony to be an important ritual for establishing a coherent culture, and hope that team members will keep that in mind and make every effort to attend. + + The ceremony will be led by an existing team member who will introduce newcomers and announce retirements. The member leading the ceremony will explain the team's values and responsibilities, and how the community team operates. New members will then each, individually state: "I understand my responsibilities as a member of the community team and agree to uphold the community values." Following the formal ceremony, there will be celebratory social interaction. + + This ceremony may seem extremely formal for a technical community, but it serves an important purpose. In a world with very little respect for ceremony, it's important to have things that bring us together, even if they are simple things. Since the community team's responsibility is an important one, it is appropriate for team members to treat it with gravity. It is likewise important to take time to celebrate happy things, so that shared experiences can become the basis of cooperation. + +## Authority of the community team +[authority]: #authority + +Team members will have the authority to ban community members from any community social space, or from all such spaces. Team members will be added to all necessary access control lists to exercise this power, as soon as possible after the onboarding ceremony. + +Team members will manage their own access control lists, adding and removing each other on Discourse, GitHub, Mjolnir (the Matrix bot), and anywhere else that's necessary. + +Community social spaces include Disourse, GitHub, and Matrix, as well as any analogous spaces which may exist in the future. It is expected that team members will not act alone when implementing bans, except in situations which are both urgent and exceptional. Like all moderation actions, bans will be publicly disclosed to the community, and explained. Banning somebody from participation on GitHub does prevent them from submitting pull requests; it is thus equivalent to full expulsion from the technical effort which the community is dedicated to. + +It is necessary for the team to have the authority to ban, as it is the basis of all the soft power the team wields. However, the team should prefer to use bans only as a last resort. When somebody is excluded from a community, the community has no further power to change their heart, help them grow, or otherwise influence them. Bans should not be performed vindictively or as punishments, but only as necessary actions for the well being of the remaining community members. A ban is a sad occasion, no matter how necessary it may be. + +The team should, whenever possible, lead by example. This may include mediating disputes, either privately or publicly as appropriate. It may also include asking community members to refrain from certain topics of discussion or from certain conflicts. Community members are expected to follow these directions, or to appeal them privately by escalating to the full community team. It is valid and important for community members to give feedback on the community team's actions, but team members' decisions are not to be mocked, flaunted, or relitigated in the court of public opinion. + +The above are some suggested remedies, but these should not be taken as prescriptive. The full space of social actions is open to team members as potential tools for resolving disputes. Team members are expected to use their authority only in ways that embody justice and that are consistent with the community's values, as formalized in the code of conduct and statement of values. Team members are expected to recognize the power dynamic that they are part of, and to be proactive and explicit in making sure community members know when they're speaking in an official capacity and when they're speaking in a personal capacity. Team members are not expected to be impartial in the sense of pretending not to have personal beliefs or goals, but are expected to hold the community's values above their own, in their official actions. + +The community team will hold its members accountable to these ideals. + +## Code of Conduct and Statement of Values +[values]: #values + +Following the adoption of this RFC, the code of conduct and statement of values will be displayed on a dedicated page on the NixOS website. They will read as follows, unless amended by a future RFC. + +The Nix community recognizes that its members come from many walks of life, and that it is natural for us to disagree on some things. Nonetheless, we are all committed to certain values, to allow us to work together and build awesome technologies. + +Community members are expected to follow these values in their interactions in all official Nix social spaces, including websites, chat rooms, bug threads, and conferences. We have a community team who will set and enforce social norms, to make that easier for everyone. faCommunity members are expected to follow the community team's requests. + +If you have opinions on the community team's work, get involved! It's a rotating team, and we want to develop the leadership potential in all community members. + +Our values are as follows. + +**Collaboration** — We all want to make the best technologies we can. We work together on our common goals, with open discussion, and without petty infighting or focusing on blame. We are all, always, teaching each other to be better. + +**Communication** — When we encounter problems, we focus on solving them, not on fighting each other. When we disagree on technical subjects we follow appropriate processes to escalate them to technical leadership. We try to avoid and de-escalate personal conflicts, but when they are unavoidable we seek mediation. + +**Empathy** — We try to see perspectives other than our own, to treat everyone with kindness and empathy, to move past mistakes. When we criticise each other we try to do so graciously. We respect each other's different backgrounds and viewpoints, and we respect the effort everyone puts into the community. + +**Humility** — We acknowledge that everybody has something to learn, that nobody is infallible. + +**Inclusion** — We work to include everybody, especially people from marginalized backgrounds. We strive to be fair and equitable, and to respect the ways people are different. We reject bigotry in all its forms. + +**Accommodation** — When community members face barriers to participation, we accommodate their needs to the best of our ability. This includes, but is not limited to, needs related to disability either physical or mental, to medical issues, to religious observations, to parenting, and to sober lifestyles. + +**Transparency** — We recognize that the whole community has a stake in decisions. We strive not to be arbitrary, to disclose when important decisions are made, and to make sure there is clear justification. + +**Advocacy** — We don't just recite our values, we live by them. We don't simply ignore attacks on our values, we speak up and take action to defend them. + +## Contacting the community team +[contact]: #contact + +The community team will be contactable via a public email address listed on the NixOS website. This email address will forward to all community team members. Additionally, all community team members will list some form of individual contact information so community members can reach out to them directly in the case of an issue concerning other community team members or matters they are not comfortable disclosing to the entire community team. + +Emails sent to the community team are not to be shared outside of the community team, or to more people than need to be involved in the case of messages sent to individual team members. + +There will be a method to quickly notify all community team members in official public communication channels, in case of something needing urgent attention. + +Any of these contact methods may be used for disputes, for discussion of issues facing the community or individual members, as a way to raise safety concerns, and for any other reason that feels necessary. + +# Drawbacks +[drawbacks]: #drawbacks + +This effort will be a focus of controversy, especially at the outset. It is the position of these authors that it's a necessary controversy, and that things will get less intense once they settle. + +# Alternatives +[alternatives]: #alternatives + +Failing to actively manage and lead the community makes it difficult for the community to practice any sort of values, not even seemingly "easy" values such as inclusion of minorities and an opposition to fascism. Every technical project is, necessarily, also a community, and it is important to live up to that responsibility for the betterment of society as a whole. + +Creating a hierarchical power structure based on specific individuals having semi-permanent roles is an approach that could initially be successful at reducing conflict. However, it would require a great deal of trust which may not exist, and it is not sustainable to indefinitely place that level of trust in specific people. By having a rotating team which includes *everyone*, we spread the necessary skills throughout the community and foster a culture which handles conflict in appropriate ways from the beginning. + +# Unresolved questions +[unresolved]: #unresolved-questions + +* Will the community agree to go in this direction? + +* How can we work this into the technical framework of the Nix community? (discourse, mjolnir/matrix, github teams, etc.) + +# Future work +[future]: #future-work + +* Consider ways to create community investment in this process, and to incorporate feedback on an ongoing basis, perhaps by setting aside recurring blocks of time for community-wide airing of concerns. From d7877a8430ea2033792b0c48e49a5c7c418fcf94 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Tue, 3 Aug 2021 13:20:13 -0700 Subject: [PATCH 02/13] RFC number assigned --- rfcs/{0000-community-team.md => 0098-community-team.md} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename rfcs/{0000-community-team.md => 0098-community-team.md} (100%) diff --git a/rfcs/0000-community-team.md b/rfcs/0098-community-team.md similarity index 100% rename from rfcs/0000-community-team.md rename to rfcs/0098-community-team.md From a56b6e86bce5c3b52af0e9df94f0b82fe770946a Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Wed, 4 Aug 2021 21:40:01 -0700 Subject: [PATCH 03/13] RFC 98: Fix two typos. These were pointed out by commenters - thanks! --- rfcs/0098-community-team.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index 6d36f99f0..cdc60b679 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -115,7 +115,7 @@ Team members will have the authority to ban community members from any community Team members will manage their own access control lists, adding and removing each other on Discourse, GitHub, Mjolnir (the Matrix bot), and anywhere else that's necessary. -Community social spaces include Disourse, GitHub, and Matrix, as well as any analogous spaces which may exist in the future. It is expected that team members will not act alone when implementing bans, except in situations which are both urgent and exceptional. Like all moderation actions, bans will be publicly disclosed to the community, and explained. Banning somebody from participation on GitHub does prevent them from submitting pull requests; it is thus equivalent to full expulsion from the technical effort which the community is dedicated to. +Community social spaces include Discourse, GitHub, and Matrix, as well as any analogous spaces which may exist in the future. It is expected that team members will not act alone when implementing bans, except in situations which are both urgent and exceptional. Like all moderation actions, bans will be publicly disclosed to the community, and explained. Banning somebody from participation on GitHub does prevent them from submitting pull requests; it is thus equivalent to full expulsion from the technical effort which the community is dedicated to. It is necessary for the team to have the authority to ban, as it is the basis of all the soft power the team wields. However, the team should prefer to use bans only as a last resort. When somebody is excluded from a community, the community has no further power to change their heart, help them grow, or otherwise influence them. Bans should not be performed vindictively or as punishments, but only as necessary actions for the well being of the remaining community members. A ban is a sad occasion, no matter how necessary it may be. @@ -132,7 +132,7 @@ Following the adoption of this RFC, the code of conduct and statement of values The Nix community recognizes that its members come from many walks of life, and that it is natural for us to disagree on some things. Nonetheless, we are all committed to certain values, to allow us to work together and build awesome technologies. -Community members are expected to follow these values in their interactions in all official Nix social spaces, including websites, chat rooms, bug threads, and conferences. We have a community team who will set and enforce social norms, to make that easier for everyone. faCommunity members are expected to follow the community team's requests. +Community members are expected to follow these values in their interactions in all official Nix social spaces, including websites, chat rooms, bug threads, and conferences. We have a community team who will set and enforce social norms, to make that easier for everyone. Community members are expected to follow the community team's requests. If you have opinions on the community team's work, get involved! It's a rotating team, and we want to develop the leadership potential in all community members. From 9e51b65c135fb20965d0fb77db642632869b7e50 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Thu, 5 Aug 2021 19:40:12 -0700 Subject: [PATCH 04/13] RFC 98: Clarify official vs. unofficial spaces. This addresses a proposal from samueldr. It clarifies that the scope is limited to official spaces, and talks about how unofficial spaces can be involved. Per discussion on the GitHub thread, NixCon is in scope so it's now listed explicitly. --- rfcs/0098-community-team.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index cdc60b679..8615ffac9 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -25,7 +25,7 @@ There is not currently any official mechanism for moderation action. It's not su * Mediate disputes when doing so is beneficial to the community * Respect the privacy of community members * Foster newcomers and develop their leadership potential -* Moderate all places where community members interact, including Discourse, Matrix, and GitHub +* Moderate all official spaces where community members interact, including Discourse, Matrix, GitHub, and NixCon * Ensure that collaboration on shared technical goals is possible * Ensure that the Nix community is a welcoming space for people from marginalized backgrounds * Do not allow the Nix community to be a place for spreading ideas rooted in fascism or bigotry @@ -115,7 +115,9 @@ Team members will have the authority to ban community members from any community Team members will manage their own access control lists, adding and removing each other on Discourse, GitHub, Mjolnir (the Matrix bot), and anywhere else that's necessary. -Community social spaces include Discourse, GitHub, and Matrix, as well as any analogous spaces which may exist in the future. It is expected that team members will not act alone when implementing bans, except in situations which are both urgent and exceptional. Like all moderation actions, bans will be publicly disclosed to the community, and explained. Banning somebody from participation on GitHub does prevent them from submitting pull requests; it is thus equivalent to full expulsion from the technical effort which the community is dedicated to. +Official community social spaces include Discourse, GitHub, Matrix, and NixCon, as well as any analogous spaces which may exist in the future. The community team does not hold authority in unofficial spaces, but unofficial spaces are invited to officially endorse the statement of values if they decide it's right for them. The community team will be available, at its discretion, for consultation with people running unofficial communities. + +It is expected that team members will not act alone when implementing bans, except in situations which are both urgent and exceptional. Like all moderation actions, bans will be publicly disclosed to the community, and explained. Banning somebody from participation on GitHub does prevent them from submitting pull requests; it is thus equivalent to full expulsion from the technical effort which the community is dedicated to. It is necessary for the team to have the authority to ban, as it is the basis of all the soft power the team wields. However, the team should prefer to use bans only as a last resort. When somebody is excluded from a community, the community has no further power to change their heart, help them grow, or otherwise influence them. Bans should not be performed vindictively or as punishments, but only as necessary actions for the well being of the remaining community members. A ban is a sad occasion, no matter how necessary it may be. From 26fb64f35c3db202c67c6fa0770affc0c3c87336 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Thu, 5 Aug 2021 19:52:35 -0700 Subject: [PATCH 05/13] RFC 98: Add the NixOS Foundation's statement. This is per ryantm's suggestion on the GitHub thread. --- rfcs/0098-community-team.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index 8615ffac9..c8b5b5fc5 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -132,6 +132,8 @@ The community team will hold its members accountable to these ideals. Following the adoption of this RFC, the code of conduct and statement of values will be displayed on a dedicated page on the NixOS website. They will read as follows, unless amended by a future RFC. +The NixOS Foundation aims to promote participation without regard to gender, sexual orientation, disability, ethnicity, age, or similar personal characteristics. We want to strive to create and foster community by providing an intentionally welcoming and safe environment where all feel valued and cared for, and where all are given opportunity to participate meaningfully. The Foundation will work with the community in service of this goal. + The Nix community recognizes that its members come from many walks of life, and that it is natural for us to disagree on some things. Nonetheless, we are all committed to certain values, to allow us to work together and build awesome technologies. Community members are expected to follow these values in their interactions in all official Nix social spaces, including websites, chat rooms, bug threads, and conferences. We have a community team who will set and enforce social norms, to make that easier for everyone. Community members are expected to follow the community team's requests. From 13effeb95b9ac16768bd0e98c43d822a0d0ec980 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Tue, 10 Aug 2021 20:21:23 -0700 Subject: [PATCH 06/13] RFC 98: Clarify informative vs. normative sections. This was per a suggestion on the discussion thread, since it kept coming up. --- rfcs/0098-community-team.md | 7 +++++++ 1 file changed, 7 insertions(+) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index c8b5b5fc5..42270631f 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -8,6 +8,13 @@ shepherd-leader: (name to be appointed by RFC steering committee) related-issues: (will contain links to implementation PRs) --- +# About this document +[about]: #about-document + +Most sections in this document are informative, not normative. They describe how to evaluate the normative sections, but do not establish rules. Nothing in the informative sections is meant to be enforced as-written, only to guide discussion of the RFC. The normative sections create procedures which will apply going forward. + +Detailed Design and its six sub-sections are normative. All other sections are informative. + # Summary [summary]: #summary From f7ca4ed0a409f4a8dc4bcc3049ab5ec481741be1 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Tue, 10 Aug 2021 21:11:53 -0700 Subject: [PATCH 07/13] RFC 98: Clarify precedence and rationale wrt the team size constraints. This was per a suggestion on the GitHub thread. --- rfcs/0098-community-team.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index 42270631f..6fe1f2e5f 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -103,7 +103,7 @@ To those who might say that any statement of values is merely performative and t The formal decision-making process is intended only as a way to resolve membership questions and other long-term questions about the direction of the team; it is neither required nor recommended for routine moderation decisions. -4. The team should attempt to maintain a sufficient size such that there are enough members to cover all the community spaces without major gaps. On no account should the team ever be so large that members can't all know each other, or can't keep each other in the loop on decisions. +4. The team should attempt to maintain a sufficient size such that there are enough members to cover all the community spaces without major gaps. On no account should the team ever be so large that members can't all know each other, or can't keep each other in the loop on decisions. In the event of a conflict between these two constraints, the latter takes precedence. It is deliberate that no exact number is specified here; it is anticipated that the community's needs will change over time. 5. Members are expected to remain in regular communication with each other and develop their social bonds; it is understood that social bonds among team members are vitally important to doing the job properly. The arrival of new members should be celebrated, and the team should maintain a low-latency communication channel where members can easily reach each other for discussions that are private from the community at large. Retired team members should leave that channel. From ede587e70a735348d20165b175389f7b749a24c2 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Fri, 13 Aug 2021 17:33:15 -0700 Subject: [PATCH 08/13] RFC 98: Change the onboarding/graduation ceremony to use a chat room. It was pointed out that video calls are non-inclusive. Thanks! --- rfcs/0098-community-team.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index 6fe1f2e5f..657a5eeea 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -107,11 +107,11 @@ To those who might say that any statement of values is merely performative and t 5. Members are expected to remain in regular communication with each other and develop their social bonds; it is understood that social bonds among team members are vitally important to doing the job properly. The arrival of new members should be celebrated, and the team should maintain a low-latency communication channel where members can easily reach each other for discussions that are private from the community at large. Retired team members should leave that channel. -6. There will be a formal ceremony to onboard new members and graduate retiring members. Ceremonies will take place on video calls attended by all current team members and any interested members of the community. Nobody will be required to show their face or voice, but team members must listen and actively participate, even if only through text. +6. There will be a formal ceremony to onboard new members and graduate retiring members, to be attended by all current team members and by any interested members of the community. The ceremony will take place in a designated chat room for the event, and will last 24 hours, with formal activities at the beginning and end of the 24-hour period. The intent of leaving it open for 24 hours is to allow participants to drop in and out, and catch up on scrollback, as their individual needs and timezones allow. + + The ceremony will be led by an existing team member who will introduce newcomers and announce retirements. The member leading the ceremony will explain the team's values and responsibilities, and how the community team operates. New members will then each, individually state: "I understand my responsibilities as a member of the community team and agree to uphold the community values." The ceremony leader and any newly arriving team members are expected to be present both at the opening of the ceremony, and at the closing. In exceptional circumstances it is permissible for team members not directly involved in the proceedings to miss them, but these authors do consider this ceremony to be an important ritual for establishing a coherent culture, and hope that team members will keep that in mind and make every effort to attend. - - The ceremony will be led by an existing team member who will introduce newcomers and announce retirements. The member leading the ceremony will explain the team's values and responsibilities, and how the community team operates. New members will then each, individually state: "I understand my responsibilities as a member of the community team and agree to uphold the community values." Following the formal ceremony, there will be celebratory social interaction. This ceremony may seem extremely formal for a technical community, but it serves an important purpose. In a world with very little respect for ceremony, it's important to have things that bring us together, even if they are simple things. Since the community team's responsibility is an important one, it is appropriate for team members to treat it with gravity. It is likewise important to take time to celebrate happy things, so that shared experiences can become the basis of cooperation. From 9955763e29d2bd7bd57364dc9a64798525aa3435 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Fri, 13 Aug 2021 17:52:48 -0700 Subject: [PATCH 09/13] RFC 98: Add a requirement to publish a ban log. This came from discussion on the GitHub thread. --- rfcs/0098-community-team.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index 657a5eeea..1e23053fd 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -126,6 +126,8 @@ Official community social spaces include Discourse, GitHub, Matrix, and NixCon, It is expected that team members will not act alone when implementing bans, except in situations which are both urgent and exceptional. Like all moderation actions, bans will be publicly disclosed to the community, and explained. Banning somebody from participation on GitHub does prevent them from submitting pull requests; it is thus equivalent to full expulsion from the technical effort which the community is dedicated to. +The team will publish a permanent, publicly visible log of all bans it imposes. The log will have short summaries of the circumstances leading to the ban, typically a few words, as a supplement to the full explanations given through discussion as described under [Rules vs. principles](#rules-vs-principles). The team will also maintain its own notes on the full circumstances surrounding bans; these notes will be kept private. + It is necessary for the team to have the authority to ban, as it is the basis of all the soft power the team wields. However, the team should prefer to use bans only as a last resort. When somebody is excluded from a community, the community has no further power to change their heart, help them grow, or otherwise influence them. Bans should not be performed vindictively or as punishments, but only as necessary actions for the well being of the remaining community members. A ban is a sad occasion, no matter how necessary it may be. The team should, whenever possible, lead by example. This may include mediating disputes, either privately or publicly as appropriate. It may also include asking community members to refrain from certain topics of discussion or from certain conflicts. Community members are expected to follow these directions, or to appeal them privately by escalating to the full community team. It is valid and important for community members to give feedback on the community team's actions, but team members' decisions are not to be mocked, flaunted, or relitigated in the court of public opinion. From 333cef9a1fd17529f128547c9e5aa85e8f8a5571 Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Fri, 13 Aug 2021 18:12:19 -0700 Subject: [PATCH 10/13] RFC 98: Change emphasis in the summary; clarify "model social norms". Changing the order of items in the summary was suggested in GitHub discussion. Two people on GitHub also expressed confusion about the meaning of "model social norms", so we added a sentence in "rules vs principles" clarifying it. The paragraph that that sentence was added to was getting quite long, so we split it, but no other wording was changed. --- rfcs/0098-community-team.md | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index 1e23053fd..a0903ae69 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -18,7 +18,7 @@ Detailed Design and its six sub-sections are normative. All other sections are i # Summary [summary]: #summary -Establish an official community team to make moderation decisions, model social norms, and mediate interpersonal problems. +Establish an official community team to model social norms, mediate interpersonal problems, and make moderation decisions. # Motivation [motivation]: #motivation @@ -76,7 +76,9 @@ The code of conduct and statement of values will set forth the goals of the comm It is the position of these authors that spelling rules out in precise, formal detail invites people to treat the rules as a game and try to find ways to use the letter of the rules against the spirit of them. By focusing on principles and appealing to community members to live up to those ideals, we hope to make such "gaming" as difficult as possible. -Making this system work without precise rules requires mutual trust between members of the community and the community team. The community team will make their best effort to explain why moderation decisions are being made and to tie those decisions to the statement of values. These explanations will typically be given by the team member who made the decision, but this is an obligation for the team as a whole, not for any single team member. It is understood that explanations are time-consuming, and that demanding them can be a tool for harassment or for undermining the team's authority; placing the obligation on the team as a whole is an attempt to balance those risks against the need for public accountability. There is no specific requirement that explanations be provided rapidly; the community team's workload may not always permit this. Explanations will never disclose private information, whether about community members or about anyone else. +Making this system work without precise rules requires mutual trust between members of the community and the community team. The community team will model social norms by holding themselves to a high standard of behavior. The community team will make their best effort to explain why moderation decisions are being made and to tie those decisions to the statement of values. These explanations will typically be given by the team member who made the decision, but this is an obligation for the team as a whole, not for any single team member. + +It is understood that explanations are time-consuming, and that demanding them can be a tool for harassment or for undermining the team's authority; placing the obligation on the team as a whole is an attempt to balance those risks against the need for public accountability. There is no specific requirement that explanations be provided rapidly; the community team's workload may not always permit this. Explanations will never disclose private information, whether about community members or about anyone else. Although feedback on moderation practices and philosophy is encouraged, community team decisions are to be disputed only through the process set forth in this document (see the contact section). Community members are expected to respect that there is a difference between giving feedback and attempting to re-litigate a decision in the court of public opinion. It is okay to respectfully disagree, in private or in public; it is not okay to prolong such a discussion unnecessarily or turn it into personal attacks. From 5bf9c8472aaf2248ea59f4026ea3193ad6f8ca8c Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Fri, 13 Aug 2021 18:57:04 -0700 Subject: [PATCH 11/13] RFC 98: Add a verbatim suggestion to "alternatives". This is per GitHub discussion. --- rfcs/0098-community-team.md | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index a0903ae69..f9412a4bf 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -192,6 +192,14 @@ Failing to actively manage and lead the community makes it difficult for the com Creating a hierarchical power structure based on specific individuals having semi-permanent roles is an approach that could initially be successful at reducing conflict. However, it would require a great deal of trust which may not exist, and it is not sustainable to indefinitely place that level of trust in specific people. By having a rotating team which includes *everyone*, we spread the necessary skills throughout the community and foster a culture which handles conflict in appropriate ways from the beginning. +A suggestion from @blaggacao: +* Submit one procedural RFC for the Moderating(!) Team +* A normative RFC for our "Statement of Values" which can be discussed without this really incommodating defensive framing of "policing discussions on the public forum" +* As prominent member pointed out, the NixOS foundation already had had a tweet commiting to the entirety of prerequisite principles of emotional safety in public discussions. An really short RFC could take that statement, maybe expand a little bit in context and move it out of twitter into the body of (accepted) RFCs. Such RFC will have "teeth". + +This suggestion is included verbatim, per discussion on the GitHub thread. + + # Unresolved questions [unresolved]: #unresolved-questions From 4d86df3b8e8c7b8ef9bf842cea673a9ee757617b Mon Sep 17 00:00:00 2001 From: Irene Knapp Date: Fri, 13 Aug 2021 20:08:30 -0700 Subject: [PATCH 12/13] RFC 98: Add a paragraph about the purpose of the statement of values. We noticed that a lot of the discussion is treating the statement of values solely as an enforcement guideline. We thought it might hepl to add this paragraph explaining other ways we expect it to be used. --- rfcs/0098-community-team.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index f9412a4bf..10bddf62d 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -84,6 +84,8 @@ Although feedback on moderation practices and philosophy is encouraged, communit It is important for communities that are seeking to make the world better to have clear values, to articulate those values, and to be willing to stand up for them when necessary. Furthermore, since the Nix community is large and ideologically diverse, it is important that there be transparency as to what the community team is trying to accomplish. The preceding paragraphs are an attempt at finding this delicate balance. +The statement of values is meant as a reminder of what we want to strive for, as a community. It's also a tool for community members to reference when discussing the direction of community efforts. Having the statement of values means that, for example, if a community member is suggesting a way to advance inclusion, nobody needs to argue as to whether inclusion should be in-scope for Nix, because the values make it clear that it is. + To those who might oppose any public statement of values: Isn't it better to have it up front, so you don't have to wonder? To those who might say that any statement of values is merely performative and that the proof is in actions, not words: These authors fully agree, but we're saying the words anyway. Please hold us accountable for living up to them. From 001901403560f849633b15e28874c6b03fa47334 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?J=C3=B6rg=20Thalheim?= Date: Thu, 2 Sep 2021 15:53:07 +0200 Subject: [PATCH 13/13] update shepherd list --- rfcs/0098-community-team.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/rfcs/0098-community-team.md b/rfcs/0098-community-team.md index 10bddf62d..c1bd81dd7 100644 --- a/rfcs/0098-community-team.md +++ b/rfcs/0098-community-team.md @@ -3,8 +3,8 @@ feature: community-team start-date: 2021-07-31 author: Irenes (Irene Knapp) co-authors: ashkitten -shepherd-team: (names, to be nominated and accepted by RFC steering committee) -shepherd-leader: (name to be appointed by RFC steering committee) +shepherd-team: @grahamc @spacekookie @zimbatm @7c6f434c @ToxicFrog +shepherd-leader: @zimbatm related-issues: (will contain links to implementation PRs) ---