[groovy-website] branch asf-site updated: avoid gendered words

[pa...@apache.org]

This is an automated email from the ASF dual-hosted git repository.

paulk pushed a commit to branch asf-site
in repository https://gitbox.apache.org/repos/asf/groovy-website.git


The following commit(s) were added to refs/heads/asf-site by this push:
     new 27affce  avoid gendered words
27affce is described below

commit 27affce813e4821fb750bf788f7de65f6ca0a417
Author: Paul King <pa...@asert.com.au>
AuthorDate: Mon Aug 30 10:09:09 2021 +1000

    avoid gendered words
---
 site/src/site/wiki/GEP-8.adoc                            | 2 +-
 site/src/site/wiki/initial-release-process-proposal.adoc | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/site/src/site/wiki/GEP-8.adoc b/site/src/site/wiki/GEP-8.adoc
index b3f449f..d95d9ee 100644
--- a/site/src/site/wiki/GEP-8.adoc
+++ b/site/src/site/wiki/GEP-8.adoc
@@ -55,7 +55,7 @@ named TypeChecked. If set, then the AST transformation will perform type inferen
 information in AST nodes metadata. Eventually, if errors are found, it will add errors to the compiler
 through a dedicated addStaticTypeError method which basically does the same as the traditional
 addError method but prefixes the messages with a "Static type checking" message.
-This is done to help the developer determine whether the error he is seeing is a "plain Groovy" error,
+This is done to help the developer determine whether the error they are seeing is a "plain Groovy" error,
 or an error thrown by the STC mode.
 
 ==== The StaticTypeCheckingTestCase class
diff --git a/site/src/site/wiki/initial-release-process-proposal.adoc b/site/src/site/wiki/initial-release-process-proposal.adoc
index 0469a65..85ec6a7 100644
--- a/site/src/site/wiki/initial-release-process-proposal.adoc
+++ b/site/src/site/wiki/initial-release-process-proposal.adoc
@@ -24,15 +24,15 @@ Releases can be initiated by a committer, as long as:
 
 * an email has been sent to the dev mailing list, where a committer volunteers for a release
 * there's a general agreement that a release can be done. There's still no explicit rule telling when a new Groovy version can be released, but the history of the project shows that releases are usually done when a significant amount of bugfixes have been done justifying a release, or that new major features are ready.
-* release manager has his personal setup ready. In particular:
-** release manager can log into his people.apache.org account using SSH
+* release manager has their personal setup ready. In particular:
+** release manager can log into their people.apache.org account using SSH
 ** release manager has administration privileges on {teamcity}[the CI server]
 
 Releases are launched from the CI server. A release should never be done from a personal computer.
 
 == Preparing a release
 
-Releases are done from the CI server, but since it will involve creating tags, branches and several commits, and that the CI server doesn't have privileges to do it, we cannot work on the Apache Git origin. Instead, it is required that the release manager forks the repository and pushes changes to his personal fork. Given that `GROOVY_2_4_X` is the branch to release, `upstream` references Apache Git, and `origin` the release manager fork on GitHub, preparing for a release usually starts with:
+Releases are done from the CI server, but since it will involve creating tags, branches and several commits, and that the CI server doesn't have privileges to do it, we cannot work on the Apache Git origin. Instead, it is required that the release manager forks the repository and pushes changes to their personal fork. Given that `GROOVY_2_4_X` is the branch to release, `upstream` references Apache Git, and `origin` the release manager fork on GitHub, preparing for a release usually starts with:
 
 ```
 git checkout GROOVY_2_4_X