_Whereas_ Microsoft has been/is still making strides to address community criticisms of how it administrates the .NET ecosystem;
_Whereas_ Microsoft has already given itself a new standard on ensuring venues for community contributions;
_Whereas_ it is an indisputable fact that all communities contain a diverse set of individuals, where it is unlikely that all are of benevolent, productive, and cooperative intent;
_Whereas_ the community, without abandoning its advocacy for improvement in the .NET ecosystem, should acknowledge that there needs to be a balance, at some line, where Microsoft is in fact obligated to intervene, to ensure productivity;
_Whereas_ Microsoft has great hesitation before moderating threads, for the reasonable concern of social repercussion;
_Therefore_ I propose the community puts forth a collective effort to develop a set of guidelines and etiquette to provide for Microsoft's adoption, to protect productivity and give Microsoft a defined "safe ground" to administrate said protection from.
In my opinion I think it makes sense to have a code of conduct to deal with offensive materials or the like, assuming that one doesn't exist. But when it comes to non-productive issues I think it might be best to allow for the individual team to make that decision, as well as to allow for leeway in defining and enforcing those decisions.
For example, the issue that prompted this discussion isn't offensive. Persistent definitely, and borderline obnoxious (especially given the individual decided to initiate an unsolicited offline email discussion with one of the team members), but I don't think it really crossed any of those lines that shouldn't be crossed. And perhaps if people like myself could resist the bait the conversation would just peter out on its own.
In my opinion the language team members should be commended for showing a considerable amount of patience and restraint throughout that conversation and the several others than have veered off course. Dealing with such a diverse and opinionated community such as ourselves can't be easy, particularly in a public forum.
For example, the issue that prompted this.....
I would say it had reached the point of redundancy and incoherence where action should have been taken a while back. If they have to decide as a group whether to lock a thread or not, then that leaves the holidays vulnerable.
And perhaps if people like myself could resist the bait the conversation would just peter out on its own.
Can't rely on that, sad to say. It's effectively the same as "hope for the best".
In my opinion the language team members should be commended for showing a considerable amount of patience and restraint throughout that conversation and the several others than have veered off course.
I'm in full agreement. I would be hard pressed to do the same, if I could at all. That said, imposing the need to do so regularly is going to wear the team down. As I said previously, the more stage time you give to trolls, the more trolls will come by. Better to set fair standards now, and by our own initiative, than to further any possible regrets the team may have for going OSS.
To note, my language has and will continue to reflect the perspective of moderation of a community, and my experience of such has been of a much less formal context, to say the least, so that will show.
There is already a formal Code of Conduct, however it's fairly vaguely worded.
For example, privately emailing (sounds like multiple times) one of the language design team on their personal (non-Microsoft) address could be seen as "private harassment".
However, in this case I would definitely argue the point for "unprofessional conduct". The Code doesn't explicitly cover any particular individual action, but the relevant discussions have turned the language discussions into a much more stressful environment, where new issues are regularly met with a reaction of "oh no, no this again."
Perhaps Microsoft should transform the general code into a more concrete set of moderation guidelines.
I think it would be best if, whatever is done, it's designed as a community effort. To be plain, Microsoft has to play the PR game, but if we put in the work, then Microsoft has little, if nothing, to do, save adopt. Point being to take the initiative, and skip as much push and pull to polish it as possible.
In the past we've locked conversations that spiraled off-topic or out-of-control (I believe https://github.com/dotnet/roslyn/pull/3507 was one of the first). But this sort of thing is very rare. The only other conversations I've had to lock were ones where people made personal attacks and did not stop even after being asked. I personally want a policy that is as lenient as possible, but I'm certainly open to any and all suggestions from the community.
As noted, we have a code of conduct. We opted not to create our own but to adopt one that had been adopted by other projects. The one we adopted is broad in nature and doesn't cover specific cases. This is the only model that works given that we want a short, readable and accessible document (meaning, you don't have to be a lawyer to read it).
I read the csharplang thread. After about 10mins of reading, I didn't see anything obviously offensive or of concern. It's very possible I missed the one/set that you were looking at. The thread is very long. Feel free to send offensive posts to [email protected].
You are right that we take a pretty conservative approach on community management. As a goal, we're not trying to prevent arguments but we do want to ensure that our repos are a safe place for people to engage. That's what the code of conduct codifies. Practically, it is sometimes tough to decide how to define "offensive". One person's "reasonable" is another person's "offensive". It's us humans that makes makes community management tough. As a result, we use a pretty high bar for defining offensive.
As an example, I've had Microsoft team members come to me saying that "I found this community post personally offensive ... can we delete it?" I try to do an objective bar test for each one of those. I ask myself if I think most of a group of 10 arbitrarily-selected people that are not part of the discussion would consider a post offensive in nature upon first read. If yes, we take some action (typically, deleting it). If not, we don't. It isn't much more complicated than that. Sometimes, there is something more complex at play and then we need to use a different approach, but that's rarely the case.
There are some comments that we've allowed to persist in the past that we wouldn't allow now, so there is some adaption and learning that we've applied over time.
Last, we take every report that people send to [email protected] very seriously and use a multi-person group to review and act on each submission.
That all said, I'm not seeing anything to act on in this thread unless I'm missing the obvious.
To reiterate, the intent behind this is not for that specific thread. There have been a few others (such as one suggesting being able to return methods that return void) where the conversation dwindled into objectively redundant and plausibly of the intent to waste time (ie trolling).
If I were to back up and try to define what I'd like to see changed, it would be threads that become objectively unproductive yet still consuming the energies of contributors be locked.
An example from a different angle would be EF Core's initial M2M threat, which, thankfully, did end up getting a resolution. The thread had many instances where people were asking previously answered questions, and repeating points.
It's my hope that you will look at these examples and look at trends in moderation, from the perspective of the value of the energies you put into it. It can be just as problematic and trouble-inviting to have the stage completely open as it is to have it closed.
Ah, I see. Yes, that's a different topic. It's also even harder to solve, IMO.
We are super hesitant to use locking. I consider it an over-reach by moderators. I do think it is useful for moderators to help with the flow of the conversation, as you suggest. We had long conversations on this. See What you can expect from Maintainers. That document is the one to focus on. Feel free to propose changes.
I would go a step further and say there is no solid solution. Just need to make the best attempts in the context.
The Maintainer's document reads as more of a Collaborative Leaders document, vs Community Management. It's the nature of the context where Maintainers will need to have that mindset. I'd suggest a section related to "thread arbitration", where something of a line can be defined. In the next couple days, I'll write something up as a WIP PR.
Sounds good. However, I'd prefer if you could find examples from other communities that have already defined solutions to issues like thread arbitration. We'd much rather re-use something that already exists. Many of these issues are super controversial and it is easy to step on third-rail type issues w/o realizing it. Microsoft and .NET Foundation are late-comers to open source community management, so we are remiss to re-innovate in spaces that are already fully explored by folks like Apache.
I can certainly make that a priority.
Looks like this good conversation completed so closing up the issue.
This repo is no longer actively monitored. Closing up old issues that have not had activity in while. If this is still an issue, please open a new issue in an appropriate repo listed in microsoft/dotnet#1275
Most helpful comment
In my opinion I think it makes sense to have a code of conduct to deal with offensive materials or the like, assuming that one doesn't exist. But when it comes to non-productive issues I think it might be best to allow for the individual team to make that decision, as well as to allow for leeway in defining and enforcing those decisions.
For example, the issue that prompted this discussion isn't offensive. Persistent definitely, and borderline obnoxious (especially given the individual decided to initiate an unsolicited offline email discussion with one of the team members), but I don't think it really crossed any of those lines that shouldn't be crossed. And perhaps if people like myself could resist the bait the conversation would just peter out on its own.
In my opinion the language team members should be commended for showing a considerable amount of patience and restraint throughout that conversation and the several others than have veered off course. Dealing with such a diverse and opinionated community such as ourselves can't be easy, particularly in a public forum.