Re: NonGNU ELPA

[Jean Louis]

* Stefan Monnier <monnier@iro.umontreal.ca> [2020-11-26 17:20]:
> > Yes, we should do that.  It should state the full rules, which
> > I've posted here, adding some details from my previous message.
> > I'll do make that and send it to you.
> 
> FWIW, I've put that in the README.org of nongnu.git
> (http://git.savannah.gnu.org/cgit/emacs/nongnu.git/tree/README.org) in
> the "Guidance for accepting packages" 

Thank you Stefan.

I may have just few thoughts on README.org and I know it is in
progress to be polished.

- head is missing to explain in brief what is nonGNU ELPA

- Regarding heading "The Emacs maintainers will decide what packages
  to put in NonGNU ELPA." as this heading comes so early in "Guidance
  for accepting packages", I would say that the tone of that heading
  gives on me as non native English speaker somewhat negative or
  little bit unwelcoming impression. Maybe it can be said that
  everybody is welcome to apply to include packages in nonGNU ELPA and
  that Emacs maintainers will have final decision based on various
  GNU free software policies. Something like that should or could be
  the first what users read.

- The Org headings are made so that it is not really heading rather
  begin of a sentence. Heading should be summary of a paragraph
  below. I know this is all in progress.

- I feel this sentence as defensive and reiteration what was
  previously said: "** If an ELisp package follows the rules below, we
  can add it to NonGNU ELPA if we want to." -- Instead one could
  formulate it in some positive manner: "Please review the rules below
  and align your package to conform to it to help maintainers make a
  decision" -- something like that, but maybe better formulated.

- "We may also change the code in NonGNU ELPA for other reasons,
  technical or not.  After all, it is free software." -- that is all
  clear and good, I just feel it is defensive for no apparent
  reason. In my opinion it requires some adaptations similar to above.

- "let's discuss it" should have clear pointers which communication
  lines to use, for example there could be hyperlins to the mailing
  list, or how to subscribe to mailing list, or some other
  communication lines. Among thousands of authors it is so that only
  subset of them is participating in GNU mailing lists. They need not
  know how to contact. Also website should give pointers on how to
  contact Emacs maintainers.

- README.org for nonGNU ELPA once polished could be included in etc/
  in distribution

- "FSF conventions" should be maybe hyperlinked to FSF and conventions
  as this way we give some references for further learning as maybe
  people wish to apply with their packages directly to GNU ELPA as
  well and may wish to contribute to Emacs directly. References and
  pointers to that type of contribution should also be included.

- In general I would myself hyperlink many terms such as GNU operating
  system, GNU/Linux to reference on GNU with differences in terms of
  Linux and GNU

- I would exclude the Savannah rule about advertisement as if it is
  general rule than those who advertise may be later warned why, as if
  it is final decision of Emacs maintainers then maintainers will
  handle those incidents. This paragraph is IMHO not necessary as may
  drive people away. It is easy to warn somebody. Advertising could be
  construed as simple placing of a hyperlink. Or telling "Copyright
  Free Software or ABC Foundation". Or otherwise one should clearly
  define what advertisement means.

  When one say "you may not advertise anything commercial" does it
  mean that some commercially sold free software cannot be placed in
  the repository?

  Then there are exeption cited about fan items that one may sell
  directly to user which is somehow contradictory.

  In general that section should be maybe defined better or removed
  and defined in general Savannah rules. As README.org could be
  eventually distributed or mirrored, it can get wide
  distribution. That is why is better to now revise whatever
  maintainers wish to revise.

- "Adding a package" is there, and fine, but nothing says about how
  authors or other people may propose packages to be included. That is
  missing as first step for people to contribute.

- in general it should be more welcoming for contributors to feel more
  free to apply and contribute and to have references how to apply and
  how to contribute. While this is explained partially, it may need
  more description and clarifications.

- There shall be more references to GNU ELPA, to Emacs Lisp manual and
  section Packaging and GNU website.

Thank you for considerations,
Jean