2021/08/30 00:11:45: Generated dev website from groovy-website@27affce
diff --git a/wiki/GEP-8.html b/wiki/GEP-8.html
index 4d7e610..d0bcfb1 100644
--- a/wiki/GEP-8.html
+++ b/wiki/GEP-8.html
@@ -200,7 +200,7 @@
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.</p>
</div>
</div>
diff --git a/wiki/initial-release-process-proposal.html b/wiki/initial-release-process-proposal.html
index 1859e7c..65e6303 100644
--- a/wiki/initial-release-process-proposal.html
+++ b/wiki/initial-release-process-proposal.html
@@ -97,11 +97,11 @@
<p>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.</p>
</li>
<li>
-<p>release manager has his personal setup ready. In particular:</p>
+<p>release manager has their personal setup ready. In particular:</p>
<div class="ulist">
<ul>
<li>
-<p>release manager can log into his people.apache.org account using SSH</p>
+<p>release manager can log into their people.apache.org account using SSH</p>
</li>
<li>
<p>release manager has administration privileges on <a href="http://ci.groovy-lang.org">the CI server</a></p>
@@ -120,7 +120,7 @@
<h2 id="_preparing_a_release">Preparing a release</h2>
<div class="sectionbody">
<div class="paragraph">
-<p>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 <code>GROOVY_2_4_X</code> is the branch to release, <code>upstream</code> references Apache Git, and <code>origin</code> the release manager fork on GitHub, preparing for a release usually starts with:</p>
+<p>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 <code>GROOVY_2_4_X</code> is the branch to release, <code>upstream</code> references Apache Git, and <code>origin</code> the release manager fork on GitHub, preparing for a release usually starts with:</p>
</div>
<div class="listingblock">
<div class="content">
