code making it to GNU ELPA, and simply update the "version" when you want to
release the new code.
-** To add a package:
+** To add a package: (submission, submit)
+
+Adding a basic package is very simple. There are thorough
+instructional, but the gist is that you:
+
+1. Notify emacs-devel@gnu.org.
+2. Place all files inside `packages/<pkg-name>/'.
+3. `git add', `git commit' and `git push'.
+
+If you don't have push access to the repository, someone will do steps
+2 and 3 for you.
+
+*** Notify emacs-devel@gnu.org
+
+There is no approval process for GNU Elpa packages. Still,
+you must send an email to emacs-devel for several reasons:
+
+- Notifying other developers;
+- Making sure the package doesn't break FSF rules;
+- Checking if the package is not reinventing the wheel;
+- Ensuring that first-time developers are doing it right.
+
+Before doing anything, please ensure your package follows the
+conventions described in the `** Format' section. Then, send an email
+to the list with the subject:
+ [ELPA] New package: <pkg-name>
+
+Start your message with an explanation about the package. A
+copy-paste of the package's Summary and Commentary is perfectly fine
+here, but you can write more or less than that if you'd like.
+
+At the bottom of the message contents include the changes you're going
+to make (the patch). For a single-file package this can be the
+package file itself instead of the patch. If you prefer (and if you
+have push access), you can push your changes to a branch called
+`scratch/<pkg-name>', and mention the branch in your message.
+
+After 48h, or once any issues have been addressed, someone will push
+your changes for you. You should probably also subscribe to
+emacs-devel@gnu.org, since that's where we discuss about GNU Elpa, and
+to bug-gnu-emacs@gnu.org, since that's where people will report bugs
+about your package.
*** Add a simple (1-file) package as packages/<pkg-name>/<pkg-name>.el.
** External branches
-The easiest way to maintain and develop GNU Elpa packages is to just
-edit them right here (in elpa.git). However, some maintainers may
-prefer to use a dedicated repository or branch for the package. There
-are two ways to do that: subtrees and externals.
+The above instructions are enough to add regular packages, those that
+are maintained primarily here in the repository. The instructions
+below are for those maintainers who prefer to use a dedicated
+repository or branch for the package.
+
+There are two ways to do that: subtrees and externals.
-Such packages should be listed in the `externals-list' file.
+Either way, such packages should always be listed in the
+`externals-list' file.
In both cases, a copy of the code is kept in the `elpa' repository
(not necessarily in the master branch) and should be sync'd with the