Remove "procedure for approving news/events" from policy page
authorMagnus Hagander <magnus@hagander.net>
Thu, 19 Nov 2020 11:57:16 +0000 (12:57 +0100)
committerMagnus Hagander <magnus@hagander.net>
Thu, 19 Nov 2020 12:04:36 +0000 (13:04 +0100)
This should never have been there as it was not part of the policy, it
was instructions for what to do (missed when the page was migrated over
from the wiki). And at this point they are also incorrect due to the new
news posting handling, but it's better to remove them here that they
didn't belong in the first place.

As this does not contain any changes to the actual policy, this commit
does not bump the "last updated" date of the page.

templates/pages/about/policies/news-and-events.html

index a8dc6331b96d2432ae1ff895257fb3dac8de0d11..2b4c71bcafacf58933b29c014bde4c8f7a455800 100644 (file)
     contributors to the PostgreSQL project will be restricted to one news item
     of any kind per six-month period.</p>
 
-<h3>Procedure for Approving pgsql-announce</h3>
-
-<p>Since pgsql-announce goes to over 30,000 addresses, we are cautious in what
-    we approve to that list. In some cases, this may result in a delay of up to
-    several days in approving announcements.</p>
-
-<ol><li>Check if it's spam and reject spam.</li>
-    <li>Check if there is anything else in the 'To' or 'CC' list besides
-        -announce; if so, reject and ask for re-submission.
-    </li>
-    <li>Read the announcement</li>
-    <li>Consider if the announcement meets this policy and is appropriate for
-        announcement
-        <ul>
-            <li>if necessary, check on pgsql-www list</li>
-        </ul>
-    </li>
-    <li>Approve or Reject</li>
-</ol>
-<p>In any case where an approver has doubts about whether to approve an
-    announcement or not, they should err on the side of caution.</p>
-
-<p>Please note that PostgreSQL major/minor release posts should be handled by
-    the release team, not by the pgsql-announce moderators.</p>
-
 <h2>Approving Events and Event-Related News (excluding training)</h2>
 
 <p>Events must have significant PostgreSQL-related content in order to be
 <p>In the event that any training company submits more than 4 training events to
     be held in any given quarter, site admins may (at their discretion) deny
     posting events to that company.</p>
-
-<h2>Rejection Notices</h2>
-
-<p>In cases where the submitter appears to have gone to some effort to submit a
-    relevant news item or event, but doesn't understand our policies, we should
-    send them a rejection e-mail linking to this page and explaining what was
-    wrong with their submission. This certainly goes for any of the major
-    project sponsors.</p>
-
-<p>If the submission looks like a 30-second cut-and-paste job, or something else
-    sloppy and quick, or is a submission by someone who has had multiple
-    submissions rejected in the past for the same reason, don't bother sending a
-    response. We get too much spam for that.</p>
-
-<p>Any company which has had submissions repeatedly rejected for the same
-    reasons, and does not correct their errors when notified, risks having their
-    community account suspended and their ability to submit news and events
-    blocked.</p>
 {%endblock%}