Update rules to allow contribution focused on inclusivity

[conartist6]

I am suggesting that the official definition of what constitutes contribution to the community be expanded to include people whose role is to help more people feel welcome in the community, particularly when working with language.

For example when I was contributing to MDN docs, another contributor came through and edited all my contributions (and those of many other authors) eliding words and phrases like "simply", "obviously" and "of course". I was initially incensed at the editorializing of my creative work, but when I read the description of the PR I realized the contributor had experienced directly or indirectly the frustration novice readers had with these addendums as they struggled to grasp complicated concepts.

I would say this is not a political issue, but that wouldn't be quite right. It isn't a left-vs-right issue. Building a coalition of people who both advocate for their own self-interests and work for common goals is the fundamental nature of both politics and open source. I encourage you to recognize that building a community around a piece of software is a task equal in complexity and value to building the software itself, and to support the people who contribute to your cause by doing that work.

You indicated in the recently-locked PR that the community needed to discuss its policies on the matter, and I am hoping this thread might serve as a place to do so in an transparent and productive manner.

[gmta]

We already have the ongoing PR #24654 in which we'll come back on exactly these types of changes to the policy and rules.

[conartist6]

Ah ok, I see now.

[n00b69]

OP, stfu

[soulhotel]

The presence of an open-source project is already, in and of itself, 'inclusive'.

Contributors are already working on a common goal by focusing on the development of a great software, in this case SerenityOS.

Also it's important to understand that many users will feel welcome to something that many other users may not. Regardless of what that something is, the only solution to such a scenario is for the individual user to look at the project objectively, and determine if the project's features are something that they appreciate or not.

[stuaxo]

eliding words and phrases like "simply", "obviously" and "of course". I was initially incensed at the editorializing of my creative work, but when I read the description of the PR I realized the contributor had experienced directly or indirectly the frustration novice readers had with these addendums as they struggled to grasp complicated concepts.

Strongly agree, even when I'd been a dev for just 15 years, I'd do tutorials that talked about how easy some framework is.

After completing the tutorial TODO list it becomes obvious that the people who made the framework have forgotten what it's like to be a beginner, and "of course" their framework is easy, however it isn't to a beginner.

It's good to set expectations, and it's OK that not everything is easy.

In that light, I'm in favour of neutral language in docs.

[ADKaster]

With #24654 merged, this issue should be in theory resolved. If folks have clarifying comments or proposed changes to the updated contributing document, they should be done in another issue or PR.