>Pronoun: Valid but nitpick. Breaking the stereotype is a valid inclusive
practice;
>if you're embarrassed that's a teaching moment since you should be asking
yourself
>why you wouldn't be objecting as strongly (if at all) if "he" had been
used. In any case,
>since this is a direct quote I decline to tamper with it; what you do
if/when you re-quote it elsewhere is up to you.

Joseph, I did provide an actionable alternative: "using inclusive wording".
That was my exact suggestion.
Here's an article on the best practices for using the inclusive wording:
https://chromium.googlesource.com/chromium/src/+/HEAD/styleguide/inclusive_code.md

The better phrase could have been "guarantee that they will never
contribute again and use their time" (replace she => they, and her =>
their).
There might be better alternatives, however, singular they will definitely
be better than both "she" and "he".

>And frankly, your complaining about "bad practice" (as opposed to bad
result) without offering an actionable alternative called for this
reminder.

Frankly, I here are my suggestions (the first is almost the same as the one
you reply with "without offering an actionable alternative", and the second
comes from many my emails:
1) Reviewing PRs and issues. https://github.com/apache/xalan-java/pull/1 is
a one-line change which fixes real issue, and it still waits more than 1
year in the "review".
According to all the "best OSS practices", project maintainers should
review the changes or reject them. It is very demotivating when a
suggestion is left without a resolution,
and there's no excuse for ignoring a trivial one-line change

2) I suggest PMC to consider encouraging and inviting contributors. It is
very actionable alternative

----

>We disagree strongly; I would say this essay should be posted periodically
to *any* git development group's list

What are the reasons and goals of posting something again and again?
If you feel xalan-java development should follow the items in the essay, I
suggest creating
a CONTRIBUTING file (see
https://docs.github.com/en/communities/setting-up-your-project-for-healthy-contributions/setting-guidelines-for-repository-contributors#adding-a-contributing-file
).
Then you could express the way community agrees to operate.

As you post "someone else's essay", I can't understand if you agree with
all its points. I don't understand if all xalan-java committers are going
to follow the essay.

For instance, the essay says "Let us not force them to first and foremost
cater to our needs as reviewers".
I have never seen committers to follow that suggestion. On contrary, almost
all the suggestions are declined with "we have other priorities".
Suggestion: "let's add CI to validate if xalan-java works" PMC: "we have
other priorities"
Suggestion: "let's fix .gitignore to prevent accidental commits of
generated files". PMC: "we have other priorities"
Suggestion: "let's avoid wiping the history". PMC: "we are focused on
Maven, so history is not as important"

Even though I fully agree everyone has their priorities, I am sure
xalan-java PMC has no excuse here as xalan-java ignores both single-line
contributions, and they are not inviting committers.
How is the PMC going to grow the community then?

Effectively, all the PRs for xalan-java are trivial, and they will
definitely improve the project.
They are small, helpful, and reviewable changes, so I would expect the PMC
to review and encourage further contributors just like the essay says,
however, the reality is very different.

>Please be patient; we are making mistakes as efficiently as possible.

Joseph, I beg your pardon, however could you please clarify how much time
should I wait for reviewing the following contributions?
It is not a problem to wait a bit, however, it is disheartening (see "Let
us try to encourage, not dishearten them" in the essay) to
wait for 4 months even for trivial changes, especially when committers make
some commits at the same time.
It does look as if the PMC ignores building the community.

The spirit of the ASF is to build community:
https://news.apache.org/foundation/entry/announcing-our-annual-event-community-over-code
,
and I struggle to see how xalan-java builds the community.

https://github.com/apache/xalan-java/pull/1 <-- this is a clear bug with
one-line solution
https://github.com/apache/xalan-java/pull/8
https://github.com/apache/xalan-java/pull/9
https://github.com/apache/xalan-java/pull/14

You have the power of committer, and you still to ignore what the essay
says:

>   -- Let us not force them to first and foremost cater to our needs as
>      reviewers, as if our own time was somehow more precious than
>      theirs, just because we sit in front of the merge button and can
>      exert power, blocking or accepting a PR.

Having that in mind, the phrase "making mistakes as efficiently as
possible" is not funny at all.
Reviewing and merging https://github.com/apache/xalan-java/pull/1 can't
take more than 5 minutes, and ignoring the PR
is exactly the opposite of what the essay suggest.

Vladimir

Reply via email to