May 23, 2018·4 min read·engineeringgogovernancecommunity

Go changes the scope and enforcement of its code of conduct

The revised Go code of conduct addresses harmful behavior outside project forums and assigns enforcement to a trained Project Steward with institutional support.

A community rule needs people with the authority and support to apply it. Go's conduct policy has encountered a gap between that requirement and what its volunteer working group can reasonably provide. Today's announcement from Steve Francia changes both the policy's reach and the responsibility for enforcement. Those changes respond to problems the project describes from its own experience with the original arrangement.

The project introduced its first code of conduct in November 2015. Francia explains that the initial wording limited action to behavior in official project forums. Reported conduct elsewhere could affect participants inside the community while falling beyond that wording. Separately, volunteers handling reports found the work overwhelming and felt inadequately trained and exposed.

I care about this because Go's usefulness depends partly on people being able to collaborate on code they can understand and maintain. A readable language does not settle how its participants treat one another. The project's rules need a practical process for handling behavior that prevents others from participating.

Venue boundaries did not match the effects

The original scope assumed that official project spaces were a sufficient boundary for a project's response. The announcement says reported incidents challenged that assumption. Conduct outside a forum can affect whether someone feels able to enter it or work alongside another participant. The location of the original act does not contain all its consequences.

The revised scope addresses conduct outside project spaces when there is a reasonable belief that it may negatively affect the project or community. That qualifying relationship matters. The explanation connects the expanded scope to participation and community safety. It does not describe a general authority to adjudicate every disagreement in a participant's life.

For a technical project, a location-only rule has an obvious practical weakness. Participants can interact through independent channels and still work together on the same issue or contribution. Moving an interaction to another venue does not necessarily remove its effect on the shared work. This is an explanation of the scope problem, not a claim about an undisclosed incident.

The change also requires judgment. A policy cannot decide whether particular conduct has the necessary connection merely by checking the address of the website where it occurred. Someone must assess the report and its consequences. Expanding the written scope therefore makes the enforcement arrangement more consequential, which is why the second change belongs in the same announcement.

Volunteers had already received a different role

Francia describes an earlier attempt to address the working group's burden. In early 2017 the project changed its role from discipline toward advice and mediation. The intention was to reduce what volunteers had to carry. The announcement reports that they still felt overwhelmed, while the project had lost an enforcement mechanism.

Advice, mediation, and enforcement are different activities. Mediation can help participants resolve a conflict when they can take part on workable terms. Enforcement requires the project to determine what behavior it will permit and what response a violation warrants. Assigning the first activity does not automatically provide authority or support for the second.

The reported problem is therefore more specific than an assertion that volunteers are unsuitable for governance. The responsibility exceeded the arrangement available to support it. Good intentions did not provide training or remove the personal exposure attached to handling a complaint. Changing the title of the work could not resolve all those demands.

This distinction matters when evaluating the revision. More extensive written standards alone would still leave someone responsible for reading reports and reaching decisions. A process has to account for that person's capacity. Otherwise, the policy can create an expectation of action without providing a viable means to act.

A Project Steward receives reports

The new arrangement replaces the working group with a Project Steward who receives training and support. The steward works with a committee containing representatives of Google's Open Source Programs Office and Open Source Strategy team to resolve reported violations. Cassandra Salisbury is the first steward.

That assigns an identifiable point of responsibility while providing an institutional group behind the role. The announcement presents this support as part of the remedy for the previous burden. It would overstate the evidence to claim that naming a steward proves the process will succeed. What changes today is the documented arrangement for doing the work.

The source also explains how the policy text developed. Go worked with Google's open-source groups after a meeting in mid-2017. They began with Contributor Covenant version 1.4 and adapted it in light of their experience. The resulting Google template provides the basis for the policy Go adopts today.

The Covenant supplies explicit behavioral standards and describes responsibilities for maintainers. Its scope also addresses people representing a project in public spaces. Go's announcement explains the particular shortcomings its adaptation intends to address. Reading the ancestry of the text helps distinguish a shared starting document from the specific enforcement design now being adopted.

Supporting participation is operational work

There is a cost to a project taking responsibility for reported harm. Someone must receive information that may be difficult to share, assess its connection to the community, and participate in a response. The May announcement makes that work visible by describing the failure of an earlier volunteer arrangement and explaining who will perform it next.

I prefer a named, supported responsibility to an implicit expectation that available volunteers will absorb whatever arrives. That judgment follows the same preference for explicit decisions that makes Go appealing to me. The relevant decision here concerns the people maintaining the project, rather than the design of a package interface.

For a participant, the immediate implications are defined by the revised scope and reporting arrangement. A report's relevance no longer depends solely on whether the conduct occurred inside an official forum. Responsibility for receiving it rests with the steward, who has the committee's support in seeking a resolution. Those are concrete changes to the process available to the community as of today.