Re: ELPA policy (was: Imports / inclusion of s.el into Emacs)

[Philippe Vaucher <philippe.vaucher@gmail.com>]

> > > So maybe it's time we defined the minimum requirements for packages to
> > > be included in ELPA?
> >
> > Why not simply use MELPA's one?
> >
> > https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org
>
> I'd prefer to start from our CONTRIBUTE, since (AFAIU) GNU ELPA is
> supposed to be part of the Emacs project.  Commonality of requirements
> is important IMO to make it easier to contribute a package: we could
> then decide relatively easily whether to add the package to core or to
> ELPA.

Sure, but from a quick look at it CONTRIBUTE lacks a lot of what
https://github.com/melpa/melpa/blob/master/CONTRIBUTING.org#making-your-package-ready-for-inclusion
proposes and would make sense for inclusion in ELPA. I'll copy the
relevant parts of that section here:

- Coding style and conventions: The Emacs Lisp files should follow the
Emacs Lisp conventions and the Emacs Lisp Style Guide.
- Package metadata: Package descriptions should adhere to the
package.el format as specified by (info "(elisp) Packaging")
documentation. More information on this format is provided by the
marmalade package manual.
- Use quality-checking tools: Use flycheck, package-lint and
flycheck-package to help you identify common errors in your package
metadata. Use checkdoc to make sure that your package follows the
conventions for documentation strings.
- Avoid long functions: The longer a function the harder it is for a
MELPA maintainer to understand what is happening and to give feedback.
It is also much harder to point to a specific portion of the code we
believe could be improved. Please spend time decomposing your long
functions into smaller, well-named and documented, ones.

I'm sure that if we read the MELPA recommendations more in depth we'd
find even more inspiration as to what ELPA's policy could be.