From 83a0e6ae83aac7c1e84399436223345406b99702 Mon Sep 17 00:00:00 2001
From: "Jonathan S. Katz" <jonathan.katz@excoventures.com>
Date: Fri, 28 Jun 2019 13:14:53 -0400
Subject: [PATCH] Treat RFC2119 conventions with all caps on the recognition
 pages.

This makes it easier to see them when one is reading.
---
 templates/pages/community/recognition.html | 62 +++++++++++-----------
 1 file changed, 31 insertions(+), 31 deletions(-)

diff --git a/templates/pages/community/recognition.html b/templates/pages/community/recognition.html
index 71136733..64476563 100644
--- a/templates/pages/community/recognition.html
+++ b/templates/pages/community/recognition.html
@@ -23,52 +23,52 @@
 <p>Recognised PostgreSQL Nonprofit Organisations (NPOs) will be listed on the <a href="/">PostgreSQL Website</a> as such. To become recognised as an NPO, the organisation must self-certify that they meet the criteria below, aimed at ensuring they meet the standards of openness expected in the PostgreSQL Community.
 </p>
 <p>
-  Use of the terms "must", "must not", "should" and "should not" in the criteria below should be interpreted per <a href="https://www.ietf.org/rfc/rfc2119.txt" target="_blank">RFC2119</a>.
+  Use of the terms "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in the criteria below should be interpreted per <a href="https://www.ietf.org/rfc/rfc2119.txt" target="_blank">RFC2119</a>.
 </p>
 
 <h3>General</h3>
 
 <ul>
-  <li>A Code of Conduct should be adopted and apply to all members and directors.</li>
-  <li>The organisation must be registered as a Non Profit Organisation in the territory in which it operates.</li>
+  <li>A Code of Conduct SHOULD be adopted and apply to all members and directors.</li>
+  <li>The organisation MUST be registered as a Non Profit Organisation in the territory in which it operates.</li>
   <li>No payments may be made to directors or members for their service with the exception of reimbursement of expenses incurred on the organisation's business, and sponsorship of conference attendance where deemed appropriate to help ensure the success of an event.</li>
-  <li>The organisation must work towards the betterment of the PostgreSQL Project and/or community. It may not participate in any activities which may bring the project into disrepute or otherwise work against the interests of the project or the community.</li>
+  <li>The organisation MUST work towards the betterment of the PostgreSQL Project and/or community. It may not participate in any activities which may bring the project into disrepute or otherwise work against the interests of the project or the community.</li>
   <li>The <a href="/developer/core/">PostgreSQL Core Team</a> may recognise, not recognise, or rescind a previous recognition of any organisation without justification, regardless of whether or not the criteria above are met.</li>
   <li>These criteria may be reviewed and potentially updated at any time.</li>
 </ul>
 
 <h3>Membership</h3>
 <ul>
-  <li>Membership must be open to anyone, limited only to the geographic area in which the NPO operates or a specific spoken language, if desired.</li>
-  <li>Membership must be at zero cost or a nominal cost (up to US $50 per year) to allow participation from any interested community members.</li>
+  <li>Membership MUST be open to anyone, limited only to the geographic area in which the NPO operates or a specific spoken language, if desired.</li>
+  <li>Membership MUST be at zero cost or a nominal cost (up to US $50 per year) to allow participation from any interested community members.</li>
   <li>Corporate memberships may be allowed, at higher cost than individual membership if desired, provided the same membership terms are available to any company.</li>
-  <li>Membership must be renewed at least once every three years. "Lifetime" memberships must not be allowed.</li>
+  <li>Membership MUST be renewed at least once every three years. "Lifetime" memberships MUST NOT be allowed.</li>
 </ul>
 
 <h3>Directors</h3>
 <ul>
-  <li>The board of directors must be elected by the membership, and all members including any corporate members must have an equal vote.</li>
-  <li>The board of directors should not consist of 50% or more directors working for the same company or group of companies under the same ultimate ownership or management, a situation which must be actively avoided as much as is possible. Should such a situation arise, for example, following the resignation of a director, an election should be held as soon as possible to restore the balance of the board.</li>
-  <li>Director terms must last no longer than three years without re-election. A limit on the number of terms served may be set. "Lifetime" directorships must not be allowed.</li>
+  <li>The board of directors MUST be elected by the membership, and all members including any corporate members MUST have an equal vote.</li>
+  <li>The board of directors SHOULD NOT consist of 50% or more directors working for the same company or group of companies under the same ultimate ownership or management, a situation which MUST be actively avoided as much as is possible. Should such a situation arise, for example, following the resignation of a director, an election SHOULD be held as soon as possible to restore the balance of the board.</li>
+  <li>Director terms MUST last no longer than three years without re-election. A limit on the number of terms served may be set. "Lifetime" directorships MUST NOT be allowed.</li>
 </ul>
 
 <h3>Vetting</h3>
 <ul>
-  <li>Voting for the board of directors must be done in a way that may be externally vetted.</li>
-  <li>Financial reports must be published at least annually for review by the membership.</li>
-  <li>The organisation must make its financial reports and voting processes and records available to the <a href="/developer/core/">PostgreSQL Core Team</a> or their nominated representative for review if requested.</li>
+  <li>Voting for the board of directors MUST be done in a way that may be externally vetted.</li>
+  <li>Financial reports MUST be published at least annually for review by the membership.</li>
+  <li>The organisation MUST make its financial reports and voting processes and records available to the <a href="/developer/core/">PostgreSQL Core Team</a> or their nominated representative for review if requested.</li>
 </ul>
 
 <a name="conferences" />
 <h2>Community Conference Recognition</h2>
 <p>The Community Conference Recognition programme is a voluntary scheme under which submitters of events to the <a href="/about/events/">PostgreSQL Website listings</a> may self-assess their entry against the criteria below, and if they comply may market their event as a PostgreSQL Community event.</p>
 <p>Events that do not meet the criteria will still be welcomed (where appropriate under the <a href="https://wiki.postgresql.org/wiki/NewsEventsApproval#Approving_Events_and_Event-Related_News_.28excluding_training.29" target="_blank">general listing policies</a>) - for example, events organised by a single company which may still be valuable for people to attend, but are not necessarily what we would consider fully "open."</p>
-<p>Use of the terms "must", "must not", "should" and "should not" in the criteria below should be interpreted per <a href="https://www.ietf.org/rfc/rfc2119.txt" target="_blank">RFC2119</a>.</p>
+<p>Use of the terms "MUST", "MUST NOT", "SHOULD" and "SHOULD NOT" in the criteria below should be interpreted per <a href="https://www.ietf.org/rfc/rfc2119.txt" target="_blank">RFC2119</a>.</p>
 
 <h3>General</h3>
 <ul>
-  <li>The event must be primarily focused on PostgreSQL and targeted at existing and/or potential developers and users of PostgreSQL.</li>
-  <li>The event must adopt and follow an appropriate Code of Conduct to ensure a safe and enjoyable environment for anyone who wishes to attend.</li>
+  <li>The event MUST be primarily focused on PostgreSQL and targeted at existing and/or potential developers and users of PostgreSQL.</li>
+  <li>The event MUST adopt and follow an appropriate Code of Conduct to ensure a safe and enjoyable environment for anyone who wishes to attend.</li>
   <li>The <a href="/developer/core/">PostgreSQL Core Team</a> reserves the right to recognise, not recognise, or rescind a previous recognition for any event without justification.</li>
   <li>Events are self-certified as complying with these criteria when <a href="/about/events/">listed on the PostgreSQL Website</a>. If an event is self-certified by the organisers and later found not to comply with the criteria, the <a href="/developer/core/">PostgreSQL Core Team</a> reserves the right to rescind the recognition of the event as a community event and, where appropriate, take further action up to a permanent ban on future event listings from the organisers.</li>
   <li>These criteria may be reviewed and potentially updated at any time.</li>
@@ -76,31 +76,31 @@
 
 <h3>Talk selection</h3>
 <ul>
-  <li>The talk selection committee must be fully disclosed on the event website.</li>
-  <li>The talk selection committee must NOT consist of 50% or more members from a single company or group of companies under the same ultimate ownership or management.</li>
-  <li>All members of the talk committee must have an equal vote (except in case of a tie-breaker).</li>
-  <li>The Call For Papers must be open for anyone to submit.</li>
-  <li>Solicited or sponsor keynote presentations may bypass the normal talk selection process, but their topics must be approved by a majority of the talk committee.</li>
-  <li>The full talk selection process and voting system must be fully disclosed to all members of the talk committee.</li>
-  <li>Details of the talk selection process and how results were obtained must be provided to the <a href="/developer/core/">PostgreSQL Core Team</a> on request.</li>
+  <li>The talk selection committee MUST be fully disclosed on the event website.</li>
+  <li>The talk selection committee MUST NOT consist of 50% or more members from a single company or group of companies under the same ultimate ownership or management.</li>
+  <li>All members of the talk committee MUST have an equal vote (except in case of a tie-breaker).</li>
+  <li>The Call For Papers MUST be open for anyone to submit.</li>
+  <li>Solicited or sponsor keynote presentations may bypass the normal talk selection process, but their topics MUST be approved by a majority of the talk committee.</li>
+  <li>The full talk selection process and voting system MUST be fully disclosed to all members of the talk committee.</li>
+  <li>Details of the talk selection process and how results were obtained MUST be provided to the <a href="/developer/core/">PostgreSQL Core Team</a> on request.</li>
 </ul>
 
 <h3>Sponsorship</h3>
 <ul>
-  <li>The sponsorship terms and/or prospectus must be published on the event website for public review.</li>
-  <li>All sponsors of the same level or type must be treated equally; they must be offered the same benefits at the same cost as all others.</li>
-  <li>Changes to the benefits offered should not be made following publication, and must not be made following the first executed sponsor agreement.</li>
-  <li>There should not be an exclusive top sponsorship level.</li>
-  <li>Sponsor benefits for all levels or types should include a listing on the event website. Ordering of the sponsor listing must be in randomised or predictable order with text stating how they are ordered, grouped by level or type of sponsorship.</li>
-  <li>Sponsorship opportunities should be open to all, offered on a first-come, first-served basis. Limits on the number of any given level or type of sponsorship may be set.</li>
+  <li>The sponsorship terms and/or prospectus MUST be published on the event website for public review.</li>
+  <li>All sponsors of the same level or type MUST be treated equally; they MUST be offered the same benefits at the same cost as all others.</li>
+  <li>Changes to the benefits offered SHOULD NOT be made following publication, and MUST NOT be made following the first executed sponsor agreement.</li>
+  <li>There SHOULD NOT be an exclusive top sponsorship level.</li>
+  <li>Sponsor benefits for all levels or types SHOULD include a listing on the event website. Ordering of the sponsor listing MUST be in randomised or predictable order with text stating how they are ordered, grouped by level or type of sponsorship.</li>
+  <li>Sponsorship opportunities SHOULD be open to all, offered on a first-come, first-served basis. Limits on the number of any given level or type of sponsorship may be set.</li>
   <li>Only recognised sponsors may exhibit at the event, or be listed on the event website or other materials.</li>
 </ul>
 
 <h3>Financial</h3>
 <ul>
-  <li>The event organisers must provide copies of financial records to the <a href="/developer/core/">PostgreSQL Core Team</a> or their nominated representative for review if requested. Any financial statements shared with the Core Team will not be distributed by the Core Team to any 3rd parties without written permission from the event organisers or where required by court order or other forms of legal authority.</li>
+  <li>The event organisers MUST provide copies of financial records to the <a href="/developer/core/">PostgreSQL Core Team</a> or their nominated representative for review if requested. Any financial statements shared with the Core Team will not be distributed by the Core Team to any 3rd parties without written permission from the event organisers or where required by court order or other forms of legal authority.</li>
   <li>
-    A statement on the event website must indicate where any profits from the event will go, which specifically must support PostgreSQL community activities, either through:
+    A statement on the event website MUST indicate where any profits from the event will go, which specifically MUST support PostgreSQL community activities, either through:
     <ol>
       <li>a <a href="#npos">recognized PostgreSQL Nonprofit Organisation</a></li>
       <li>a detailed list of how the profits will support
-- 
2.39.5