diff --git a/htdocs/codingconventions.html b/htdocs/codingconventions.html
index 21cc95de..6c574a28 100644
--- a/htdocs/codingconventions.html
+++ b/htdocs/codingconventions.html
@@ -114,10 +114,12 @@ maintained and kept up to date.  In particular:</p>
 
 <p>
 ChangeLog entries are part of git commit messages and are automatically put
-into a corresponding ChangeLog file.  A ChangeLog template can be easily generated
-with <code>./contrib/mklog.py</code> script.  GCC offers a checking script that
-verifies a proper ChangeLog formatting (see <code>git gcc-verify</code> git alias).
-for a particular git commit.  The checking script covers most commonly used ChangeLog
+into a corresponding <code>ChangeLog</code> file.
+A ChangeLog template can be easily generated by the
+<code>./contrib/mklog.py</code> script.  GCC offers a checking script that
+verifies proper ChangeLog formatting for a particular git commit
+(see the <code>git gcc-verify</code> git alias).
+The checking script covers most commonly used ChangeLog
 formats and the following paragraphs explain what it supports.
 </p>
 
@@ -129,10 +131,12 @@ in comments rather than the ChangeLog, though a single line overall
 description of the changes may be useful above the ChangeLog entry for
 a large batch of changes.</p>
 
-<h3>Components</h3>
+<h3>Components of a git commit message</h3>
 
 <ul>
+    <li><code>subject</code> - a brief description of the commit</li>
     <li><code>git_description</code> - a leading text with git commit description</li>
+    <li><code>sign_off</code> - <a href="https://gcc.gnu.org/dco.html">DCO sign-off</a></li>
     <li><code>committer_timestamp</code> - line with timestamp and an author name and email (2 spaces before and after name) <br>
         example: <code>2020-04-23␣␣Martin Liska␣␣&lt;mliska@suse.cz&gt;</code></li>
     <li><code>additional_author</code> - line with additional commit author name and email (starting with a tabular and 4 spaces) <br>
@@ -153,7 +157,9 @@ a large batch of changes.</p>
 <h3>Format rules</h3>
 
 <ul>
-    <li><code>git_description</code> - optional; ends right before one of the other compoments is found</li>
+    <li><code>subject</code> - a single line in the format described below</li>
+    <li><code>git_description</code> - optional; ends right before one of the other components is found</li>
+    <li><code>sign_off</code> - optional; see <a href="https://gcc.gnu.org/dco.html">DCO</a> policy</li>
     <li><code>committer_timestamp</code> - optional; when found before a <code>changelog_file</code>, then it is added
     to each changelog entry</li>
     <li><code>additional_author</code> - optional</li>
@@ -166,6 +172,65 @@ a large batch of changes.</p>
     <li><code>co_authored_by</code> - optional, can contain more than one</li>
 </ul>
 
+<h4 id="Subject">Subject line</h4>
+
+<p>The first line of the commit message contains a brief summary that
+encapsulates the intent of the change.
+For example: <code>cleanup check_field_decls</code>.
+Although, very short, the summary should be distinct so that it will
+not be confused with other patches.</p>
+
+Additionally, the subject should begin with a component tag, followed by
+an optional series identifier. When related to one or more bugs,
+it should end with the bug numbers.
+
+<p>Ideally, the entire subject line should not exceed 75 characters.</p>
+
+<h4 id="Component">Component tags</h4>
+
+<p>A component tag is a short identifier that identifies the part of
+the compiler being modified.  This highlights to the relevant
+maintainers that the patch may need their attention.  Multiple
+components may be listed if necessary.  Each component tag should be
+followed by a colon.  For example,</p>
+
+<ul>
+  <li><code>libstdc++:</code></li>
+  <li><code>combine:</code></li>
+  <li><code>vax: testsuite:</code></li>
+</ul>
+
+<p>Some large components may be subdivided into sub-components.  If
+the subcomponent name is not disctinct in its own right, you can use the
+form <i>component/sub-component:</i>.</p>
+
+<h4>Series identifier</h4>
+
+<p>The series identifier is optional and is only relevant if a number of
+patches are needed in order to effect an overall change.  It should be
+a <i>short</i> string that identifies the series (it is common to all
+commits in the series) and should be followed by a single dash surrounded
+by white space.</p>
+
+<h4>Bug number</h4>
+
+<p>If your patch is related to a bug in the compiler for which there is an
+existing PR number, the bug number should be stated.  Use the
+short-form variant <code>[PR<i>nnnnn</i>]</code> without the bugzilla
+component identifier and with no space between 'PR' and the number.
+The body of the commit message should still contain the full form
+(<code>PR &lt;component&gt;/<i>nnnnn</i></code>) so that Bugzilla
+will correctly notice the commit.
+If your patch relates to two bugs, then write
+<code>[PR<i>nnnnn</i>, PR<i>mmmmm</i>]</code>.
+For more than two bugs just cite the most relevant one in the summary
+and use an ellipsis after the first one; list all the
+related PRs in the body of the commit message in the full form.</p>
+
+<p>It is not necessary to cite bugs that are closed as duplicates of
+another unless there is something specific to a duplicate report that
+is not covered by its parent bug.</p>
+
 <h3>Documented behaviour</h3>
 
 <ul>
@@ -182,7 +247,9 @@ a large batch of changes.</p>
 
 <h3>Example patch</h3>
 
-<pre><code>This patch adds a second movk pattern that models the instruction
+<pre><code>aarch64: Add an extra sbfiz pattern [PR87763]
+
+This patch adds a second movk pattern that models the instruction
 as a "normal" and/ior operation rather than an insertion.  It fixes
 the third insv_1.c failure in PR87763, which was a regression from
 GCC 8.
@@ -205,7 +272,11 @@ Co-Authored-By: Jack Bar  &lt;jack@example.com&gt;
 <h3>Tokenized patch</h3>
 
 <pre>
-<code>$git_description
+<code>$subject
+
+$git_description
+
+$sign_off
 
 $committer_timestamp
 
diff --git a/htdocs/contribute.html b/htdocs/contribute.html
index c0cce359..b879b2d5 100644
--- a/htdocs/contribute.html
+++ b/htdocs/contribute.html
@@ -243,29 +243,17 @@ can be accessed directly from the repository.)</p>
 <h3>E-mail subject lines</h3>
 
 <p>Your contribution e-mail subject line will become the first line of
-the commit message for your patch.</p>
-
-<p>A high-quality e-mail subject line for a contribution contains the
-following elements:</p>
-
-<ul>
-  <li>A classifier</li>
-  <li>Component tags</li>
-  <li>An optional series identifier</li>
-  <li>A brief summary</li>
-  <li>An optional bug number</li>
-</ul>
-
-<p>The entire line (excluding the classifier) should not exceed 75
-characters.</p>
+the commit message for your patch, so should follow the same
+<a href="codingconventions.html#Subject">format</a>,
+prefixed by a classifier.</p>
 
 <h4>Classifier</h4>
 
-<p>The classifier identifies the type of contribution, for example a
-patch, an RFC (request for comments) or a committed patch (where
-approval is not necessary.  The classifier should be written in upper
-case and surrounded with square brackets.  This is the only component
-of the e-mail subject line that will not appear in the commit itself.
+<p>The classifier identifies the type of contribution, for example a patch,
+an RFC (request for comments) or a committed patch (where approval is not
+necessary).  The classifier should be surrounded with square brackets,
+and is often written all upper case.  This is the only component of the
+e-mail subject line that will not appear in the commit itself.
 The classifier may optionally contain a version number (v<i>N</i>) and
 a series marker (<i>N/M</i>).  Examples are:</p>
 
@@ -275,61 +263,9 @@ a series marker (<i>N/M</i>).  Examples are:</p>
   <li><code>[PATCH 3/7]</code> - the third patch in a series of seven
     patches</li>
   <li><code>[RFC]</code> - a point of discussion, may contain a patch</li>
-  <li><code>[COMMITTED]</code> - a patch that has already been committed.</li>
-</ul>
-
-<h4>Component tags</h4>
-
-<p>A component tag is a short identifier that identifies the part of
-the compiler being modified.  This highlights to the relevant
-maintainers that the patch may need their attention.  Multiple
-components may be listed if necessary.  Each component tag should be
-followed by a colon.  For example,</p>
-
-<ul>
-  <li><code>libstdc++:</code></li>
-  <li><code>combine:</code></li>
-  <li><code>vax: testsuite:</code></li>
+  <li><code>[committed]</code> - a patch that has already been committed.</li>
 </ul>
 
-<p>Some large components may be subdivided into sub-components.  If
-the subcomponent name is not disctinct in its own right, you can use the
-form <i>component/sub-component:</i>.</p>
-
-<h4>Series identifier</h4>
-
-<p>The series identifier is optional and is only relevant if a number of
-patches are needed in order to effect an overall change.  It should be
-a <i>short</i> string that identifies the series (it is common to all
-patches) and should be followed by a single dash surrounded by white
-space.</p>
-
-<h4>A Very Brief summary</h4>
-
-<p>The brief summary encapsulates in a few words the intent of the
-change.  For example: <code>cleanup check_field_decls</code>.
-Although, very short, the summary should be distinct so that it will
-not be confused with other patches.</p>
-
-<h4>Bug number</h4>
-
-<p>If your patch relates a bug in the compiler for which there is an
-existing PR number the bug number should be stated.  Use the
-short-form variant <code>[PR<i>nnnnn</i>]</code> without the bugzilla
-component identifier and with no space between 'PR' and the number.
-The body of the commit message should still contain the full form
-(<code>PR &lt;component&gt;/<i>nnnnn</i></code>) within the body of
-the commit message so that Bugzilla will correctly notice the
-commit.  If your patch relates to two bugs, then write
-<code>[PR<i>nnnnn</i>, PR<i>mmmmm</i>]</code>.  For multiple
-bugs, just cite the most relevant one in the summary and use an
-elipsis instead of the second, or subsequent PR numbers; list all the
-related PRs in the body of the commit message in the normal way.</p>
-
-<p>It is not necessary to cite bugs that are closed as duplicates of
-another unless there is something specific to that report that
-is not covered by the parent bug.</p>
-
 <h4>Other messages</h4>
 
 <p>Some large patch sets benefit from an introductory e-mail that
@@ -362,7 +298,7 @@ original thread indicating that a new version has been submitted.</p>
 <p>Here are some complete examples, based on real commits to GCC.</p>
 
 <ul>
-  <li><code>[COMMITTED] libstdc++: Fix freestanding build [PR92376]</code></li>
+  <li><code>[committed] libstdc++: Fix freestanding build [PR92376]</code></li>
   <li><code>[PATCH 1/6] analyzer: Fix tests for UNKNOWN_LOCATION</code></li>
   <li><code>[RFC] doc: Note that some warnings depend on optimizations [PR92757]</code></li>
   <li><code>[COMMITTED] c++: coroutines - Initial implementation</code></li>
