Problem-solving: Update or replace draft SoC/CCoC

[japhb]

Currently the Raku and Rakudo communities do not have a final, approved SoC/CCoC (Standards of Conduct / Community Code of Conduct) document. A draft was created in July 2015, based largely on five basic principles, but to my knowledge as one of the contributors it was never approved/ratified.

That draft is light on legal statements or exhaustive listing of unacceptable behavior, and focuses more on intent and positive behaviors in the face of trolling and other negativity. Other Perl family community SoC documents, such as the SoC for the next TPC conference and the perl5-porters SoC choose a much more detailed and prescriptive path, with additional emphasis on agreed unacceptable behaviors and policies for dealing with them.

We need to:

1. Decide on procedures for: a) updating or replacing our existing CCoC draft, and b) how we will ratify/approve it.
2. Update or replace the existing draft following the procedure in task 1a, taking into account our current needs and current best practices for writing SoC/CCoC documents for open source projects. If we decide on formal reporting, investigation, arbitration, enforcement, or other such procedures, they should be included in the new draft. If we decide to have nominated community "arbitrators/moderators" (for lack of a better phrase), we should also include the procedure for nominating and approving them, or decide that we will address that procedure in a separate document (and then create/approve that separately).
3. Ratify/approve the draft according to our procedure in task 1b.
4. If we have chosen to nominate arbitrators/moderators, we should do so on completion of task 3.

[japhb]

Please, let's do step 1 (a+b) before we go to step 2. Otherwise this issue is going to end up derailed in a similar way to the previous one before we make solid progress.

[vrurg]

@japhb by your items as you listed them, this would be my proposal on procedures:

1 - I think the initial draft shall be proposed in a form of PR into problem-solving. It's content could be compiled based on ideas from the sources you referred to. When considered done, the voting could be done by approving the PR similar to how renaming was accepted. The only difference could be that 2/3 of reviewers votes should be sufficient to accept the document.

2 - these matters would be considered and accepted/reject during the process of reviewing the document in a form of proposed patches/editions.

4 - the list of nominated persons must be a part of the paper and would be approved together with the PR.

[niner]

I would like repeated negligence to be considered a form of unacceptable
behavior.

What you point out here is the responsibility each of us carries as
developers. For example, I frequently use my privileges to push improvements
to master like my recent NativeCall precompilation fixes. I do this because
they matter to me. Then it was discovered that my fixes caused regressions in
other people's use cases. Even though my code ran just fine, I saw it as my
responsibility to fix the mess I created and so I did.

The same is true for reviewing PRs. When I accept or merge a PR, I take over
some responsibility that this will do more good than harm to the project and
its users. That's why for example I was hesitant to review Kaiepi's IPv6 work

• even though I have been a proponent of IPv6 for 2 full decades. For doing an
  appropriate review, I had to dig into an unfamiliar part of the code base and
  think far ahead about the consequences the changes may cause. That takes a lot
  of time and effort. But if I do a review, I better do it right.

I didn't mean to, but in my example the same conflict of goals is visible as
in the one that sparked this discussion: I had to balance the risk of
worsening our code base versus the risk of frustrating a new and very able
contributor. Where the optimal balance is, is far from obvious.

This topic of developer responsibility is clearly very important. What I don't
know is if a SoC/CCoC is the right place for discussing/codifying it. I think
it _possible_ that we could get by without actually codifying it. i.e. it
could be enough when senior developers raise such issues in a CCoC conformant
way. Just like I for example pointed out the value and structure of proper
commit messages numerous times, or why we shouldn't make backwards
incompatible changes lightly. The arguments usually carry enough weight
without the need for pointing out broken rules.

[japhb]

@vrurg Regarding your procedure proposal, task 1 and task 2 seem like a reasonable start. I'm not convinced on task 4, so I'm curious of your reasoning why the list of humans nominated should be part of the initial PR.

[japhb]

@niner I agree that the SoC/CCoC may not be the right place for developer responsibilities -- SoC documents tend to talk about good behavior (and possible censure) within the _community_, whereas I think of a responsibilities doc talking more about good behavior (and possible censure) within the _codebase_ and _committer list_.

If we believe we need a developer responsibilities doc (or some other wall around the committers list), we should address that in a separate issue/PR. I will say that this makes me sad having loved Audrey's radical trust philosophy, so if we do end up creating one I'd like it to be angled more in the "protection for the project if trust is misplaced" direction rather than the "gatekeeper to granting any trust at all" as certain other cathedral-style projects use them.

[ugexe]

so if we do end up creating one I'd like it to be angled more in the "protection for the project if trust is misplaced" direction rather than the "gatekeeper to granting any trust at all" as certain other cathedral-style projects use them.

I don't think there is any disagreement here, and its why it reads "repeated" negligence -- i.e. a provable pattern of careless actions in some area with no evidence of improvement over time. In such a scenario one should have no reason to worry about making a mistake (since they can correct themselves once they discover it was a mistake), new comers are inherently given extra leniency (because over time barely applies to them), and us grumps have an official means of action after already pointing out previous similar LTA developmental practices.

[lizmat]

A headsup from me: I will be looking at this the coming days. But don't expect anything substantial from me before the weekend, as I will be afk for most of tomorrow.

[nxadm]

The CoC is not about about handling someone repeatidly someone repeatedly not agreeing with you technically not about them being wrong, even all the time. It's about how to communicate with each other, even when code-wise you're correct.

whereas I think of a responsibilities doc talking more about good behavior (and possible censure) within the _codebase_ and _committer list_.

I agree wholeheartedly with @japhb: the CoC is about how we communicate with each other and with the world (people) and not about the responsibility towards the codebase (technical and responsability towards others). I think @niner illustrated that rather well.

[tmtvl]

Repeated negligence could be considered a form of trolling, albeit not necessarily a deliberate one.

[nxadm]

There is no non-deliberate trolling. It's a contradictio in terminis.

[vrurg]

@japhb

Regarding your procedure proposal, task 1 and task 2 seem like a reasonable start. I'm not convinced on task 4, so I'm curious of your reasoning why the list of humans nominated should be part of the initial PR.

I want to have it all in a single document. And I consider it pretty natural to have a section in it which not only tells how conflicts are to be resolved but will also include the list of people elected for this.

Though what I missed in my view is that voting for arbitrators must be held on individual basis while I was thinking about the list as a whole. Yet, in either case, every single election is a good reason for editing the paper for the purpose of changing the list.

[vrurg]

I think the discussion about bad developer practices (negligence in particular) would take us nowhere for now. What shall be done is @ugexe point of view is taken into account. Upon having a draft ready for reviewing we can initially include a paragraph about this subject into it (hope Nick wouldn't mind writing it for the paper). Then we take a separate vote on it. And if it loose – it gets eliminated from the draft.

This is the best way because:

• current discussion is prone to bikeshedding
• people mostly discuss their own view on a problem rather than the actual thing unless they have it right in front of them; only in the latter case the discussion have good chances to be substantial
• while currently being opposed to the @ugexe proposal, I don't rule out a situation where the actual text can convince me that it must be eventually included. And perhaps not me alone.

[lizmat]

I think the keyword with regards to developers part of a CoC, is "responsibility". You should be responsible for your actions.

This means on the one hand that if you create some new feature that gets included, you make sure that it gets documented at least externally. When you merge a pull-request, you become responsible for it to not break something hard or soft (like making things 2x as slow for all code).

This does not necessarily mean you would have to do all of the testing (which could take prohibitively long), but be ready to revert the moment it becomes clear it is causing issues. And if a simple revert has become impossible, be responsible for having it fixed another way.

[tony-o]

Re 4: Seems shortsighted to limit who can arbitrate or moderate disputes. Maybe suggestions for go-tos but not limiting it to specific people.

[lizmat]

I think when it comes to arbitration, you'd need someone who is acceptable to both parties. As soon as one of the parties has lost trust in the arbitrator, you've lost any chance of a good outcome of the arbitration. Now, not all people now all people in the Raku community: so having people chosen to be able to do the role of arbitrator, seems logical to me.

I agree that this is not mandatory: if two parties can find someone else acceptable to them as arbitrator, then by all means, use that person as arbitrator.

I think dispute moderation can be done and should be done by anybody in the community.

[lizmat]

https://perl6.party/post/On-Troll-Hugging-Hole-Digging-and-Improving-Open-Source-Communities

[japhb]

About the list of arbitrators -- it might be worth having a link to a list of volunteers, just so someone who looks up the CCoC because they feel there's a violation has some idea of who has indicated willingness to act in this role. Even if dispute moderation is something we hope many of us can do, we want to allow people to indicate that they have enough emotional capacity to do so with a clear unbiased view and without burning themselves out, and that they are willing to spend the limited time/energy they have to give to the community on this. Dispute resolution can be exhausting even for experts; I don't want us to pile load onto people who are already pushing their personal limits.