diff --git a/site/src/site/releasenotes/groovy-3.0.adoc b/site/src/site/releasenotes/groovy-3.0.adoc
index 84a5c90..7b1296e 100644
--- a/site/src/site/releasenotes/groovy-3.0.adoc
+++ b/site/src/site/releasenotes/groovy-3.0.adoc
@@ -712,7 +712,7 @@
 == Split package changes (from beta-2)
 
 The Java Platform Module System requires that classes in distinct modules
-have distinct package names. Groovy has it's own "modules" but these haven't
+have distinct package names. Groovy has its own "modules" but these haven't
 historically been structured according to the above requirement.
 For this reason, Groovy 2.x and 3.0 should be added to the classpath not module path
 when using JDK9+. This places Groovy's classes into the unnamed module
diff --git a/site/src/site/sitemap-user.groovy b/site/src/site/sitemap-user.groovy
index ae23e35..26ec33a 100644
--- a/site/src/site/sitemap-user.groovy
+++ b/site/src/site/sitemap-user.groovy
@@ -480,7 +480,7 @@
         speaker 'Andrés Almiray'
         summary '''
             <p>Groovy is a well established player in the JVM since a few years ago.
-            It's increased popularity across the years has spawned several projects that conform the Groovy Ecosystem.
+            Its increased popularity across the years has spawned several projects that conform the Groovy Ecosystem.
             You've probably heard of Grails, Gradle, Griffon and Spock.
             But what about the rest of projects that are just waiting around the corner to be discovered and make your life easier?
             This talk presents them tools and libraries that use Groovy as the main driving force to get the job done.</p>
diff --git a/site/src/site/wiki/groovy-release-discussion.adoc b/site/src/site/wiki/groovy-release-discussion.adoc
index d8fc13b..84d9ca0 100644
--- a/site/src/site/wiki/groovy-release-discussion.adoc
+++ b/site/src/site/wiki/groovy-release-discussion.adoc
@@ -102,7 +102,7 @@
 
 * 3.1 DISCLAIMER is correct, filenames include "incubating".
 
-_We need to add the *DISCLAIMER*. The "incubating" part is disturbing. In particular, Groovy is not a new project. It's been there for 12 years, and the last release before Apache will be 2.4.2. Does it mean that the next release will have to be named 2.4.3-incubating? It will be very disturbing for our users, and it sounds pretty bad, just as if Groovy wasn't production ready. Should we do this, then the incubation phase should be shortened as much as possible. Another option that we consider is what are exactly the deliverables. If the only deliverable is the source zip, because only sources matter (see 3.6), then we could potentially rename only the source zip to include incubating. The binaries, the properties file, etc, could stay with 2.4.3 (without incubating) because it doesn't seem to be mandatory that the *version number* includes incubating, only the filenames. And if we produce binaries that are not hosted at Apache, like we do now, they can follow their own pattern. This would imply that in Groovy, the only deliverable that would be done through Apache would be the source zip, and the *filename* could include incubating. All other artifacts would *not* belong to the release checklist._
+_We need to add the *DISCLAIMER*. The "incubating" part is disturbing. In particular, Groovy is not a new project. It has been around for 12+ years, and the last release before Apache will be 2.4.2. Does it mean that the next release will have to be named 2.4.3-incubating? It will be very disturbing for our users, and it sounds pretty bad, just as if Groovy wasn't production ready. Should we do this, then the incubation phase should be shortened as much as possible. Another option that we consider is what are exactly the deliverables. If the only deliverable is the source zip, because only sources matter (see 3.6), then we could potentially rename only the source zip to include incubating. The binaries, the properties file, etc, could stay with 2.4.3 (without incubating) because it doesn't seem to be mandatory that the *version number* includes incubating, only the filenames. And if we produce binaries that are not hosted at Apache, like we do now, they can follow their own pattern. This would imply that in Groovy, the only deliverable that would be done through Apache would be the source zip, and the *filename* could include incubating. All other artifacts would *not* belong to the release checklist._
 
 * 3.2 Top-level LICENSE and NOTICE are correct for each distribution.