POND Documents

The files here are taken as the governing documents ("the Documents") of POND. They are not meant to necessarily be complete or authoritative in all respects. Each Document has two important sections: the rules for changing the document, and the limitations of the document (i.e. when the Document should be treated as guidelines or documentation vs hard rules). These Documents may end up out of date for minor details (as defined in each Document itself), but an effort should periodically be made to keep them in sync.

The Documents are as follows:

• Role Structure - Defines the organizational structure of POND, particularly the leadership, and contains details pertaining to the criteria, selection process for, and duties of said roles.
• Policy - Defines organizational policies and procedures. Not every informal procedure or policy will be documented, but the most important ones will, and are considered authoritative except where otherwise specified (i.e. leadership not abiding by them - intentionally or accidentally - should be held accountable).
• The Code of Conduct - (Under Construction, to be added here within two weeks of adoption of these Documents)

Official Documents Not Included Here

The following documents are considered to be official and binding (except where otherwise specified), but are hosted elsewhere for accessibility or convenience reasons, they may also have laxer update policies as noted below:

• The Community Rules - including rules for specific channels - are hosted on Discord, and may be changed by a majority vote of the Planners (with a 2-day review period by the Mediators). These Rules apply to all users. The Rules on Discord are considered authoritative and should not be reproduced in these documents. However, enforcement guidelines referencing certain rules are explored here, as discussing the severity of certain misconduct issues when outlining formal mediation and accountability processes without doing so is rather hard. Rules and processes defined in these Documents are meant to be mostly for leaders. In the case where out-of-date Rules are referenced, the spirit and context of the text as written should be used if the policy is needed before the text is updated to reflect the change.
• Guidelines are encouraged to be provided as accessible, up-to-date documentation of leadership practices on Discord for the benefit of other leaders and/or users. Provided they don't conflict with any hard requirements defined in these documents, they should be considered valid and have no need to be added here. That said, as they're guidelines, they are also not "binding", merely informative.
• The Summaries are very, very cut-down versions of these Documents with the most salient points for quick reference and targeted at the general userbase. These must always be kept up-to-date with the changes to these Documents. In the case where the Summaries conflict with or are less specific than these Documents, these Documents are considered the authoritative text. Changes to the Summaries should be run past other leaders to prevent mistakes, but otherwise don't need a vote to update.
• The Transition Plan is not included here because it's ephemeral, but the initial adoption of these Documents also officially ratifies the Transition Plan as presented to users. It must be followed in the course of restructuring leadership, and prioritizing updates to policies and procedures. TODO: This item should be removed after the Transition Plan ceases to be relevant.
• Other Documents included alongside this Document may define their own exceptions or accessory documents hosted elsewhere.

All Documents must either be a post on the Discord server itself, or easily available from a publicly accessible link on the server, available to all users - there is no penalty for accidentally keeping a Document internal or forgetting to link it, but the link must be posted when the error is pointed out.

Special Thanks

I'd like to thank everyone body who contributed to the original bylaws, while most of the text hasn't survived, I referenced it heavily in making this expanded and easier to navigate version.

Changing These Documents

To add, remove, or alter a governing document, a 2/3 supermajority of the POND Planners is required. Any removed document is considered entirely repealed and must be done with extreme care. Individual documents shall define their own alteration rules within the Document itself.

Any change to any of these documents, including Refactors, should be announced to users.

Refactoring

Documents may be "refactored" with a majority vote of any tier 2 leadership team - as long as text is not substantively changed, the exact wording or organization of these Documents may be altered to correct typos, improve poorly-worded statements, or make them easier to navigate. This includes splitting Documents, combining them, or changing which Document a section is in. Before the vote, refactors must be put up for review by leaders (and optionally the wider userbase or volunteer non-leader users) for at least 2 days. Just for a few pairs of eyes to point out any editing errors or unintentional substantive changes.

Limitations of these Documents

This is not a constitution, we are not a government entity, this does not represent a legal contract between leaders and/or users. While the server users and leadership are making a commitment to abide by these principles and rules, it is ultimately something only enforceable by collective agreement, goodwill, and social forces. No legal action can be taken to enforce this text (although legal action may of course be pursued if leaders violate any real laws). If the leadership becomes sufficiently hostile or ambivalent towards the principles behind these documents, sadly nothing can be done aside from moving on from the community.

In addition, in areas in which these documents are vague or incomplete, decisions will be made based on vibe. Leaders should use their heads to decide the appropriate actions to take, as actual harm done in the course of incorrectly gauging vibe is still subject to accountability processes. These documents cannot and should not cover every possible contingency, as running a community and dealing with people is inherently complex and nuanced. In some cases, updating policies and guidelines to accommodate the situation should be done if it's likely to recur in the future, or if inconsistent decision-making is causing problems or confusion, but not every one-off decision needs to become a formal practice.

Prefer the general to the specific, and respect each others' judgement. When in doubt: check in with other leaders before taking action.

Mistakes

In the case where the text of the Documents includes a clear typo or similar error, the line should be interpreted as intended, not written. While this could be abused, an errant accidental "not" should not yield a full accountability process and investigation when no harm is actually done. Just because a document says "Bigotry is allowed" instead of "isn't" doesn't mean in that context we suddenly allow Bigotry sometimes. Please point out such mistakes so we can fix them.

Technical Mistakes

All Documents may outline specific technical implementation details - such as role permissions, specific bots, or channel structures. In the case where a Document is ratified with a mistaken understanding of the scope of permissions a role needs to fit its description, or a tool's functionality is misunderstood (such as a bot's features being more limited than expected, or requiring a premium subscription), the next-best solution should be implemented so long as it doesn't violate the spirit of the guarantees it's trying to uphold.

As an example: if a bot is used to collect feedback via a form, and the form text is to be redirected to a dedicated forum post in the leadership area - creating a new channel or redirecting it to an existing leadership channel is okay, but redirecting it to a public channel is not. Care should be taken to make the new solution as close as possible to the proposed one (so redirecting to a very active channel may cause something to get buried, as compared to a dedicated or low-traffic one).

If found, significantly better technical solutions may be adopted to replace the outlined solution by a simple majority of the Tier 2 body responsible for managing the policy (typically the POND Planners or Developers).

All such changes may be done without requiring an approved update to the Documents, but they should eventually be updated under the Refactoring rules for simple documentation purposes. The one exception is if the new tool falls under the User Bot Policy, in which case stricter review standards apply.

POND Roles

This section outlines the POND role structure, including leadership duties, privileges, and selection processes.

Rules for Changing The Role Structure

The Non-Leadership Roles section may be changed at any time by a simple majority of the Planners, this document need not be updated to track every little such role change, but it is encouraged to periodically update it just to maintain a useful reference document. Major changes to the leadership structure and duties must follow the general be ratified by a 2/3, 48-hour Automatic Abstention Vote of the entire POND leadership (Tier 2 and Tier 1) after a mandatory 2-day review period by Community Members.

There are some exceptions to this 2/3 margin, the following changes may be made with different processes:

1. Altering the maximum or minimum number of seats - This may be altered by a simple majority of the body increasing or decreasing their seat count - The maximum cannot be lowered below the current number of seat holders - The maximum cannot be lowered if there is an open application to the position (including a held application, see: the Seat Count Guidelines and Misconduct Handling Procedure for Leadership Applications)
   • People with held applications may be asked if they wish to voluntarily withdraw it
   • If there's a reasonable suspicion that a body is decreasing their seat count simply because they suspect a certain user may soon apply and wish to prevent it, an accountability procedure may be initiated
2. Changing the frequency of leadership meetings - This can be altered by 3/4 (rounded up) of all affected Tier 2 leaders, and the Secretaries. This is set at a higher threshold to ensure that the meeting attendance frequency is not increased in a way that "soft-fires" other members of the group (intentionally or accidentally).
3. Minor changes to leadership role names and "flavor text" (i.e. how we summarize their purpose/niche)
   • This is essentially the same as making changes to to Non-Leadership roles, it's so minor there's no purpose in a big spectacle. This document should be updated at some point to reflect it for accuracy and usefulness, but it's not urgent

In addition, the Documents-wide Mistakes and Technical Mistakes exceptions apply.

Limitations of This Document

This document is not 100% authoritative. For extremely minor details (such as the name or exact location of a channel changing, or the exact bot used to manage roles etc.), this document may get out of sync and whatever is being used in practice trumps the text of this document. That said, when such discrepancies are noticed this should be updated to reflect them, just to eliminate confusion.

In addition, as long as leadership role duties don't significantly drift, it's very likely that the roles will naturally grow to better define their duties and practices over time, as long as it's not a radical departure from the general concept of the role as defined here, an issue of accountability or community safety, or a major escalation of role privileges, this document need not always be voted on and changed. There may come a time in which this whole thing needs a major update to reflect the current roles in practice just for documentation purposes, and that's okay. It's fine for things to evolve to better suit our community without a formal process for everything.

However, this document should be considered authoritative in all "substantive" matters - specific leadership structures, prohibited actions, transparency and accountability requirements, measures to keep the community welcoming and leadership positions accessible, etc. If the leadership team is found to not be following these policies, an effort must be made to correct either their practices (including following all relevant accountability measures), or (in minor cases that haven't caused any harm), this document.

Non-Leadership Roles

The New Participant role is granted upon joining the server automatically, and after enough participation (currently defined as reaching Maki Level 4), will be automatically promoted to Community Member. Community Members gain access to the ability to opt-in to the "Support Area Access" role, giving them access to the support channels. Should the user be in violation of the support rules or it is found necessary by a formal conflict resolution process, they may, at the judgement of the Mediators, be stripped of support access and given a role that prevents access to the section.

Users may also be granted the Ticket Mute role in cases where their access to the server at large needs to be restricted, this allows them to talk in tickets but not interact with the rest of the server (including reading posts). Both Mods and Mediators may use this role and pull the user into a ticket.

Other miscellaneous roles may be added or removed as necessary (e.g. pronoun roles, event roles managed by a bot, etc).

Talks Too Much is manually granted to users when they've reached Maki Level 50, and is a joke role.

Voluntary Server Restriction

Users may at any time open a ticket to request to be Ticket Muted if they need a break from the server for any reason, and may end their break at any time. This prevents reading the server entirely, so it can be useful for a complete detox. That said, this should be used sparingly just because it has to be done manually and results in an executive burden on the team, so this isn't an option to replace willpower if you want us to force you to go to bed or study every night etc.

What Does "Local" Mean?

We have no strict definition for "Local" but defining this is a priority after other urgent restructuring items are tackled. In the meantime our fuzzy definition is a that Regular Visitors must visit around twice a year, and an Inbound user must be making active maneuvers to arrive within about a year. Regardless, we ask all users not currently in Portland to respect our space and refrain from talking about their local communities too much, and to specify when their photos etc. are not from Portland or the surrounding area. In particular, it's bad form to compare Portland with your local community too much.

Users Who Have Moved Away

We currently do not kick or restrict active, valued community members who have extensively participated in the in-person community that move away, but we ask them to respect our space as a local one. More in-depth guidelines for users who are no-longer local will be fleshed out alongside the Inbound and Regular Visitor roles. We make the same request as we do with all non-local members re: posting about their new community too much. There is currently no specific role for this, but one may be made in the future. We ask that users who have moved away to change to Inbound or Regular Visitor in the meantime.

Not Local

The "Not Local" role is a honeypot. The server is by definition a local server, so the "Not Local" option during onboarding is meant to trap people who join and have no intention of being a part of the local community. In some cases they may misinterpret the role and end up changing to Inbound or Regular Visitor, but Not Local users may be kicked at any time. If they have been active they may get a kind talking to and a request to voluntarily leave first.

General Leadership Requirements

Leaders must be users with the Support Area Access role (or equivalent). In addition, leaders must not be "Inbound" or "Not Local", they must at minimum regularly visit the Portland area. Tier 2 leadership has an additional restriction of having consistent/reliable physical access to Portland (to attend meetings).

In addition, any prospective leader must have attended at least 5 in-person events, and met several members of the team(s) they're applying to.

If any of these requirements are not met, their application will be voided (this is distinct from rejection - it does not incur the 6-month restriction on resubmitting applications, they may reapply as soon as they meet the minimum requirements).

Finally, the ability to inhabit a leadership position may be suspended or revoked at the discretion of the Mediators during or as the result of a formal accountability process.

Training

All leaders must undergo trauma-informed conflict resolution training, including identification of and security around sharing sensitive information. We commit to establishing specific training procedures within two weeks of this Document's adoption, in which case it will be updated to reflect the results. Since external, non-leadership users are heavily involved in designing our training, this timeline may be slightly stretched to accommodate their capacity upon request, but it may not extend past a month.

Mediators must undergo extra training, which is elaborated on in their own section.

Application

All roles will have public applications. In an attempt to reduce a feeling of "cliquiness", and reduce the bar for attaining leadership positions, the application process is as follows: applications will be directly posted in a #server-talk thread designated for the process - the application is a simple free-form post about what you're applying to and why. Objections will be solicited with an anonymous feedback form. If 0.8% of the current total number of Discord members object to the application within 2 days, the application will be rejected.

Anonymous objections will be handled internally, in case a sensitive accusation is made. The form will have a checkbox indicating if the objection should be considered "sensitive" or not (if Dyno doesn't allow this - instruct users to write a line specifying it's sensitive). That said, discretion may be used to keep the text of an objection in confidence if it appears that someone may have simply forgetten to check the box and it contains identifying details. Non-sensitive objections will be reposted to the application thread. All objections must be anonymously submitted through the form (to prevent a user from submitting both a public and anonymous objection simultaneously - this may change if we find a better process or bot).

Application Staggering

Applicants must wait until the previous application is processed. This is because the objection form will prevent users from submitting multiple anonymous objections within the application window (and it's prohibitive to make a new form for each applicant). If multiple people want to apply at the same time, they're welcome to submit their applications as a single "block" and the same objection form will collect objections for all simultaneous applicants (just specify which applicants you're objecting to in your submission).

A tier 1 leader applying to multiple tier 2 positions is also encouraged to submit all relevant applications at once, to prevent gumming up the pipeline, in which case objectors may elect to object to the application in general, or only specific roles.

The name of the Application thread should be changed to contain [IN PROGRESS] or [OPEN] depending on whether an application is currently in review, or free for submission (until a good workaround is found for multiple simultaneous applications).

Reapplication Timelines

Applications to the same role can only be made by a user once every six months. This means that if you apply to CL and are rejected, you must wait 6 months for CL. This does not apply for different roles - for example, if you are rejected for Mediator, you may still apply to POND Developer/Planner. Please see Tier 2 Roles for more information about the differences in their application requirements.

A user must hold a Tier 1 role for three months before applying to Tier 2 (leadership tenure pre-restructure is included in this timeframe). This requirement is suspended for Tier 2 bodies that are below their minimum threshold of members. Leaders who have had their roles forcibly revoked and eventually rejoin the leadership team will have their time as a leader reset for the purposes of this rule, and will be ineligible to directly apply to a Tier 2 position before the 3 month tenure requirement regardless of the number of filled seats.

Leaders who have their positions revoked, or their ability to submit applications restricted, must also wait 6 months from the application of the punishment to reapply at minimum - harsher consequences may be applied if necessary.

Serious Accusations of Misconduct for Applicants

In the event of an anonymous accusation of misconduct, we will announce that we received a very serious complaint (without details). However, due to the principle of "Do you really think someone would do that? Just go and tell lies on the internet?" The system is too easy to abuse anonymously. As such, we will give the accuser(s) a couple of days to file a formal complaint with a mediator - in which case an investigation and conflict resolution process will be launched. The leader's application will be treated as "on hold" until the investigation is concluded.

In the case where the accusation appears to be substantiated, and a positive resolution cannot be reached, the application will be rejected even if they otherwise passed the objection threshold.

In the case where the accusation appears to be spurious, or a positive resolution to the conflict is reached, the application will be treated as normal.

If the accuser does not come forward, the objection will be counted as a normal objection. Should the complaint be genuine, the user may always come forward at a later date when they feel more comfortable to launch an investigation process, and the regular mediation process for members of the leadership team will be used.

ℹ️ - We do not have a clear definition for "serious complaint", but for the first rounds of applicants it will be treated as anything to the level of abuse, bigotry, assault, harassment, stalking, etc. I.E. egregious violations of rules 1 and 2, or clear and egregious community safety violations. The team commits to adopting a formal policy for this within two weeks of the adoption of this document.

Acknowledged Process Limitations

We have no ability to prevent conflicts of interest, mere personality clashes, and undue bias from submitting valid-seeming anonymous objections to leadership apps. The best we can do is set the bar for approval at a level where a few complainants acting under such circumstances won't drastically sway the outcome.

People may be able to figure out who someone is from context or writing style, unless the out themselves of their own volition, they are not to be outed or investigated under the anonymous submission policy outlined in the Policy Documentation.

Rejection of Rules-Violating Objections

If an application receives an objection that violates our rules - especially our rules about bigotry, it will be rejected. We intentionally do not have a clear line for what counts as "bigotry" for this nor Rule 1 in general because by its nature it can be hard to define, and any clear line drawn can be maliciously used to just barely not violate it (particularly when dog-whistles are involved).

We acknowledge that care must be taken in the grey area between ableism and legitimate concerns about mental health and how it relates to the leadership position - a more concrete process for differentiating these cases will be drafted after the initial restructure.

Fiddly technical details about how we collect anonymous objections

Anonymous objections are collected via Dyno form. They will be automatically sent to the leadership area, and will be shared by a leader when non-sensitive. If marked as sensitive, the complaint will be immediately escalated to a Mediator assigned to handle the conflict. In cases where a user is still uncomfortable with this, they may DM a Mediator at their discretion, and the Mediator will be obligated to start the investigation process and keep the complainant anonymous even from the rest of the leadership team.

Leadership Re-Application Requirement Immediately Post-Transition

The old-structure CLs and Moderators will inhabit their chosen roles upon adoption of the first version of this document as "interim" members of their chosen bodies, and must immediately (re)apply to their positions. This will be treated as one massive application block sharing a single objection form. This is probably going to be a bit obnoxious, but is the only way to handle this large of a task expediently, but also without giving ourselves a free pass to avoid the same community approval process every future leader must go through.

Just make it clear who you're objecting to - and for which role(s) - in your submission. Ideally on a different line for each one so it's easier to read and aggregate.

In case you accidentally submit your form and realize you forgot an objection, DM an interim leader you trust and they'll sort it out for you.

In the case like every current member is rejected we panic, we have zero way to plan for this eventuality. It probably won't happen.

Leadership Meetings

Every Tier 2 branch will hold a monthly Leadership meeting - this meeting should be on a consistent recurring schedule (e.g. "3 PM on the first Saturday of the month"). All Tier 2s, are expected to attend every meeting (almost - vacations and emergencies happen, we're not monsters). Leaders are generally expected to attend in person, but remote attendance is allowed if necessary. Meeting times and locations should be selected so it's easy for all required attendees to physically travel to the location.

Tier 1s are encouraged to attend meetings matching their opt-in roles, but are not required attendees and do not have voting power at said meetings - as such scheduling and location selection is not required to accommodate them.

Every 3 months, all Tier 2 leaders will have a joint meeting to sync up and make sure everybody is on the same page. All Tier 2s are required, and Tier 1s remain optional. This may or may not end up replacing the other leadership meetings that month (TBD - we'll play it by ear to see if the meeting cadence is too demanding).

Leaders may, of course, elect to have extra meetings or working sessions as they see fit.

Secretaries are also required to attend the meetings for the bodies they're assigned to, see the role description for more details.

Accountability and Misconduct

For more preliminary rules on accountability and misconduct processes, as well as conflict resolution processes, please see Accountability & Mediation in the Policy Doc - to be fleshed out immediately post-restructure.

However, serious accusations of misconduct will result in temporary suspension from the all leadership positions until the conflict resolution process yields a positive resolution. Some other egregious internal rule violations (again, to be worked out post-restructure), even absent interpersonal conflicts requiring mediation, may undergo a similar process.

Onboarding

In addition to training, there are expansive onboarding resources [...]

Plural Leaders

Plural users who apply for and enter leadership are encouraged to be clear about which system members are (or are not) applying for leadership. Objections to applications of systems may specify if they don't want specific system members to be in leadership, instead of rejecting the system as a whole entity.

Due to the complexity of managing such a situation, system members may not occupy different sections of leadership (i.e. one member can't be Developer while another is Planner), all approved system members considered any form of leader are considered to share all approved positions collectively.

Plural systems in leadership still only get a single vote, and only count as a single seat in Tier 2 bodies. Prolonged fronting by unapproved system members will cause them to be forcibly placed "on break" until an approved system member is available. For short-term fronting (around one day) unapproved system members are requested to refrain from using leadership channels, except to pass on important messages by the request of approved members. Unapproved system members may not participate in Mediator duties at all.

Blends/fusions of system members containing both approved and unapproved system members simultaneously, as well as new system members that form after the approval process, will be considered approved leaders by default (for simplicity). To counterbalance this, at their discretion, the Mediators may by majority vote remove individual overly-disruptive members/blends from approved leadership - be it temporarily or permanently - so long as they do not remove the entire system, which requires the normal formal accountability process. Artificial restriction of a system by stripping leadership from, say, almost all system members who front regularly without good reason may be found to be an abuse of power in some circumstances.

Systems whose approved members cannot or do not front regularly enough to reliably execute their duties may be found in nonfeasance collectively, especially in Tier 2 roles, and have their whole system's roles removed like any similarly unavailable singlet leader.

In general, actions taken by unapproved members as users do not reflect on approved members' character where leadership is concerned. Unapproved system members also may not take away approved system members' agency (such as by "resigning" for them). However, in extreme cases, systems with sufficiently disruptive, chaotic, or malicious system members may sadly have to be removed from leadership entirely, even if the rest of the system contains very good leaders - especially if the disruptive system members make a habit of abusing leadership privileges they shouldn't have access to.

Official Leadership Actions

This sections outlines all official actions and powers that are common to all POND leadership.

Discord Powers

All leaders at minimum have access to the following: pins, timeouts, role management (only used for Ticket Mute unless Tier 2), message deletion, and bans. Minor/specific permissions may change as defined in the Role Alteration guidelines. However, unless one is a Moderator one should not use moderation powers (barring a very good reason, such as timing out a user late at night when no mods are online).

As all Tier 1 positions are opt-in by a simple at-will reaction role change, it doesn't make sense to limit these permissions to the sub-roles (it will make the roles tab messy and channel specific permissions too hard to manage - and a hypothetical CL working in bad faith could get the powers with a simple reaction anyway). That said, a leader abusing roles such as improperly using mod features, will force at least a temporary leadership role removal, and a requirement to go through a formal accountability process.

If abuse of this system becomes a recurring pattern, restricting access to the permissions and attached roles may be considered, but unless and until that proves necessary, users are encouraged to keep in mind that any leader will technically have access to these permissions when reviewing leadership applications.

All leaders also will have access to all tickets. They are bound by the Policies regarding ticket information security, but more importantly - compared to the old system, this reveals significantly less sensitive information (as sensitive matters are handled off-server).

Resignation

Leaders may resign at any time, for any reason. To resign they should open a ticket and formally submit a statement of resignation with as much or as little detail as necessary.

NOTE: Resignation is different from going On Break

NOTE: Due to stupid technical details with our ticket system, former leaders have to manually leave Every. Single. Ticket. they were in. Leaders who resign from the leadership team in its entirety are required to do so, and will be manually removed in short order they don't. If the leader was in a particularly large number of tickets (very likely if they've been a leader for a long time), leaving and rejoining the server might be the most expedient. We hopefully will adopt a new ticket system without this problem relatively soon, but it's lower priority than many other tasks.

We recognize two types of resignation: Resignation on Good Terms and Resignations of Protest.

Resignation on Good Terms

Resignations on Good Terms are defined as resignations due to life circumstances such as stress, moving away from the area, or simply lack of interest or capacity. Which is to say, making a decision to resign for the good of oneself or the community, with no hard feelings.

For Tier 2 leaders in particular, leaders who are retiring on good terms are humbly requested to participate in a knowledge transfer and torch-passing with the remaining leaders and/or new leaders who take their place. They should be open to occasional requests to clarify old procedures, or decisions. These are not requirements, especially for resignations due to circumstances like ill health, but retiring leaders should be aware of the expectation.

Leaders who submit a good-terms resignation will be barred from reapplying to their position for 3 months - this is to prevent putting undue strain on the application process, and discourage role chaos. There is a grace period of a week to change your mind, where you may be reinstated without an application no questions asked, unless someone was already approved to take your place as a Tier 2. This privilege to change your mind is only afforded once per year.

Leaders who resign on good terms will, barring an explicit request to the contrary, be given a kind farewell and "thank you" announcement, with an optional personal statement from them to the userbase about their departure.

Resignation of Protest

Resignations of Protest are defined as resignations due to large disagreements with the rest of the leadership team, such as resignations due to a perception of widespread malfeasance.

When resigning this way, no expectation to transfer knowledge or be available to help new leadership will be solicited, of course, but there is also no grace period to change your mind due to the emotional intensity of the situation. A leader who resigned in protest may reapply as normal after the 3 month waiting period. However, if a leader resigns in protest twice, they may not rejoin the team, as they clearly have irreconcilable disagreements with it.

Leaders who resign in protest are not restricted from expressing their concerns to the server (provided it's restricted to the appropriate area - #server-talk), and are encouraged to open a formal mediation process if they still have faith in that part of the leadership system. They are also permitted to use any of the regular User Checks Against Leaders without restriction.

Leadership departures of this nature may or may not get an announcement depending on the wishes of the resigning leader, but in the case they wish to pursue the situation in #server-talk, an announcement acknowledging that a leader resigned in protest and a pointer to the resulting thread is required at minimum.

NOTE: Leaders who resign this way are not "untouchable". It is foreseeable that someone could, for instance, use such a frenzy to cover up their own abuse of power. Or flagrantly break various server rules while talking about their resignation. This is likely to get messy and cannot be planned for exactly, but it's worth noting that they are not blanket immune from official server disciplinary procedures, including removal of posts or a ban, regardless of the optics of taking such action. This caveat should be used as a last resort and only in the most extreme cases, so as not to silence legitimate dissent when emotions are running hot.

Resources for Leaders

This is a list of all resources leadership should have access to:

• POND Staging - a server where we test out bots and new ideas without affecting the wider server.
• Onboarding Resources
• POND Portland Github - All Leaders should have membership to this - all Planners should have owner privileges. (If desired)
• MEDIATORS ONLY - A list of Conflicts of Interest as per TODO

Going On-Break

Any leader of either tier may go "on-break" at any time - for any (reasonable) duration. This will remove the user's leadership roles, grant them the honorary "Leader (On-Break)" role, and revoke access to leadership chat and tools. Leaving the server will be considered "on-break" unless a formal resignation is submitted.

As of now, Leaders may go "on-break" as often as necessary, and for any reason.

That said, within two weeks of the adoption of this document, we commit to deciding on formal guidelines for:

• A threshold of "excessive breaks" (both in length and frequency)
• What happens if the number of members in a Tier 2 body dips below its minimum size due to the break
• "Abuses" of the concept of a break (such as a Tier 2 conveniently taking a break every month to dodge a meeting)
• As Mediators on break pose special challenges, potential special procedures if a Mediator goes on break (especially if all existing Mediators have a conflict of interest in a situation)

All of these situations will need guidelines put in place and the work will be done on this during the internal policy reform immediately post-restructure, with this document updated to reflect that.

For any votes, the On-Break member will be considered as abstaining.

NOTE: Due to stupid technical details with our ticket system, leaders have to manually leave Every. Single. Ticket. to lose access. On Break leaders are not expected to do this (but obviously cannot participate in them). We hopefully will adopt a new ticket system without this problem relatively soon, but it's lower priority than many other tasks. That said if On-Break leaders want to leave tickets for a more relaxing vacation, they are heavily encouraged to do so.

NOTE: Due to Discord limitations, the Server Owner has a few caveats when going On-Break, explained in their role section.

POND Leadership Roles

This section is an outline of all leadership roles.

We have three classes of roles: Tier 1, Tier 2, and Miscellaneous Roles. The latter are largely roles that act as accessories to existing roles.

Tier 1 Roles

These roles are "Tier 1" roles - which have less responsibility and are less "intense" positions. When someone applies, they apply to the Community Leader (CL) position, which is an "umbrella role". As such the terms "Tier 1" and "Community Leader" are roughly interchangeable. CLs may opt-in or opt-out of the three sub-roles (Community Organizer (COs), Community Representative (CRs), or Moderator (Mods)) at will - though excessive switching is discouraged.

All Tier 1s may see all currently active leadership channels, regardless of roles - this allows them to give input on some isolated proposal they really care about without having to temporarily declare themselves a CR, for instance.

In the event a CL is found to not be active in executing their chosen roles ("nonfeasance"), they'll be asked to stop labelling themselves with the sub-role until they have the capacity to do so. There are no ramifications for this, since the roles are merely a declaration of how one wants to use their leadership position to improve the server. CLs must have at least one specific Tier 1 or 2 role at any time, or they'll be at minimum considered as "On Break".

All Tier 1s also have a specific power not available to Tier 2s: at any time they can vote to force any Tier 2 leader to undergo an accountability process, including removing them as leader temporarily or permanently.

Tier 1 Vote to Hold Tier 2 Leaders Accountable

All Tier 1s also have a specific power not available to Tier 2s: at any time they can call a vote to force any Tier 2 leader to undergo an accountability process, including removing them as leader temporarily or permanently.

Community Leader

This role is an "umbrella role". As such, the vast, vast majority of its privileges are defined in the sections above (Tier 1 Roles as well as the general leadership Powers and Requirements.

Its main purpose is to ease the application and role management process, as the Tier 1 roles are all low-stakes and low-pressure enough to opt-in.

The bar for leadership is set low enough that the vast majority of users can become CLs with no issue, and there is no membership cap. Becoming a CL is nothing more than opting in to the backend information firehose, and a commitment to contribute to the community. The entire community can be CLs if they want as long as they regularly perform their opt-in duties.

Moderator

The Moderator ("Mod") role is extremely different from what the role used to be. While previously Mod was a mix of this and every Tier 2 role, it now simply deals with the day-to-day moderation of the Discord chat. This includes things such as sweeping topics into their appropriate places, banning basic spammers, setting the tone, and reminding users to tone down conversations that are getting too heated. Moderators do not handle major interpersonal conflict resolution (i.e. things more serious than breaking up minor squabbles in chat) - that is the job of the Mediator role, which can be considered the more intense version of this role, with more stringent requirements.

Moderators are also encouraged to report back to the leadership team (especially Mediators) with concerns and observations about users who are regularly skirting the rules (in spirit or letter) or values of the server. They (along with Mediators) are encouraged to give input on or proposals for new or modified rules and policies to the POND Planners and CRs when they identify repeated rule or cultural issues that may require new structures to mitigate.

Community Organizer

Community Organizer ("Organizers" or "COs") are the worker bees of the server, and very focused in particular on the event planning aspect of the server. While COs (just like regular users) may have their own projects and recurring events, their primary job as a leader is to pick up any tasks delegated to them by the POND Developers (which is the more intense version of this role). They are also expected to mentor regular users on how to make successful events, as well as help them plug their events and make them happen (e.g. if people are stuck on scheduling, COs should step in the help people decide on a concrete time and date).

Community Representative

Community Representatives ("Community Reps", "Reps", or simply "CRs") are meant to give feedback and propose improvements for the general direction of the community. This is essentially an advisory role, mixed with a bit of a responsibility for helping execute more "backend" tasks. CRs will be regularly presented with proposals for the direction of the server and asked to give feedback, flesh out language, etc. At any time, CRs may also propose their own measures, and if approved by a majority of CRs, the Planners are required to at least consider and vote on it.

This could include things such as fleshing out the rules and purpose of a new channel or section, or even giving feedback on proposals for new long-term goals, recurring server traditions, "branding" decisions (e.g. server art contests), and so on. They are considered the less intense version of the POND Planner position.

Community Leader vs Community Organizer

A good question is why we split COs and CRs, when they could be combined into the same role. Particularly when the distinction between the kinds of things CRs and COs are meant to help "execute" isn't always going to be clear.

This was initially considered, but 2-3 members of the leadership team, as well as 1-2 regular users in DMs, expressed that they have high bandwidth for executing on concrete tasks, but low bandwidth for things like debate, discussion, planning, and giving feedback on proposals. As such, the CO and Dev roles were created to separate the execution and approval/proposal/planning process. Rather than make one role with a bunch of fuzzy optional duties, it makes more sense to just make two roles with clearer duties, even if there's some redundancy. There will likely be quite a large overlap between the COs, CRs, Developers and Planners, and that's okay.

Remember that any leader can opt in or out of any Tier 1 role at any time, so the fact that these are not perfectly clearly defined is not a major issue. These Tier 1 roles are a declaration of how you want to contribute, not a set of assigned duties.

That said, a good rule of thumb for whether it's a CO or CR job is whether it's working on something abstract like a formal proposal for Planners to vote on (CRs), or something concrete, in particular the concrete implementation of a proposal that was already passed by the Planners or coordination of in-person events (COs). The precise nature of what kinds of tasks these roles handle will probably differentiate naturally over time.

Tier 2 Roles

Tier 2 roles are higher intensity roles than the Tier 1 roles. In particular, every Tier 2 role has at minimum a requirement to respond to leadership-related pings, give feedback, and submit votes within 24-hours unless On Break. In exchange, they are given voting power on resolutions within their specific body. As outlined in Leadership Meetings, they also are required to set the agenda and attend regular leadership meetings.

People may be and are encouraged to be multiple Tier 2 roles, but a separate application is required for each. In fact, the POND Planner group is required to have at least one Mediator and at least one POND Developer on it, to make sure that new proposals and resolutions for the server direction don't make the other bodies' jobs harder, or stretch their capacity too thin.

All Tier 2 roles also have the duties of their matching Tier 1 roles.

Technical Permissions

All Tier 2 roles have the Discord "Administrator" permission, meaning they can in principle perform any action shy of server deletion or managing other admin roles, as well as see all threads and channels. While most info in leadership chat is non-privileged (especially since mediation is moving to a DM-based process), this shouldn't be a huge deal, but they are expected to be more diligent about sensitive information in accordance with their training, and the leadership rules and guidelines.

Seat count guidelines

All Tier 2 roles have a designated minimum and maximum number of seats (outlined in their specific sections). If a role has fewer members than the minimum seat requirement, the application delay is suspended - allowing CLs to apply to it even if they've only been a CL for under 3 months - this allows a user who wants to step up to immediately apply to both positions to inhabit the role, though this requires fairly intensive onboarding and training timelines.

Tier 1s may apply to a body which is at its maximum number of members, and an honest discussion must be openly had about whether any of the current members should retire - for instance because life is getting too intense, they're starting to lag in their duties, and so on. While of course any leader can resign at any time, historically, people have been reluctant to resign because they're worried their work won't get picked up - this allows the conversation to happen at a time when they can be sure their duties won't go unfulfilled. If nobody feels it's time to resign, the application (should it be successful), will be stored, and the applicant will be given "right of first refusal" should a position open up in the future (processed in the order of accepted applications).

Mediator

This is the most sensitive role, and is essentially the most sensitive aspect of what the old-structure Mod team handled. Mediators are meant to handle advanced conflict resolution between members, especially major incidents such as stalking, harassment, etc. While all leaders are expected to be aware of conflicts of interest, mediators in particular have to manage these very well, and are expected to recuse themselves in many more circumstances.

In addition to the training general leadership must have, Mediators must go through regular conflict management, restorative and transformative justice training, and improve their skills in these areas. This is to prevent harm as much as possible when handling such conflicts.

Mediators are responsible for facilitating formal conflict resolution processes between members, as well as handling such accusations against leaders. They are encouraged to handle these processes in group DMs, because of the expanded access general leadership has. Mediators are required to submit regular summaries and updates on the progress and/or resolution of any conflicts that they are mediating, at a level of detail that's comfortable to the involved parties.

Mediators also handle "interventions" with members - such as members that are constantly bumping up against the spirit of the rules or community, or to open a ticket to check in and intervene if somebody's behavior is concerning or regularly bringing down chat. They are not meant to be trained mental health professionals, and these check-ins should not be construed as a formal mental health crisis intervention, but rather a way to clarify the server boundaries, and point them to our resources for such things.

They also should be more involved in giving feedback and input on things that affect the interpersonal and "squishy" part of the userbase - such as Mental Health Crisis resources and policies.

Availability Requirement

Mediators must have the server set to open DMs, and must take care to make sure no one user is blocked by every Mediator, since DM access to them is important to initiate sensitive complaints. Mediators should tell each other when they block someone, just in case. That said, if every Mediator wants to block a user, this likely constitutes a conflict of interest on the part of the whole team in the event they need to mediate a conflict with said user - and is subject to the CoI policy, specifically the process for selecting alternate Mediators. Said Mediators are expected to graciously forward the complaint, despite their distaste for the user, and failure to do so will be considered an abuse of the position and subject to an accountability procedure.

Seat Count

Minimum Seats: 3 Maximum Seats: 4

The mediator count is low because high-stakes conflicts don't come up that regularly, so in many cases they won't have much to do aside from plan and undergo training; submit reports, feedback, and proposals to the Planners; and organizing meetings. 98% of the time, these will be interchangeable with regular server moderators.

There are special rules for situations where no Mediators are eligible to mediate a conflict outlined in the relevant section on Mediator contingencies.

POND Developer

The POND Developers are the project managers and doers of the server. They are expected to have at least one long-term project they're managing - whether that be working towards a long-term goal or recurring traditions and events. The bounds of this are limitless, and could be anything from doing the legwork to scout out physical third spaces, to managing a monthly gathering of some form.

POND Developers are empowered and encouraged to delegate pieces of large tasks to COs, and even interested non-leadership users. For example, they can post in a public "work board" or thread that they need a CO or user to call around and pick a location in a certain area for the monthly gathering.

POND Developers are unlikely to "vote" within their group very often, but some larger projects may need votes on how best to allocate resources and labor, or how to prioritize tasks and plans that they need to execute.

They should also give feedback to the Planners about whether they have the capacity to enact newly proposed plans before they pass, as well as give feedback on what kinds of longer-term projects they may want to do. Note that not all long-term projects necessarily need to be proposed - Devs (as COs, as regular users) may of course manage their own recurring events and such. It's only in the cases of establishing "official" server traditions or very specific projects such as commissioning new art, distributing official fliers, or planning for some theoretical pie-in-the-sky idea like incorporating as a Non-Profit or securing a physical location for our community that they need to explicitly get approval and more in-depth plans approved and drafted by the Planners.

Developers are also the first line in empowering regular users to make their own events. Any user that has a question on how to make events should take it to the Devs, and the Devs should mentor them. Devs should draft guidelines that show users how to make events, and what kinds of events succeed. They should be proactive in moving theoretical plans to concrete plans, and on the lookout for people that are getting discouraged due to events falling through and help users solve those problems.

Seat Count

Minimum Seats: 4 Maximum Seats: 10

The number of seats for Developers is both broad, and has a fairly high max, because each Developer is at their heart just a person who wants to nurture the community and do things to make it the best it can be. The community needs as many Devs as we have big things to be executed and managed. This number is the most likely to be tweaked upwards if there ends up being a ton of interest in the position, and applicants have a very strong proposal for the kinds of projects they want to do.

POND Planners

POND Planners are our backend Amateur Professional Volunteer Opinion Havers™. They're meant to take a long-view of the community, and steer its direction. Planners should have a finger on the pulse of where the community wants to go and propose and workshop ideas to make it a reality.

Planners should be comfortable with the community's culture and workings, and be able to separate useful from unactionable feedback, as well as identify and disregard feedback that goes against the character of the community. Importantly - Planners should be able to drill down into even "bad" feedback and extract the core idea and problem at its heart, and be willing to solve that even if they don't address the exact feedback as requested.

While the POND Developers are the "doers", the Planners do have some concrete duties besides proposal, debate, and voting. In particular, Planners should be active in tasks such as "drafting language" - rules, guides, resources, descriptions, etc. In addition, Planners are likely to be the ones executing some of the simpler tasks for the ideas they pass - such as creating new roles or Discord channels. However, any large enough task, even ones such as this, may be sent over to Community Developers so they can be responsible for breaking up and delegating the work.

Planners are not only allowed, but encouraged to inhabit other leadership roles, including other Tier 2 roles. Planners should have a pretty good idea of what's going on with the community, and be actively involved with it beyond an abstract, theoretical level. Having such responsibilities mitigates the predisposition to pass subpar measures due to losing touch with the more "practical workings" of our group.

Seat Count

Minimum Seats: 3 Maximum Seats: 6

The seat count is set pretty high due to a need for a variety of perspectives, but the max count is set much lower than Developers due to a "too many cooks" element. Too many people in a planning role can cause gridlock due to everyone having to give feedback, and trying to accommodate said feedback. While formal processes such as voting deadlines are in place to mitigate such gridlock, preventing the team from growing beyond a certain size is very helpful extra step in mitigating this.

In addition to the simple minimum and maximum seat requirement, there is a requirement that at any time at least one Planner must also be a Mediator, and one must be a Developer - if a single Planner is both a Dev and a Mediator, they cannot fulfill both requirements at once, at least one other Mediator or Developer must be a Planner as well.

Miscellaneous Roles

These are leadership roles that don't strictly fit into the tier structure, but act as accessories to them in various ways.

Server Owner

Due to how Discord works, we must have a server owner. It's against the Discord TOS to share an account for this purpose, so a specific person must be appointed, unfortunately. Since roles that have Administrator permissions can only be added or removed by the owner, the owner is solely responsible for executing role changes for Tier 2 members - including promotions, demotions (temporary or permanent), resignations, and the "On Break" status.

Due to the nature of Server Ownership, the owner must be a Tier 2 leader, in the event the owner leaves all Tier 2 roles for any reason, they will have to transfer ownership. Server Owners may still go "On Break", but because of the features of ownership, they will not lose access to leadership areas - but are nonetheless expected to not participate until their break is over.

In the event the Server Owner is the subject in an accountability or mediation process, they must immediately transfer ownership (except when the entire leadership team is indicted at once as per the User Petitions).

Secretary

We will have exactly three Secretary positions. These are pseudo-Tier 2 roles but don't fit neatly in that structure. There's one secretary at any given time assigned to each Tier 2 role. As such, they do need to submit an application for the position indicating which team they're working with.

Secretaries are expected to attend all meetings for the body they're part of, and regularly generate reports both to give updates to different arms of the leadership, but also keep the general userbase informed with meeting minutes, summaries of recent decisions and initiatives, and similar announcements. Due to the note-taking, Secretaries do not have voting power, and are expected to minimize their contribution to discussion (because it's very hard to take notes while talking and thinking about what you want to say).

A Secretary may, occasionally, ask another Tier 2 leader on their team if they can trade duties for one meeting, in which case they will be treated as a normal member of the body for the duration of said meeting, while the person taking over their duties is treated as Secretary (i.e. the Secretary gains voting power and full discussion privileges, and the assignee loses them). Secretaries should use this sparingly.

In the rare event the Secretary is On Break for a meeting, another team's Secretary will be asked to fill in, and failing that, another leader will be asked to step up for that meeting. In the event nobody voluntarily steps up Tier 2 members in that group will select a Secretary among themselves randomly.

While a Secretary may be a regular member of another Tier 2 position, they may not be Secretary of more than one Tier 2 body at a time.

As Secretaries are a key component of our transparency initiatives and communication with users, they have fairly strict activity requirements, and a failure to meet their duties will result in their replacement very swiftly.

Very Boring Backend Channel Role Permissions

The currently in-use leadership channels are visible to all leaders, regardless of tier. They may also post in all such channels as needed. Tier 1 leaders are expected to not vote in the voting log (unfortunately Discord only allows restriction on adding new reactions - not stacking existing ones). While the user notes channel is available to all leaders for minor and obvious tracking of concerns about various users, Mediators are heavily recommended to keep particularly sensitive user information in an off-server location provided it complies with our Infosec Policy.

Care must be taken by Tier 2 roles to remember that old archived admin area have posts that happened pre-restructure and are under different, more strict information security rules.

Server Mascot

This is your reward for getting this far, a lame joke role we're not actually going to ever make.

In the event someone attains all tier three leadership positions at once they automatically get promoted to the only Tier 3 role:

Server Mascots lose all voting power, and all leadership privileges, but are required/empowered to come to every monthly gathering in a frog costume.

Policies and Procedures

Rules for Changing Policies and Procedures

This Document follows the General Document Change Policy. Currently there are no exceptions, but some might be made for specific enforcement guidelines to make developing our guidelines easier.

Limitations of this Document

This Document is not complete, and since humans and community management are complex they cannot be expected to be so. We will do our best to abide by the spirit of the rules here when there's no letter, and this Document should aim to be flexible rather than prescriptive, particularly where complex or low-stakes topics are concerned.

Voting

Votes are done primarily by Tier 2 leaders within their own bodies, though some votes may specify different methods of approval, or different groups of leadership (such as all Tier 2 leaders, or all leaders in general).

In general, proposed resolutions that need to be voted on have a hard deadline of moving from drafting -> voting by the next leadership meeting. This mandatory vote is permitted to be a simple vote to table the resolution, or extend the deadline. Proposals whose votes are routinely delayed should be audited to see if perhaps there's an alternate path or something more urgent to prioritize.

Tier 2 leaders can declare voting deadlines at-will for their own proposals and initiatives, so long as the proposal has been posted or in discussion for at least a day, and the voting window is at least 24-hours long (since all Tier 2 leaders must review and vote within that timeframe). As soon as a vote passes the acceptance threshold, it may be implemented without waiting for straggling voters. After a vote has passed, people may not change their votes (but stragglers should still record their votes for the record, and to prevent an implication of nonfeasance).

The Role Structure Document contains more in-depth info on voting requirements, abstention, and who is allowed to vote. The Conflict of Interest Policy also contains a few provisions for vote eligibility.

Automatic Abstention Votes

"Automatic Abstention Votes" are a specific type of vote involving Tier 1 leaders. An Automatic Abstention is a vote that dictates that within a specified timeframe (typically 24 to 48-hours), anyone who hasn't voted is automatically considered to have abstained. This is used because Tier 1 leaders have no deadline to check in or vote regularly.

There is no quorum for voting, to prevent pocket vetoing by a small dissenting group that otherwise could not reach a majority refusing to vote.

Technically speaking, all votes are Automatic Abstention Votes, it's just that Tier 2 leaders that "abstain" this way more than a few times are liable to lose their roles due to nonfeasance. Tier 2 leaders should instead explicitly declare their abstention.

Mandatory Review Periods

Whenever a rule for changing a Document or otherwise collecting feedback specifies an "x-day review period", this means that, prior to the ratification vote, the changes must be offered to the specified bodies for the full duration to collect feedback (so 2-days is exactly 48-hours). The reviewing members don't vote on the resolution, but their objections should be discussed (even if ultimately discarded), and minor typos etc. fixed, before the vote commences. A formal vote must commence ASAP after the 48-hours, and objections voiced after that window will be discarded, to prevent eternal bike-shedding and fruitless attempts to make everyone happy.

In the cases where objections feel substantial, the owner of the proposal may elect to instead submit a vote to have time to revise the proposal, but the vote may not be cancelled entirely.

Recently Appointed Leaders

Recently appointed leaders may not vote for a week after joining as they should focus on training and onboarding, and are likely not familiar with the proposals and goals of the leadership team yet. This is waived in the case of Mediators who join the team by request due to an emergency situation.

Secret Votes

In the case of sensitive disciplinary measures, Mediators may occasionally need to vote on topics where they may feel uncomfortable about their decision being public. They may use any tool they choose to conduct the vote in private, and the only documentation required is whether the vote passed or failed - without specifying the pass/fail margin or choices of individual members. This privilege should be used sparingly.

Conflict of Interest Policy

A Conflict of Interest (CoI) is defined as a relationship or interest that may cause a leader to either feel forced to not vote their conscience, or suffer undue bias due to their personal circumstances or relationships.

Due to the nature of our community, the vast majority of our conflicts of interest are going to be close relationships with other users. Whether a CoI is relevant or not depends on the severity of the CoI, and the context of the measure being voted on. Leaders are expected to be aware of their conflicts of interest, and actively declare them and be willing to recuse themselves as necessary

Recusal

For our purposes, recusal can be declared at six levels:

1. A bias is declared for posterity, but is not considered severe enough to warrant disengaging from the topic
2. A commitment to not vote on a certain topic
3. A commitment to not be the primary point person on a project, proposal, or accountability proceeding
4. A commitment to abstain from engaging with or commenting on a project, proposal, or accountability proceeding altogether
5. A request to not be involved in any way with the topic at hand, including being privy to as few details as possible
6. The leader is directly involved in a situation under mediation, and will be engaging as if they were a regular user

Leaders may recuse themselves at any level (except 1) without specifying the reason, in case it involves sensitive information they'd rather not be public knowledge. Leaders are heavily encouraged to withhold the recusal reason in cases where it involves sensitive private matters or traumatic incidents.

In cases where the gravity of the reason is so heavy it might bias the other leaders' judgement just by hearing it, openly revealing such info in the process of declaring a recusal will itself be considered a violation of the CoI policy, and a failure to properly recuse oneself. If one wants to air such information, they must do so in the course of a formal mediation process at their own pace and comfort level. Such violations will generally receive much lighter consequences than other failures of recusal, unless they happen repeatedly.

Carrying Out and Recognizing Recusal

Level 1

Level 1 is technically not a recusal, but just an informational heads up. The vast majority of "CoIs" for non-mediation situations will fall into this category, given those duties tend to not involve very sensitive topics.

Levels 2 & 3

Recusal methods 2 and 3 are relatively straightforward and easy to enforce - it's easy to check whether the person voted, and whether they were the person in charge of the process. That said, even if a person is not the "point person" they may still be in violation if they contributed overly-much despite not technically being the "owner". Benefit of the doubt should be given in most cases, but extreme or repeated mistakes of this variety may end up triggering an Accountability Process.

Levels 4 & 5

Recusal method 4 requires the leader to not engage with the topic whatsoever, including not giving input at meetings while the topic is being discussed. Recusal method 4 should be handled in a group DM off the server, with only a summary being posted, to minimize the information the leader receives. Leaders who are abstaining at level 5 or 5 are also required to not talk about the process privately with any other member of the leadership team directly involved with handling the situation, to avoid influencing the decision indirectly.

Level 6

Level 6 represents situations where a leader is involved in a sensitive situation directly. If the leader is under investigation, they may have their leadership suspended during the process (see Mediation); however, if they are a witness, victim, or support person, they may simply be forced to act as a user within the context of said process. In this case, they are essentially at level 3 recusal, with the caveat that they are allowed "commentary" in the same way as any other user giving testimony, rather than input from a leadership perspective. In such cases, they are still barred from discussing the situation socially with the Mediators responsible for the conflict.

Record of Potential CoIs

After "Phase 2" of restructuring, Mediators are excepted to compile an internal, private Document of all significant Conflicts of Interest for the whole leadership team. This document should be internal to the Mediators alone (which is to say - hosted outside the server entirely) to prevent leaders from being able to pry into intimate details about everyone's personal relationships or trauma. [TODO - Update this after it's done]

Mediators who mention (privately or publicly) CoI information that's not very, very obviously open knowledge to the involved parties will immediately have their role temporarily removed and put under an Accountability Process, which will at minimum result in mandatory leadership retraining. More severe situations may result in more severe penalties - starting at being prevented from holding a Mediator position for a minimum of 6 months. The leader is still bound by these rules if they resign from leadership, though different consequences may need to be enacted.

This data is collected via interview - that is Mediators should not become private detectives to compile this list, simply asking all leaders is sufficient. Mediators are not to document CoIs discovered by intuition, they may only log CoIs they are directly told about. These CoIs will be rated by Severity, and checked and enforced as necessary.

Newly appointed leaders after the initial compilation of this list will be interviewed during onboarding.

Leaders are encouraged to proactively declare new CoIs to the Mediators (e.g. they started dating a server member, or moved in with another leader). Leaders are not required to disclose a CoI to a Mediator under any circumstances, but a failure to do so will increase the severity of the consequences if the leader is found to have not properly recused themself should a situation where the CoI they've hidden becomes relevant.

Sharing a CoI where one claims to be a victim of an action that's a violation of server rules or safety should not be considered a green light to start a formal investigation process. Mediators may offer to do so - but the action of declaring a CoI and the action of requesting a formal mediation process are wholly distinct actions. Starting such an investigation without consent, formally or informally, will be considered the same type of violation as an information leak, with the same consequences.

CoI Severity Levels

While we cannot specify every possible type of CoI, and the severity may not be strictly correct for all cases of the below items, this serves as a rough guideline for identifying the severity of various common CoIs:

Low:

• Casual friendship
• One party owes the other some small amount of money
• Strong dislike or personality conflict

Medium:

• Close/Best friendship
• Cohabitation
• Romantic partnership
• Close working relationship outside POND (coworkers, volunteer organizations, etc.)

High:

• Complicated personal history (e.g. a bad breakup)
• Landlord/renter relationship
• Boss/employee relationship

Severe:

• Traumatic history (e.g. abuse, harassment, etc.)
• Marriage
• Financially or physically dependent/caretaker relationship

There are no strict rules for which situation warrants recusal when a CoI is present, but generally speaking Mediators should be wary about participating in anything but the lowest stakes Mediation process without at least some form of recusal beyond Low severity, and it may become very problematic if a single branch of POND Leadership consists mainly of people with High or Severe CoIs. Having multiple Medium CoIs at once should be treated as High or above.

Special Considerations for Mediation

Mediators are expected to be much more diligent about CoIs than others. As mentioned above, they should generally recuse themselves if they have even a Medium CoI with a major party involved in anything more than the lowest-stakes mediation process. In some cases, where too many Mediators are unavailable or stretched very thin, a Mediator with a single Medium CoI with a party may be involved, provided the mutual agreement of all participants, but this should be done very rarely, and never in cases that are very severe (such as sexual assault allegations). See the policies for Assignment of Mediators for more info.

Conflict Resolution

All leaders should do their best to resolve conflicts in an unbiased way. Treat each other kindly, and argue in good faith.

Mediators should never inject their own frame into a Conflict Resolution process, and instead try to find the facts as described by the involved parties to the best of their abilities.

Rule-Breaking

Users who break rules will be held accountable for doing so. The exact infraction will depend heavily on the severity of the infraction, the gravity of the rule, and previous conduct - and can range from a simple talking to to an outright ban. For low-severity rules (such as content warning guidelines, or lightly getting into politics), the occasional failure to abide by them will not be punished so long as the user corrects the mistake/knocks it off when requested.

Random spammers and new joins that immediately come in swinging and breaking rules may be treated much more harshly than established users.

Server Rules

The server rules will be treated in the following order of severity, with worse consequences for multiple infractions:

TODO

Leadership Rules

Leadership rules should all have their severity pretty clearly defined in the sections outlining them. Leaders are expected to adhere by the leadership standards very strictly, and formal accountability processes are much more likely to be triggered for leadership rule violations (outside the more severe regular rules), that said, as outlined in the Accountability Process section, our server does value reform and repair over performative punishment. Still, severe and repeated violations will be treated much more harshly than regular users would be.

Leadership Training

All leaders must go through mandatory trauma-informed conflict resolution training, and training pertaining to the identification of and security around sensitive information. The specific training chosen is TBD. Training must be repeated once a year.

Some accountability processes may require leaders to immediately undergo retraining.

Mediators

Mediators must undergo additional training in conflict management and Restorative/Transformative Justice -- TBD, they are expected to constantly improve their skills in this area.

New Mediators must finish some undecided portion of this training before officially handling any Mediation processes, except in the short window before such training is formally decided on and implemented - and in emergencies where no viable Mediator candidates are available.

Accountability and Mediation

Users and Leaders who break rules will be held to a formal accountability process, facilitated by a Mediator. The exact shape and outcome is defined as TBD TBD etc..

In addition, at any time a User who has experienced a severe problem with another user, may request Mediation to resolve the conflict.

Mediation Involving Multiple Users

Mediation involving multiple users will be handled in group DMs with summaries being provided at the comfort levels of the involved parties.

Mediation Involving a Single User

Mediation involving Single Users happens in cases such as rules being regularly broken, or major infractions - this is usually handled in a ticket, but can be moved to a private DM by request.

Leadership Accountability

Leaders are subject to some extra accountability requirements. In particular - for some more severe violations, leaders will have their roles temporarily removed until a resolution is reached (such resolution may make this removal permanent). Their seat is not considered empty during such a process, instead they are treated similarly to being "On Break" until it resolves.

Assignment of Mediators

Mediators will be assigned based on whoever has the current lowest caseload. Users may request a specific Mediator to take point if they so choose, and this request must be granted barring a disqualifying factor such as a CoI. To accommodate such requests, management of other cases may be given to other eligible mediators to even out the workload.

While one Mediator will be the "point person" in every case, all cases should have at least 2 mediators - temporary Mediators may be selected as per the contingencies if all other Mediators have a CoI.

Contingencies when no viable Mediator is available

If no Mediator can take point, or a second mediator for a given process cannot be found -

Temporary Mediators will be selected by a vote of all Tier 2 leadership with no CoI. The selected Mediator must not be barred from Mediation due to an accountability measure. The preference for bodies to choose from goes as follows: Moderators, Developers, COs, CRs, Planners. No leader is required to be an interim Mediator, and may opt-out of candidacy by request. More experienced leaders in those pools should be preferred over less experienced ones. Said selected member may immediately begin mediating, but also must undergo an accelerated version of Mediator training in the process.

In the event no leaders are eligible, a call to users will be put out (without details about the conflict), and selected from volunteers. Failing that, we panic.

Anonymity

Mediation processes in group DMs must keep the users anonymous, except by mutual consent. Other leaders should refrain from "figuring out" who the involved parties are from context cues, and if they do, should not tell others about their suspicions.

The precise nature of conflicts is treated as sensitive information, though leaders not actively involved in the Mediation process are permitted to talk with friends about such situations provided they are discussing info they only know from channels outside their leadership duties, or info the involved parties are clearly and unambiguously sharing as "open information". Leaders should be extremely careful doing this as there is a very fine line involved, and an accountability process will be initiated at the mere implication of a failure to abide by the rules. The severity of the consequences is determined by the sensitivity and volume of the leaked information. When in doubt, don't!

Leaders who are actively involved as a user in any mediation proceeding are permitted to share information openly with friends without consequence - except the social consequences of their own actions if they break a friend's trust. However, they should refrain from discussing such a thing in leadership channels outside the formal mediation process.

Types of Resolution

Accountability and mediation proceedings may resolve in a variety of ways depending on the incident, parties involved, and severity of the infraction or incident

"Positive" Resolutions

A "positive" resolution for mediation between multiple users is one where all parties have agreed the problem is satisfactorily resolved. This doesn't necessarily mean there are no "hard feelings", but both parties are satisfied with the measures taken, and the measures taken do not severely change or restrict the user's participation or roles in the server.

A "positive resolution" for a rule infraction is one where the accountability measure taken does not result in severe consequences (such as being barred from support, or stripped of a leadership position), in particular when this happens because the user makes a sincere, concerted attempt to fix their mistake and take accountability for their actions of their own accord.

These definitions are mostly useful for reference purposes, and are not official designations.

"Negative" Resolutions

A negative resolution is one where there are irreconcilable differences between users, or they resulted in a major action like a ban or removal from leadership (permanent or temporary).

These definitions are mostly useful for reference purposes, and are not official designations.

Repeated Offenses

Repeated offenses may incur more severe penalties, especially when a user consistently seems to improve for a time, but it never sticks, when community safety concerns are involved.

Plural Users

Plural users are more complicated as multiple system members may act differently, but the shared account presents certain challenges. This policy will be fleshed out with the rest of the leadership policies.

Mental Health Crises

We are not mental health professionals, but want to have resources and protocols for users in a mental health crisis: TODO

Excessive Negativity in Chat

Users who are being excessively negative in chat, particularly those who make it the majority of their participation, will undergo a Mediation process. This will largely be a kind talking to, but for the health of the community they may need their server usage restricted if the behavior continues.

Ticket Procedures

This documents leadership guidelines for the most common ticket situations.

"Point Person"

One person should be "Point" on every ticket, especially disciplinary tickets, this prevents the user from feeling ganged up on. Users may request a different point person to their preference. We'll flesh this out more later.

Role Assignment

Tickets will be forwarded to different roles based on their nature. For instance, users are encouraged to open tickets for help organizing events, which will go to COs and Devs. We hope to have a better system for this than Maki sometime in the future that will do this automatically.

Moderation vs Mediation

Moderators may handle disciplinary tickets that are things like random spammers, or new users that come in and immediately do very little but make trouble. However, for any more advanced situation, Mods should ping the Mediators to transfer point.

If the situation is urgent and disruptive, and no Mediators are around, Mods (and - if it's really late at night and nobody is around - other leaders) may apply Ticket Mute to a person, and open a ticket to tell them a Mediator will get to them when one is available, but otherwise abstain from handling it further (aside from deleting messages if necessary).

Ticket Privacy

See the relevant section in the Information Security Guidelines.

Server Moderation Guidelines

Ban/Kick Guidelines

Generally a ban is for serious infractions or disregard for the rules, as well as spammers. Kicks are for things like non-local people (as they could move here later), or members who are under 21 (since they might grow up someday, who knows, Kids Next Door rule).

If an established community member is banned, a ban log detailing their username and infraction must be posted in #bot-spam within 24 hours so users cannot be silently disappeared with no warning. The infraction description can be somewhat vague if more specific info would out victims or reveal other sensitive information.

DM/Anonymous Complaints

Complaints about the server or its practices received in DM by any leader should be logged in an appropriate leadership channel. The name of the complainant need not be revealed, but we want to maintain a list of at least the genre of various complaints, and how many people have complained about it, to prevent a loose sense of "many people are saying this" but no concrete idea of who or how many or how recently.

Information Security and Privacy Guidelines

Leaders are expected to adhere to the Information Security policy fairly strictly. That said, that does not mean the policy itself is strict. That is to say, most things are pretty lax, but the rules around what must be kept secret and secure are very rigorously enforced.

Broadly speaking, leadership chat is not secret except as specified elsewhere in these Documents. However, leaders should take care and rely on their training when determining if it's okay to share something - and remember that leaking sensitive information will result in a strict accountability process. If you're even remotely unsure - either ask in leadership chat if it's okay, or don't share altogether. Newer leaders will be given much more grace in accidental minor violations of this policy than seasoned leaders.

Anonymity and Privileged Information

Anonymous information must remain fully anonymous - and not shared outside the scope it's authorized to be seen in. Multiple anonymous complaints may be summarized and have their complaints presented in aggregate ("we've gotten quite a few complaints recently about sweeping topics too often"), but the text and details shouldn't be shared directly.

User Notes

Backend channels may be used to keep dedicated moderation notes about various users. This can be disciplinary or infraction notes, but also documenting concerns for a user's well-being. The existence of this isn't secret (nor surprising to most users we'd think), and neither are its contents per se. However, leaders should never go around publicly listing who has notes on them, or for what reason they have them - whether in chat or at an event, and doing so will be met with a strict penalty for bullying.

The lack of secrecy extends insofar as you should remember that any user could become a leader at any time and see what we've documented, so nothing should be said that you wouldn't say to their face. In addition, many such posts are started because of a series of complaints about users (well below the level of a formal mediation process) - often by a mix of leaders and regular users in tickets and DMs. It's hard to separate "leaking" such user note information and simply engaging in healthy venting with a friend about a user you find frustrating due to their public behavior.

That said, it is, at best, considered very bad form to just open someone's thread and go over all their documented incidents for gossip purposes, even with someone on the same page with the same information, and will result in a formal accountability process due to sheer bullying and violating the community spirit alone.

To prevent this policy from getting complicated - sensitive mediation notes should never be stored here (or anywhere in leadership chat, for that matter), other than brief summaries that a conversation was had and action was taken, such sensitive notes should be stored somewhere off-server only accessible to Mediators.

Leadership Chats

The leadership chats (outside Mediation issues and other designated sensitive data) in general are not secret, but leaders are encouraged to use discretion when talking about backend stuff - in particular, don't speak for the leadership team unless the leadership team agrees in advance on what they want to say. You also should be careful about delivering too many gritty details on initiatives that may not even happen - just to manage expectations. Finally, please don't leak other leaders' words to a another user they may have an issue with - let them control how and when they want to express their frustration to that person themselves and on their own time (this really applies even outside a leadership context, but is more clearly enforceable here).

Leaders are permitted to vent about proposals, frustrations, and other leaders' behavior privately to other users - including those outside leadership. Venting can be healthy processing that prevents conflicts from festering, just don't let it rise to the level of outgrouping or bullying. Even so, the same guideline here applies as it does for internal user notes - don't publicly air dirty laundry to a wide group of people. It's bullying!

In addition, resist the urge to "talk shop" at length outside leadership channels and dedicated places like server talk, just because it's alienating to users who are not in leadership.

Support Section

The support section is not not secret. Or rather, it's not secret but extreme caution should be used when sharing information outside of it. Due to the nature of many of the channels there, people share a lot of personal information. Leaders and users alike can be held accountable for spilling personal details without someone's consent outside designated spaces.

That said, it's absolutely not forbidden to casually reference a conversation from the support section elsewhere in the server or at events, provided everyone is being mindful about private personal details. Especially since many conversations in that section are about more general concepts and not just sordid stories of one's private personal life. Repeated harm caused to other community members caused by leaking intimate details will result in accountability actions.

On the other hand: we would like to remind users that the support section is, at best, only kind of private. Maki level 4 is a very low bar, and inactive users retain access indefinitely. While you're encouraged to be as vulnerable as you want, when deciding what information to share, remember that pretty much any stranger capable of appearing nice for a few hours can get access to and use your posts as maliciously as they want, and we'd probably never even know.

CAVEAT: Sensitive data in support may be flagged and shared in leadership chat for moderation purposes, or as evidence when discussing things like the need for certain mental health policies - though leaders must use their training and discretion in determining the sensitivity level of any info reposted there.

Ticket Infosec

Due to mediation being moved off-server, Tickets are rarely classified as secret, but they also usually shouldn't be shared in a cavalier way without reason. Tickets involving established users are generally treated with much higher sensitivity than rando joins that just spam or make trouble. In some rare cases, particularly weird tickets from quickly banned new joins might be shared for the bit.

Some examples of things it might be okay to share about tickets:

• "Oh yeah, I was helping <x> with their event and I think it went really well! I wish more people opened tickets for event mentoring!"
• "lmao, man this spammer really went for it <screenshot>"
• "yeah, we've gotten a few tickets about that, and we [try to/plan to] handle it like..." (without revealing the people who made the tickets)
• "this user helped us a lot with developing this new great thing for the server" (happened to be organized in a ticket; example: thanking Choomba for designing the server logo)

Some examples of things it's not okay to share about tickets:

• A screenshot of another user's DMs (even if they're DMs showing a random spammer, it's their DMs)
• The exact names of users who have submitted certain complaints (to prevent people from going after them - if they want their name attached they can put it in server talk)
• Screenshots of serious tickets with established users
• Any specific details about a circumstance around a complaint that could identify a complainant, even unintentionally
• Any interpersonal issues or complaints about specific users, especially if they quickly get escalated to Mediation
• Discussions of specific rule infractions
  • Exception: if a user was making a scene in the middle of chat, it might be appropriate to give a very quick, low-detail "the user has been muted and pulled into a ticket to address this behavior"

Bots

Bots are used on the server for a variety of tasks. In general, such bots should be safe, but we have specific policies on their usage. In particular, when bots are collecting sensitive data, care should be taken to ensure the data is handled in a sensitive way. Any bot feature we're going to use for such purposes should be tested thoroughly before rolling it out to users - and a guide should be written so users can be reassured about what we can and cannot do or figure out with the data we get.

In the event we realize a mistake in something we've used, we should acknowledge the mistake and quickly find a solution. There are no penalties for making such a mistake unless it was done maliciously, and a talking-to (or a "gentle suggestion" to maybe leave bot-related duties to other leaders) may be needed if it's done negligently more than once or twice.

User-Created Bots

User-created bots add some special concerns. Unless a bot's permissions are not sufficiently scoped, the admin of the bot is essentially being given full control of the server for everything the bot can do. As such, user-created bots must be approved by users in a similar process to leadership applications - where objections are collected and a threshold of 0.8% rejects the bot. Leadership may also elect to reject the bot for any reason. A link to the code must be posted (for technically-inclined users to audit if they so choose) and a list of administrators and contributors to the bot. This can be thought of as informally giving the bot developer(s) the pseudo-"leadership position" of "bot maintainer".

This process doesn't need to be undergone by bots solely maintained by leaders in the Community Developer role EXCEPT if the bots are going to be handling otherwise anonymous or sensitive information (including changes to an already approved bot that add such a feature).

In this case, a fairly thorough and honest application must be submitted explaining what data, exactly, the administrator has access to, and a threat model for how easy or hard it is for the admin to derive revealing information from it. Bots handling such data are expected to maintain the absolute minimum amount of data necessary to enable their use. The bot feature need not engage in top-of-the-line Signal-tier encryption to be viable, but a plan must be submitted and users must approve it.

Follow-Ups With Complainants

Users who formally complain about an element of the server, or a user, should be followed up with when action is taken regarding the thing they complained about. In mediation cases, the Mediators are expected to proactively keep these users in the loop and update them on actions directly.

Special Policies for In-Person Events

In-person events have a few special elements. For one - the event host is allowed to set their own rules. So long as the rules are in the spirit of the server, they should be considered as "binding" for purposes of accountability. Which is to say - if users are routinely breaking (reasonable) rules that event hosts set, this is essentially identical to repeatedly breaking server rules.

In addition, certain rules apply less, or can be outright suspended with mutual consent in in-person events. While not an exhaustive list: In particular, Rule 4 (no heated topics or debates on things such as politics etc.) is essentially always suspended in person, due to the different nature of face-to-face interaction. It's also almost always allowed to discuss topics such as alcohol and weed. Even so, please respect peoples' wishes if they don't want to participate in such topics or behavior.

Rules such as the ones against bigotry and harassment always apply, and no, users cannot make a "bigotry allowed" event - the ability for users to define their own rules for their own events only goes as far as community values and safety are upheld.

Personal Conflicts and Event Attendance

In the case of very serious interpersonal conflicts, some users may be barred from attending some events with other users. The precise nature of such decisions is up to the Mediators handling the conflict - but here are some general guidelines:

Generally speaking, in such cases users will be barred from attending events hosted by the other user(s), and at the very least heavily discouraged from attending events with low attendance containing the other user(s).

However, very large events, such as the monthly gatherings, will generally allow both parties to attend, though they'll be under pretty strict instructions to limit their interaction. Only in very extreme cases will one party or the other be wholesale barred from such events simply due to the presence of the other, and any situations that warrant such a strict measure are probably severe enough to just warrant a ban in most cases.

External User Checks Against Leaders

Users may, at any time, submit a no confidence petition - either anonymously or in Server Talk, towards any member(s) or arm of the leadership team. This is treated similarly to a leadership application in that anonymous feedback will be collected for two days, and a decision made after that period. If at least 0.8% of the server users (the same percentage to reject a leadership application) sustain the petition, the petition is considered passed.

This will enact a formal conflict resolution process and investigation against the indicted leader(s), including potential accountability measures.

In the case that the petition is against an entire arm of leadership (such as all Planners, or the entire leadership team) the indicted group is expected to participate in an open server discussion about the reasons behind the discontent and all leaders will at minimum be reduced to "interim" occupants of their positions and forced to reapply after the proceedings have concluded. Such a petition has a slightly higher pass threshold of 1% of discord users, due to the chaos such an action inevitably creates.

Documents Editing Guidelines

This is just a set of guidelines and tutorialization for editing these documents.

Firstly, you'll need a Github account. Then go to the repository at https://github.com/POND-Portland/docs

After this, you can use the User Interface to add and edit files:

Edit Process

To add a file, use the interface pictured below:

To add or move a chapter, you need to go into SUMMARY.md and add an entry to the table with the name and the path to the file, a technical user can help with this.

To edit a new file, click on it, and then the pen icon:

This will automatically create a "Fork", then open a Pull Request like so:

This should allow us to review and merge the changes.

If you can't figure it out, ask a more technical leader and they can walk you through it, or submit the final changes for you.

If you are a technical user, check the mdbook docs to make your life a little easier.

Editing Style Guide

This is the style guide for the document:

• All Roles should either link to the role definition, or be in BOLD.
• Prefer new pages to sections
• A section with subsections should be under a folder
  • Keep sections organized by naming the file after the chapter name! So if you're adding chapter 4, name it 04-my-chapter.md
  • For subsections, create a folder with that number 04-my-chapter, the first file should be the same name as a file, i.e. 01-my-chapter.md. It's 01- because it's the first page in that section.
  • When adding to Summary.md the 01 should be the same level as its surrounding sections, and 02 and up should be indented.
• We need to write better instructions later.

Appendix

Below are miscellaneous definitions and clarifications for some terminology commonly used in the Documents:

• Community Members - when this role is referenced (e.g. for mandatory review periods), technically speaking it almost always means "Support Area Access", as that's our real gate. In the very rare event a Community Member has their support access limited, they do not qualify as Community Members for such purposes. "All users with the Support Area Access role" is just a much clunkier and confusing phrase compared to "Community Members".
• "Community at-large" - interchangeable with "Community Members".
• community members - when lowercase, this usually just means "all users".
• Ticket - A channel generated for a specific user to communicate with all server leaders.
• Backend - Leadership channels and discussions, as well as esoteric server and community management details not generally relevant to the wider userbase.
• Server - The Discord Server that the Community is hosted on.
• (Community) Values - Inclusivity, accountability, and friendliness.