feat(opcodes): implement remediation procedures

[nrdxp]

Opening so we can get these as refined as possible. All feedback is welcome and encouraged. Also, would like to get the appeal procedure down before merging.

[nrdxp]

Just a thought I want to get down...

It may be important to document specific accountability measures for admins as well, say if they consistently skip steps in the remediation process, etc, they could be subject to remediation themselves on account of the violation of accountability, professionalism and transparency,

[nrdxp]

thinking more on this, it will likely be useful to set down a list of loose guidelines for how to manage communication to assist in avoiding remediation in the first place. Maybe a few:

• read-only technical discussion rooms, invite or request only to write
• off-topic channel that doesn't enforce remediation and only very loose moderation (since there is no topic to attempt to keep the conversation on). if it gets out of hand, we simply close the entire room for a time. Dishing out remediation one by one in such a chaotic setting is a recipe for exploitation and erosion of trust, and also just a time sink
• basically no editing of history is allowed except obvious spam. For posterity, the integrity of the conversation should be upheld in alignment with transparency
• likely some others?

[ic4-y]

You might be legally required to remove some contents which aren't technically spam, depending on the country. And the same goes for PR reasons in the largest possible sense.

Also, somewhat ironically, I would not be too specific on these things right now, but rather work them out as we go. They are not top priority in any case.

[nrdxp]

Yes well, it is obviously informed a bit by our rather unpleasant experiences of late. Still, I feel the less room for ambiguity we leave the better. I did plan to expouse a document, probably in the etiquette section or similar, that goes into a loose structure of how to actually apply this ethic too though, which may clarify some things.

It is also stated in the goals that these supplementary documents are entirely optional. But just to explain what I mean a bit:

• in the early phases, governance of a project is really appropriately managed in a fairly ad hoc fashion, with one or a few tightly aligned individuals who all act mostly autonomously. All that might be useful at this stage is a guiding ethic to stay aligned, and you can probably forgo any real formal policy.
• as the project gains adoption, some semblence of a structure needs to emerge, likely the sooner the better (hence putting this here now), so that you can set the tone and the norms up front, and there is minimal chance for a detrimental divergence

• if a project grows so large, then explicit delegation and decentralization practices need to be made explicit and are essential to keeping things manageable without being overly authoritarian or bureaucratic. I think this is where we experienced some difficulty recently. We saw a lack of delegation to individual teams and code owners and an attempt to govern too strictly, and too centrally over an only loosely coordinated collection of groups and interests.

  It could be at this stage that different teams or interests have their own remediation procedures, etc, etc.

[ic4-y]

The issue I was trying to get at is not that there are a few norms and expectations set explicitly.

But here we are talking about a catalogue of punishments, remediation, appeals and procedural stuff more generally.

That was relevant in RFC 175. I'd argue it is no longer relevant for us now.

I would advise keeping this in the drawer for now, maybe we can go back to it in the future, in case we need it.

But since it's optional in this repo.

---

Maybe my sharp turns on which positions I endorse and when, just to endorse entirely different positions afterwards can be confusing. But in short, I'd argue we have no need nor use now for RFC 175 or anything like it.

I feel the less room for ambiguity we leave the better

See this is what I see differently. Right now, we want to be fast and not think about shit until it actually happens. So being informed by the negative experiences should not explicitly inform our policy. The negative experiences should not be forgotten, but they are not to be at the forefront of our minds so to speak.

Rather, what we want now is shape positive experiences for us and others.

We need to engender a positive vision. That is only possible with a bit of ambiguity. :grin:

[nrdxp]

Not bad points, it makes sense. I would put this into a "draft" if I could but I can't so long as it is a private repo.

Perhaps it wouldn't be so bad to just leave it open for now? I don't want to lose track of the document by removing it from the repo entirely.

We need to engender a positive vision. That is only possible with a bit of ambiguity. 😁

I agree, but perhaps I am just traumatized by the recent experience, I am a bit nervous about ambiguity atm :joy:

[ic4-y]

Yeah, let's just leave it open for now to come back to when we get retraumatzied.

[nrdxp]

sure, but I do at least wish to mention that to clarify and reduce ambiguity is at least one of the supplementary goals of this entire effort :sweat_smile: