Merge pull request #67 from kikofernandez/eep0-update

eep-0001: update EEP process

eeps/eep-0001.md

@@ -3,7 +3,9 @@
     Status: Draft
     Type: Process
     Created: 29-Jan-2007
-    Post-History: 29-Jan-2007
+    Post-History:
+        29-Jan-2007
+        25-Oct-2024
 ****
 EEP 1: EEP Purpose and Guidelines
 ----
@@ -52,7 +54,8 @@ EEP Work Flow
 =============
 
 The EEP editors assign EEP numbers and change their status.  Please
-send all EEP-related email to <[email protected]>.
+create EEPs by opening a pull request to the repository
+[https://github.com/erlang/eep](https://github.com/erlang/eep).
 
 The EEP process begins with a new idea for Erlang.  It is highly
 recommended that a single EEP contain a single key proposal or new
@@ -66,40 +69,30 @@ style and format described below, shepherds the discussions in the
 appropriate forums, and attempts to build community consensus around
 the idea.  The EEP champion (a.k.a. Author) should first attempt to
 ascertain whether the idea is EEP-able.  Posting to the
-<[email protected]> mailing list is recommended. Small
+[ErlangForum](https://erlangforums.com/) is recommended. Small
 enhancements or patches often don't need a EEP and can be injected
-into the Erlang development work flow by sending a patch to
-<erlang[email protected]>.
+into the Erlang development work flow by creating a pull request to
+[https://github.com/erlang/otp](https://github.com/erlang/otp)
 
 The EEP champion writes a rough but fleshed out draft of the EEP, with
 a proposed title. This draft must be written in EEP style as described
-below. Then, after subscribing to the email list <[email protected]>,
-the EEP champion sends the EEP to that list.  Note that the list has a
-size limit for posts, at the time of writing 128 KByte, so EEPs with
-attachments that are too large will bounce. Large attachments can be
-put on a suitable web page and then be referred to from the EEP.  If
-that is not possible, ask on the list how to submit the large EEP in
-question.
-
-If the EEP editor approves, she/he will assign the EEP a number, label
-it as Standards Track or Process, give it status "Draft", and create
-and check-in the initial draft of the EEP.  The EEP editor will not
-unreasonably deny a EEP.  Reasons for denying EEP status include
-duplication of effort, being technically unsound, not providing proper
-motivation or addressing backwards compatibility, or not in keeping
-with the Erlang philosophy.
+below. The EEP champion can tentatively assign the next available EEP
+number to their EEP, label it as Standards Track or Process, and give
+it status "Draft". Then, the EEP champion sends the EEP to the EEP
+repo ([https://github.com/erlang/eep](https://github.com/erlang/eep)).
+The EEP editor will not unreasonably deny a EEP.  Reasons for denying
+EEP status include duplication of effort, being technically unsound,
+not providing proper motivation or addressing backwards compatibility,
+or not in keeping with the Erlang philosophy.
 
 If a pre-EEP is rejected, the author may elect to take the pre-EEP to
-the <[email protected]> mailing list to help flesh it out,
+the [ErlangForum](https://erlangforums.com/) to help flesh it out,
 gain feedback and consensus from the community at large, and improve
 the EEP for re-submission.
 
 The author of the EEP is then responsible for posting the EEP to the
 community forums, and marshaling community support for it.  As updates
-are necessary, the EEP author can check in new versions if they have
-commit permissions, can email new EEP versions or diffs to the EEP
-editor for committing, or submit changes in any other suitable
-way for the version control system.
+are necessary, the EEP author can check in new versions.
 
 Standards Track EEPs consist of two parts, a design document and a
 reference implementation.  The EEP should be reviewed and accepted
@@ -110,12 +103,13 @@ or a URL to same -- before it can be considered Final.
 
 EEP authors are responsible for collecting community feedback on a EEP
 before submitting it for review.  A EEP that has not been discussed on
-the erlang mailing list will not be accepted.  However, wherever
-possible, long open-ended discussions on public mailing lists should
-be avoided.  Strategies to keep the discussions efficient include:
-setting up a separate SIG mailing list for the topic, having the EEP
-author accept private comments in the early design phases, setting up
-a wiki page, etc.  EEP authors should use their discretion here.
+the [ErlangForum](https://erlangforums.com/) will not be accepted.
+However, wherever possible, long open-ended discussions on public
+forums should be avoided.  Strategies to keep the discussions
+efficient include: creation of a new topic in the
+[ErlangForum](https://erlangforums.com/), having the EEP author accept
+private comments in the early design phases, setting up a wiki page,
+etc.  EEP authors should use their discretion here.
 
 Once the authors have completed a EEP, they must inform the EEP editor
 that it is ready for review. EEPs are reviewed by a committee of
@@ -270,13 +264,6 @@ following RFC 2822 continuation line conventions.  Note that personal
 email addresses should be obscured as a defense against spam
 harvesters.
 
-While a EEP is in private discussions (usually during the initial
-Draft phase), a Discussions-To header will indicate the mailing list
-or URL where the EEP is being discussed.  No Discussions-To header is
-necessary if the EEP is being discussed privately with the author, or
-on the erlang mailing list.  Remember to obscure email addresses here
-to.
-
 The Type header specifies the type of EEP: Standards Track or Process.
 
 The Created header records the date that the EEP was assigned a
@@ -313,12 +300,12 @@ factors, such as the maturity of the EEP, the preferences of the EEP
 author, and the nature of your comments. For the early draft stages
 of the EEP, it's probably best to send your comments and changes
 directly to the EEP author. For more mature, or finished EEPs you may
-want to submit corrections to the <[email protected]> mailing list.
+want to submit corrections to the [EEP repository](https://github.com/erlang/eep).
 
 When in doubt about where to send your changes, please check first
 with the EEP author and/or EEP editor.
 
-EEP authors can update EEPs by submitting new versions to the editors.
+EEP authors can update EEPs by submitting changes to thei pull requests.
 
 Transferring EEP Ownership
 ==========================
@@ -336,7 +323,7 @@ that's not possible, you can always submit a competing EEP.
 
 If you are interested in assuming ownership of a EEP, send a message
 asking to take over, addressed to both the original author and the EEP
-editor <[email protected]>.  If the original author doesn't respond to
+editor.  If the original author doesn't respond to
 email in a timely manner, the EEP editor will make a unilateral
 decision (it's not like such decisions can't be reversed :).