proposal: add culture or community label to issue tracker

[s-mang]

I think we can all agree that there will always be ways in which we can improve the culture of the Go project such that we increase participation or adoption.

There is currently no place for gophers to report patterns they see in culture which are inhibiting contributions or participation.
There is currently no place or means for gophers to be empowered to not only find and report any unhelpful patterns they observe, but brainstorm and implement solutions on their own.
There is currently no place where we are tracking issues of culture nor the effectiveness of solutions we implement.

The only real place where cultural issues are reported ATM is the code of conduct mailing list (conduct@golang.org). But these issues remain one-off incidents, where the reporter requires the assistance of the CoC working group in order to come to a one-time solution.

See this issue by @kevinburke as an example of an issue that I think would be a good fit for a culture label, if it were to be rephrased as a problem statement #22154.

Issues of culture should be reported alongside issues in code.
This goes along nicely with what @davecheney and others have been saying over and over again for so long - writing code is not the only way to contribute to the Go project. Having these issues of culture reported and solved alongside issues in code will highlight their importance to the Go project, and will encourage and empower gophers to actively make the culture better.

To those of the mindset that there are other venues and forums for these types of issues, I leave you with this:
There is no such thing as separate but equal. In separating cultural issues from issues in code, we are inherently deprioritizing them.

[kevinburke]

I think it's a fine idea, Sarah. My one worry is occasionally people will have culture/community issues that are better addressed in private, and the presence of the public tag might lead them to post here when otherwise they'd hunt for a private contact address. But I think that's a secondary concern.

[leighmcculloch]

💯 A win we get with having culture/community issues reported here is that gophers are more likely to discover them. If the issues are in forums, slack or elsewhere, then they will only be discovered by those who seek them out or already participate in those forums.

These tags could also be used for new ideas to make the community better, and don't need to be limited to something-is-wrong issues.

[as]

I genuinely don't understand how this fits on this particular issue tracker. Aren't cultural issues subjective, difficult to measure quantitatively, and have resolutions that are part of an ongoing process spanning across an entire project life-cycle?

Most issues accepted by the project have traceability that leads back to a temporal slice of the project source code or documentation at some point in time. What is the advantage of encouraging the uses of cultural issue to be logged here other than having evidence that the issues have been acknowledged as an issue by the virtue of them being on an issue tracker?

[s-mang]

Aren't cultural issues subjective

No. A cultural pattern which is impeding the participation of even one gopher is not subjective.
Just as a bug in the compiler which impedes your software development, but nobody else's, is not subjective.

One-off issues should still be reported to conduct@. I am not proposing that should change.

[s-mang]

The process for a culture bug should be the same as that for a technical bug:

1. Bug is reported.
2. Bug is vetted - evidence is collected, bug is verified.
3. Solutions are brainstormed.
4. Solution is chosen.
5. Solution is implemented.
6. Bug is closed.

[as]

To those of the mindset that there are other venues and forums for these types of issues, I leave you with this:
There is no such thing as separate but equal. In separating cultural issues from issues in code, we are inherently deprioritizing them.

I dont think its fair to attach conclusions to a premise without providing causal, correlational, or even anecdotal evidence. The statements above discourage dissenting opinions from being expressed, and I dont think an effective disscussion can occur until the proposal is falsifiable.

[ianlancetaylor]

@as This is not science. We use the issue tracker for many things (other than questions). For example, we're using it for this very discussion.

Most issues accepted by the project have traceability that leads back to a temporal slice of the project source code or documentation at some point in time. What is the advantage of encouraging the uses of cultural issue to be logged here other than having evidence that the issues have been acknowledged as an issue by the virtue of them being on an issue tracker?

It means that we can address those issues in source code or documentation where appropriate. And, we can address them in other ways where that is appropriate. And if we can't come up with a fix, then we close the issue, as we already do routinely.

You seem to be implying that it would be better to not know about these issues. I don't see how that makes sense.

[as]

It doesnt make sense, but I'm not trying to imply that. Rather, its my lack of knowledge on the current issue landscape that make the proposal difficult to understand.

I was looking for a statement like, "over this time period there have been X issues regarding culture, clearly this pattern is recurring to the point of where it would be useful to identify such issues with a distinct tag".

Its not science, it just makes sense to provide supporting data or mention that the data is private. I've seen one cultural issue on the tracker in the past few weeks and thought the proposal would reveal more information about a pattern of cultural issus such that the new tag is necessary.

[chris-short]

I'm all for it. It would be nice if we put people and code issues at the same level. Too often in this industry we forgo addressing serious issues because the person is a great contributor. This is a step in fixing that.

[kennygrant]

I like this idea, and your suggested 'community' label Sarah, to encourage discussing solutions and participation in this public channel.

As a small-time contributor to go (thanks to those who have assisted with/put up with my changes), there are a lot of areas where the community could perhaps help, but are not sure where to contribute, or how, or who to talk to about it without wasting people's time. The website, playground, wiki and even the issues list feel like they have a lot of areas that could do with help, but it's not clear where help is wanted, where it is less useful, who owns which area, or if anyone is looking at go community involvement or what the levels of involvement are (should early contributors review, should they edit the wiki, should they try to resolve issues, if so which ones?). So nice to see this issue pop up.

There are certainly quite a few existing issues which might fit this label #18413 #22154 #22484 #21983 #18517 etc - many are about docs, wiki, issue labels, encouraging contribution, and community but also code (e.g. the github integration) which currently have no unifying classification but might be helped by one.

Given the very small cost (adding a label to the issue tracker and reclassifying some issues), the existing issues it applies to, and the potential gains for newish contributors, I think it's worth doing.

[rsc]

Per discussion with proposal-review, let's try creating a "Community" label and see how it goes. It sounds like much of the focus given as examples is more specifically "Contributors", but maybe other topics will come in too.