From my previous interactions with the Serenity community, it was clear
to me that this rule (for better or worse) was introduced by the author
that wanted to focus on the code and not let an open-source operating
system project be used as a 'political vehicle' and so as to not have
to possess a political science degree to operate the project thought to
be a technical exercise, like building a sandcastle.
For better or worse.
Unfortunately, the wording as-is can be interpreted as a dogwhistle
in the direction of "keep politics out of tech", which has been present
in communities like, as of recently, NixOS - and this seems to have
caused the problems that Serenity has been intentionally trying to
avoid.
It might also disregard cases of technical arguments, arguments
involving how people treat each other _within_ the community as well
as how to change the wording in documentation with the sole intent of
making the project more attractive to more contributors.
Given recent commits and governance changes, I decided to rewrite the
rule to make it more clear and encourage people to be "more excellent
to each other", while not compromising on what I see as the original
meaning.
Hopefully this makes it more clear what the intended action is. For a
lot of people "squashing" means combining multiple commits into one,
which is a common practice when merging to a branch.
This includes a few new options to the .clang-format configuration file
to A) adhere to option changes within clang-format 16 (namely the option
AlignTrailingComments), and B) enforce existing style guide rules with
new clang-format rules.
Jokes don't scale well, and if everyone adds their pet "funny" thing
to the project, we'll just look unserious and goofy.
To avoid that, and maintain a dignified style, let's just have a blanket
ban on jokes and "funny" things in user-facing parts of the system.
- Rename "reviewers" to "maintainers" to disambiguate, since everyone
is encouraged to participate in code review.
- Clarify that maintainership is by invitation only and unrelated to
participation metrics.
It's strongly preferred that new contributors get comfortable with the
system and the project by working on smaller and/or existing things
before adding entirely new components to it.
Ideally, new contributors should hack on the system for a while before
attempting to make large architectural changes.
This will help ensure that architectural work is more in line with
the project direction, and that everyone's time is better spent.
