Re: non-gnu elpa issue tracking

[Jean Louis]

* Stefan Kangas <stefankangas@gmail.com> [2020-12-09 19:59]:
> > 2) The acceptance or candidacy process for each package should be
> >    documented in some discrete method. Melpa does this using github's
> >    pull request feature, which documents the entire conversation related
> >    to the process of accepting a package.
> 
> Could you be more specific?  Do you mean that we should document it
> somewhere, or do you mean something else?


My opinion is that things should be transparent. But not to bother
developers it is best to keep it in the mailing list which is
transparent enough and durable over decades. 

> > 4) There's no link on the repository page[1] to the software being used
> >    to generate it, and the forge at which it is being developed. Having
> >    that would make the infrastructure friendlier for pull-requests, bug
> >    reports, and other feedback.
> 
> I assume that there will be a landing page similar to the one on
> elpa.gnu.org.

My opinion is that non-GNU ELPA and GNU ELPA both should never point
to any website that has any proprietary Javascript or promotes
proprietary software, specifically hyperlinks to Github better be
removed completely.

The other issue with licenses should be used to help those people who
left unlicensed packages to license them properly.