GNU bug report logs - #76925
[PATCH] admin/notes/elpa: Add note on contributing to external packages

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 76925 in the body.
You can then email your comments to 76925 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] admin/notes/elpa: Add note on contributing to external
 packages
Date: Mon, 10 Mar 2025 12:15:48 -0700

[Message part 1 (text/plain, inline)]

Severity: wishlist

I'm forwarding this from emacs-devel so that we don't lose track of it.

-------------------- Start of forwarded message --------------------
From: david <davidimagid <at> gmail.com>
To: emacs-devel <at> gnu.org
Cc: Stefan Kangas <stefankangas <at> gmail.com>, Philip Kaludercic
 <philipk <at> posteo.net>
Subject: [PATCH] admin/notes/elpa: Add note on contributing to external
 packages
Date: Mon, 10 Mar 2025 09:01:38 -0400

[Message part 2 (text/plain, attachment)]

[0001-Add-note-about-externally-hosted-packages-to-admin-n.patch (text/x-patch, attachment)]

[Message part 4 (text/plain, attachment)]

[Message part 5 (text/plain, attachment)]

Message #8 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: davidimagid <at> gmail.com, philipk <at> posteo.net, 76925 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing to
 external packages
Date: Tue, 11 Mar 2025 14:07:39 +0200

> Cc: david <davidimagid <at> gmail.com>, Philip Kaludercic <philipk <at> posteo.net>,
>  Stefan Monnier <monnier <at> iro.umontreal.ca>
> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Mon, 10 Mar 2025 12:15:48 -0700
> 
> I'm forwarding this from emacs-devel so that we don't lose track of it.

Is ELPA documentation exempt from our convention to use US English?

Message #11 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: davidimagid <at> gmail.com, philipk <at> posteo.net, 76925 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing to
 external packages
Date: Tue, 11 Mar 2025 08:40:46 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Cc: david <davidimagid <at> gmail.com>, Philip Kaludercic <philipk <at> posteo.net>,
>>  Stefan Monnier <monnier <at> iro.umontreal.ca>
>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Mon, 10 Mar 2025 12:15:48 -0700
>>
>> I'm forwarding this from emacs-devel so that we don't lose track of it.
>
> Is ELPA documentation exempt from our convention to use US English?

AFAIK, no.

Message #14 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: davidimagid <at> gmail.com, philipk <at> posteo.net, 76925 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing to
 external packages
Date: Tue, 11 Mar 2025 15:33:57 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Tue, 11 Mar 2025 08:40:46 -0400
> Cc: 76925 <at> debbugs.gnu.org, davidimagid <at> gmail.com, philipk <at> posteo.net, 
> 	monnier <at> iro.umontreal.ca
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Cc: david <davidimagid <at> gmail.com>, Philip Kaludercic <philipk <at> posteo.net>,
> >>  Stefan Monnier <monnier <at> iro.umontreal.ca>
> >> From: Stefan Kangas <stefankangas <at> gmail.com>
> >> Date: Mon, 10 Mar 2025 12:15:48 -0700
> >>
> >> I'm forwarding this from emacs-devel so that we don't lose track of it.
> >
> > Is ELPA documentation exempt from our convention to use US English?
> 
> AFAIK, no.

Then there a few nits to be fixed in that text.  Like two spaces
between sentences.

Message #17 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: 76925 <at> debbugs.gnu.org
Subject: [PATCH Bug#76925] Add note about externally hosted packages to
 admin/notes/elpa
Date: Tue, 11 Mar 2025 11:43:57 -0400

Hi,

This patch fixes the issue described in Bug#76925 by clarifying the
guidelines for contributing to externally hosted packages in GNU ELPA.  
The changes include:

1. Added two spaces after periods for better readability.
2. Clarified the process for making local changes in `elpa.git`.

Please review and let me know if any further changes are needed.

Thanks,
David D.

Message #20 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: philipk <at> posteo.net, 76925 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>, monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Tue, 11 Mar 2025 11:52:43 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Tue, 11 Mar 2025 08:40:46 -0400
>> Cc: 76925 <at> debbugs.gnu.org, davidimagid <at> gmail.com, philipk <at> posteo.net, 
>> 	monnier <at> iro.umontreal.ca
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Cc: david <davidimagid <at> gmail.com>, Philip Kaludercic <philipk <at> posteo.net>,
>> >>  Stefan Monnier <monnier <at> iro.umontreal.ca>
>> >> From: Stefan Kangas <stefankangas <at> gmail.com>
>> >> Date: Mon, 10 Mar 2025 12:15:48 -0700
>> >>
>> >> I'm forwarding this from emacs-devel so that we don't lose track of it.
>> >
>> > Is ELPA documentation exempt from our convention to use US English?
>> 
>> AFAIK, no.
>
> Then there a few nits to be fixed in that text.  Like two spaces
> between sentences.

Hi,

This patch fixes the issue described in Bug#76925 by clarifying the
guidelines for contributing to externally hosted packages in GNU ELPA.  
The changes include:

1. Added two spaces after periods for better readability.
2. Clarified the process for making local changes in `elpa.git`.

Please review and let me know if any further changes are needed.

Thanks,
David D.

[0001-Add-note-about-externally-hosted-packages-to-admin-n.patch (text/x-patch, inline)]

From 4970c30be128f9806edd8d14dff82103edf49264 Mon Sep 17 00:00:00 2001
From: dimagid <dimagidve <at> gmail.com>
Date: Mon, 10 Mar 2025 08:39:40 -0400
Subject: [PATCH Bug#76925] Add note about externally hosted packages to
 admin/notes/elpa

---
 admin/notes/elpa | 71 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 71 insertions(+)

diff --git a/admin/notes/elpa b/admin/notes/elpa
index afcda71d1dd..c6debf4bfce 100644
--- a/admin/notes/elpa
+++ b/admin/notes/elpa
@@ -33,3 +33,74 @@ the package.
 
 It is easy to use the elpa branch to deploy a "local" copy of the
 package archive.  For details, see the README file in the elpa branch.
+
+* Contributing to Externally Hosted Packages
+
+Some GNU ELPA packages are primarily developed in external repositories
+(e.g., on GitHub, GitLab, or similar platforms).  If you maintain such
+a package, it is important to ensure that contributors understand the
+requirements for contributing, especially when it comes to copyright
+assignment to the Free Software Foundation (FSF).  Here’s what you need
+to do:
+
+1. Include Clear Contribution Guidelines in Your Repository
+   Ensure your external repository's README or CONTRIBUTING file
+   includes the following:
+   - A notice that the package is distributed through GNU ELPA.
+   - A statement that contributors must assign copyright for their
+     contributions to the FSF, if the contribution is significant
+     (e.g., more than a few lines of code).
+   - For complete information, see the CONTRIBUTE file in the Emacs
+     repository.
+
+2. Handling Contributions Requiring Copyright Assignment
+   When a contributor submits a pull request or patch that requires
+   copyright assignment:
+   - Acknowledge the Contribution: Thank the contributor and let them
+     know that their contribution will need to go through the FSF’s
+     copyright assignment process before it can be merged.
+   - Explain the Process: Provide the contributor with clear
+     instructions on how to complete the copyright assignment process.
+     This typically involves:
+     - Filling out the FSF’s copyright assignment form.
+     - Sending the signed form to the FSF.
+     - Waiting for confirmation from the FSF that the assignment has
+       been processed.
+   - Point to Resources: Direct the contributor to the FSF’s copyright
+     assignment page for more information:
+     https://www.fsf.org/licensing/assigning.html
+
+3. Consult with GNU ELPA Administrators
+   If you are unsure whether a contribution requires copyright
+   assignment or how to handle a specific case:
+   - Consult with the GNU ELPA administrators by emailing
+     emacs-devel <at> gnu.org.
+   - Provide details about the contribution (e.g., the size of the
+     patch, the contributor’s contact information, and any relevant
+     context).
+
+4. Merging Contributions
+   Once the contributor has completed the copyright assignment process
+   and you have received confirmation from the FSF:
+   - Merge the contribution into your external repository.  Note that
+     repositories under `elpa.git` should not be modified directly by
+     Emacs developers, as their upstreams are not expected to merge
+     changes made there.  Instead, contributions should be made to the
+     external repository and then synchronized with `elpa.git`.
+   - In exceptional cases, minor local changes may be made directly in
+     `elpa.git` (e.g., to adapt the package to the ELPA environment).
+     However, these changes will not be reflected in the upstream
+     repository and should be kept to a minimum.
+   - Ensure the contributor is properly credited in the commit history.
+   - If applicable, update the AUTHORS or THANKS file in your
+     repository to acknowledge their contribution.
+
+5. Maintaining Compliance
+   - Periodically review your repository’s contribution guidelines to
+     ensure they are up-to-date and align with GNU ELPA policies.
+   - Stay in touch with the GNU ELPA administrators to address any
+     questions or concerns about contributions and copyright assignment.
+
+By following these steps, you can ensure that contributions to your
+externally hosted package are handled in a way that complies with
+GNU ELPA policies and respects the FSF’s copyright requirements.
-- 
2.48.1

Message #23 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: david <davidimagid <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>, monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Tue, 11 Mar 2025 21:02:01 +0000

david <davidimagid <at> gmail.com> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> From: Stefan Kangas <stefankangas <at> gmail.com>
>>> Date: Tue, 11 Mar 2025 08:40:46 -0400
>>> Cc: 76925 <at> debbugs.gnu.org, davidimagid <at> gmail.com, philipk <at> posteo.net, 
>>> 	monnier <at> iro.umontreal.ca
>>> 
>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>> 
>>> >> Cc: david <davidimagid <at> gmail.com>, Philip Kaludercic <philipk <at> posteo.net>,
>>> >>  Stefan Monnier <monnier <at> iro.umontreal.ca>
>>> >> From: Stefan Kangas <stefankangas <at> gmail.com>
>>> >> Date: Mon, 10 Mar 2025 12:15:48 -0700
>>> >>
>>> >> I'm forwarding this from emacs-devel so that we don't lose track of it.
>>> >
>>> > Is ELPA documentation exempt from our convention to use US English?
>>> 
>>> AFAIK, no.
>>
>> Then there a few nits to be fixed in that text.  Like two spaces
>> between sentences.
>
> Hi,
>
> This patch fixes the issue described in Bug#76925 by clarifying the
> guidelines for contributing to externally hosted packages in GNU ELPA.  
> The changes include:
>
> 1. Added two spaces after periods for better readability.
> 2. Clarified the process for making local changes in `elpa.git`.
>
> Please review and let me know if any further changes are needed.
>
> Thanks,
> David D.
>
> From 4970c30be128f9806edd8d14dff82103edf49264 Mon Sep 17 00:00:00 2001
> From: dimagid <dimagidve <at> gmail.com>
> Date: Mon, 10 Mar 2025 08:39:40 -0400
> Subject: [PATCH Bug#76925] Add note about externally hosted packages to
>  admin/notes/elpa
>
> ---
>  admin/notes/elpa | 71 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 71 insertions(+)
>
> diff --git a/admin/notes/elpa b/admin/notes/elpa
> index afcda71d1dd..c6debf4bfce 100644
> --- a/admin/notes/elpa
> +++ b/admin/notes/elpa
> @@ -33,3 +33,74 @@ the package.
>  
>  It is easy to use the elpa branch to deploy a "local" copy of the
>  package archive.  For details, see the README file in the elpa branch.
> +
> +* Contributing to Externally Hosted Packages
> +
> +Some GNU ELPA packages are primarily developed in external repositories
> +(e.g., on GitHub, GitLab, or similar platforms).  If you maintain such
> +a package, it is important to ensure that contributors understand the
> +requirements for contributing, especially when it comes to copyright
> +assignment to the Free Software Foundation (FSF).  Here’s what you need
> +to do:
> +
> +1. Include Clear Contribution Guidelines in Your Repository
> +   Ensure your external repository's README or CONTRIBUTING file

Why is this partially title-cased?

> +   includes the following:
> +   - A notice that the package is distributed through GNU ELPA.
> +   - A statement that contributors must assign copyright for their
> +     contributions to the FSF, if the contribution is significant
> +     (e.g., more than a few lines of code).
> +   - For complete information, see the CONTRIBUTE file in the Emacs
> +     repository.

Also, this is not a requirement.  There is no need for any README file
at all, and I don't think we should force people to have them.

> +
> +2. Handling Contributions Requiring Copyright Assignment
> +   When a contributor submits a pull request or patch that requires
> +   copyright assignment:
> +   - Acknowledge the Contribution: Thank the contributor and let them
> +     know that their contribution will need to go through the FSF’s
> +     copyright assignment process before it can be merged.
> +   - Explain the Process: Provide the contributor with clear
> +     instructions on how to complete the copyright assignment process.
> +     This typically involves:
> +     - Filling out the FSF’s copyright assignment form.
> +     - Sending the signed form to the FSF.
> +     - Waiting for confirmation from the FSF that the assignment has
> +       been processed.
> +   - Point to Resources: Direct the contributor to the FSF’s copyright
> +     assignment page for more information:
> +     https://www.fsf.org/licensing/assigning.html

I would mention the fifteen-line thumb-rule for "significance of a
contribution" somewhere here.

> +
> +3. Consult with GNU ELPA Administrators
> +   If you are unsure whether a contribution requires copyright
> +   assignment or how to handle a specific case:
> +   - Consult with the GNU ELPA administrators by emailing
> +     emacs-devel <at> gnu.org.
> +   - Provide details about the contribution (e.g., the size of the
> +     patch, the contributor’s contact information, and any relevant
> +     context).
> +
> +4. Merging Contributions
> +   Once the contributor has completed the copyright assignment process
> +   and you have received confirmation from the FSF:
> +   - Merge the contribution into your external repository.  Note that
> +     repositories under `elpa.git` should not be modified directly by
> +     Emacs developers, as their upstreams are not expected to merge
> +     changes made there.  Instead, contributions should be made to the
> +     external repository and then synchronized with `elpa.git`.

Should we clarify that the ELPA administrators might commit to the
repository if the upstream development appears to have stagnated and is
not reachable?

> +   - In exceptional cases, minor local changes may be made directly in
> +     `elpa.git` (e.g., to adapt the package to the ELPA environment).
> +     However, these changes will not be reflected in the upstream
> +     repository and should be kept to a minimum.
> +   - Ensure the contributor is properly credited in the commit history.
> +   - If applicable, update the AUTHORS or THANKS file in your
> +     repository to acknowledge their contribution.
> +
> +5. Maintaining Compliance
> +   - Periodically review your repository’s contribution guidelines to
> +     ensure they are up-to-date and align with GNU ELPA policies.
> +   - Stay in touch with the GNU ELPA administrators to address any
> +     questions or concerns about contributions and copyright assignment.
> +
> +By following these steps, you can ensure that contributions to your
> +externally hosted package are handled in a way that complies with
> +GNU ELPA policies and respects the FSF’s copyright requirements.

(A general comment on the tone makes this sound more micro-managey than
I think is necessary.  IMO it is better to have a relaxed atmosphere
than having it sound too "corporate" for lack of a better word.)

Message #26 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>, monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Tue, 11 Mar 2025 17:50:23 -0400

Philip Kaludercic <philipk <at> posteo.net> writes:

> david <davidimagid <at> gmail.com> writes:
>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>>>> From: Stefan Kangas <stefankangas <at> gmail.com>
>>>> Date: Tue, 11 Mar 2025 08:40:46 -0400
>>>> Cc: 76925 <at> debbugs.gnu.org, davidimagid <at> gmail.com, philipk <at> posteo.net, 
>>>> 	monnier <at> iro.umontreal.ca
>>>> 
>>>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>>> 
>>>> >> Cc: david <davidimagid <at> gmail.com>, Philip Kaludercic <philipk <at> posteo.net>,
>>>> >>  Stefan Monnier <monnier <at> iro.umontreal.ca>
>>>> >> From: Stefan Kangas <stefankangas <at> gmail.com>
>>>> >> Date: Mon, 10 Mar 2025 12:15:48 -0700
>>>> >>
>>>> >> I'm forwarding this from emacs-devel so that we don't lose track of it.
>>>> >
>>>> > Is ELPA documentation exempt from our convention to use US English?
>>>> 
>>>> AFAIK, no.
>>>
>>> Then there a few nits to be fixed in that text.  Like two spaces
>>> between sentences.
>>
>> Hi,
>>
>> This patch fixes the issue described in Bug#76925 by clarifying the
>> guidelines for contributing to externally hosted packages in GNU ELPA.  
>> The changes include:
>>
>> 1. Added two spaces after periods for better readability.
>> 2. Clarified the process for making local changes in `elpa.git`.
>>
>> Please review and let me know if any further changes are needed.
>>
>> Thanks,
>> David D.
>>
>> From 4970c30be128f9806edd8d14dff82103edf49264 Mon Sep 17 00:00:00 2001
>> From: dimagid <dimagidve <at> gmail.com>
>> Date: Mon, 10 Mar 2025 08:39:40 -0400
>> Subject: [PATCH Bug#76925] Add note about externally hosted packages to
>>  admin/notes/elpa
>>
>> ---
>>  admin/notes/elpa | 71 ++++++++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 71 insertions(+)
>>
>> diff --git a/admin/notes/elpa b/admin/notes/elpa
>> index afcda71d1dd..c6debf4bfce 100644
>> --- a/admin/notes/elpa
>> +++ b/admin/notes/elpa
>> @@ -33,3 +33,74 @@ the package.
>>  
>>  It is easy to use the elpa branch to deploy a "local" copy of the
>>  package archive.  For details, see the README file in the elpa branch.
>> +
>> +* Contributing to Externally Hosted Packages
>> +
>> +Some GNU ELPA packages are primarily developed in external repositories
>> +(e.g., on GitHub, GitLab, or similar platforms).  If you maintain such
>> +a package, it is important to ensure that contributors understand the
>> +requirements for contributing, especially when it comes to copyright
>> +assignment to the Free Software Foundation (FSF).  Here’s what you need
>> +to do:
>> +
>> +1. Include Clear Contribution Guidelines in Your Repository
>> +   Ensure your external repository's README or CONTRIBUTING file
>
> Why is this partially title-cased?
>
>> +   includes the following:
>> +   - A notice that the package is distributed through GNU ELPA.
>> +   - A statement that contributors must assign copyright for their
>> +     contributions to the FSF, if the contribution is significant
>> +     (e.g., more than a few lines of code).
>> +   - For complete information, see the CONTRIBUTE file in the Emacs
>> +     repository.
>
> Also, this is not a requirement.  There is no need for any README file
> at all, and I don't think we should force people to have them.
>

Ok I can fix that.

>> +
>> +2. Handling Contributions Requiring Copyright Assignment
>> +   When a contributor submits a pull request or patch that requires
>> +   copyright assignment:
>> +   - Acknowledge the Contribution: Thank the contributor and let them
>> +     know that their contribution will need to go through the FSF’s
>> +     copyright assignment process before it can be merged.
>> +   - Explain the Process: Provide the contributor with clear
>> +     instructions on how to complete the copyright assignment process.
>> +     This typically involves:
>> +     - Filling out the FSF’s copyright assignment form.
>> +     - Sending the signed form to the FSF.
>> +     - Waiting for confirmation from the FSF that the assignment has
>> +       been processed.
>> +   - Point to Resources: Direct the contributor to the FSF’s copyright
>> +     assignment page for more information:
>> +     https://www.fsf.org/licensing/assigning.html
>
> I would mention the fifteen-line thumb-rule for "significance of a
> contribution" somewhere here.
>

I can also include this.

>> +
>> +3. Consult with GNU ELPA Administrators
>> +   If you are unsure whether a contribution requires copyright
>> +   assignment or how to handle a specific case:
>> +   - Consult with the GNU ELPA administrators by emailing
>> +     emacs-devel <at> gnu.org.
>> +   - Provide details about the contribution (e.g., the size of the
>> +     patch, the contributor’s contact information, and any relevant
>> +     context).
>> +
>> +4. Merging Contributions
>> +   Once the contributor has completed the copyright assignment process
>> +   and you have received confirmation from the FSF:
>> +   - Merge the contribution into your external repository.  Note that
>> +     repositories under `elpa.git` should not be modified directly by
>> +     Emacs developers, as their upstreams are not expected to merge
>> +     changes made there.  Instead, contributions should be made to the
>> +     external repository and then synchronized with `elpa.git`.
>
> Should we clarify that the ELPA administrators might commit to the
> repository if the upstream development appears to have stagnated and is
> not reachable?
>

The original PATCH didn't address this. The ELPA README mentions
it briefly, but on emacs-devel, I was advised to include a
reference to it here.

>> +   - In exceptional cases, minor local changes may be made directly in
>> +     `elpa.git` (e.g., to adapt the package to the ELPA environment).
>> +     However, these changes will not be reflected in the upstream
>> +     repository and should be kept to a minimum.
>> +   - Ensure the contributor is properly credited in the commit history.
>> +   - If applicable, update the AUTHORS or THANKS file in your
>> +     repository to acknowledge their contribution.
>> +
>> +5. Maintaining Compliance
>> +   - Periodically review your repository’s contribution guidelines to
>> +     ensure they are up-to-date and align with GNU ELPA policies.
>> +   - Stay in touch with the GNU ELPA administrators to address any
>> +     questions or concerns about contributions and copyright assignment.
>> +
>> +By following these steps, you can ensure that contributions to your
>> +externally hosted package are handled in a way that complies with
>> +GNU ELPA policies and respects the FSF’s copyright requirements.
>
> (A general comment on the tone makes this sound more micro-managey than
> I think is necessary.  IMO it is better to have a relaxed atmosphere
> than having it sound too "corporate" for lack of a better word.)

Hi Philip,

I proposed this patch after receiving a pull request for my recently
published ELPA package—a minor typo fix. This made me wonder: what if a
significant contribution comes from an unknown developer? I checked the
ELPA README and the document I'm patching but found no explicit
guidance. While I know that ELPA contributors must sign the FSF
copyright assignment for substantial code changes, I believe we should
provide clearer instructions for handling external contributions,
especially for authors and maintainers looking to publish new packages
on GNU ELPA.

However, ELPA code can transition to the core with minimal friction.
This is why I propose clarifying these details in the patch wording,
and why I included this in the Emacs developer notes.

Message #29 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925 <at> debbugs.gnu.org,
 Stefan Kangas <stefankangas <at> gmail.com>, monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Wed, 12 Mar 2025 08:06:23 -0400

[Message part 1 (text/plain, inline)]

Philip Kaludercic <philipk <at> posteo.net> writes:
>
> (A general comment on the tone makes this sound more micro-managey than
> I think is necessary.  IMO it is better to have a relaxed atmosphere
> than having it sound too "corporate" for lack of a better word.)

Updated patch incorporating feedback:

- Adjusted tone to be more collaborative.
- Clarified GNU ELPA admins' role in upstream stagnation.
- Ensured consistent sentence case in headings.

Please review and suggest further improvements.

Thanks,
David D.

[0001-Add-note-about-externally-hosted-packages-to-admin-n.patch (text/x-patch, inline)]

From 09842ebfbf8b123351bdec9c05e4aedff7ab640d Mon Sep 17 00:00:00 2001
From: dimagid <dimagidve <at> gmail.com>
Date: Mon, 10 Mar 2025 08:39:40 -0400
Subject: [PATCH Bug#76925] Add note about externally hosted packages to
 admin/notes/elpa

This commit adds a section to admin/notes/elpa documenting best practices
for maintaining externally hosted GNU ELPA packages.  It covers contribution
guidelines, copyright assignment, and synchronization with elpa.git, while
emphasizing a collaborative and relaxed approach to package maintenance.
---
 admin/notes/elpa | 77 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 77 insertions(+)

diff --git a/admin/notes/elpa b/admin/notes/elpa
index afcda71d1dd..6a5f2a5c360 100644
--- a/admin/notes/elpa
+++ b/admin/notes/elpa
@@ -33,3 +33,80 @@ the package.
 
 It is easy to use the elpa branch to deploy a "local" copy of the
 package archive.  For details, see the README file in the elpa branch.
+
+* Contributing to externally hosted packages
+
+Some GNU ELPA packages are primarily developed in external repositories
+(e.g., on GitHub, GitLab, or similar platforms).  If you maintain such
+a package, it’s important to help contributors understand the
+requirements for contributing, especially when it comes to copyright
+assignment to the Free Software Foundation (FSF).  Here’s what you can
+do:
+
+1. Include clear contribution guidelines in your repository
+   If you include a README or CONTRIBUTING file in your external
+   repository, consider adding the following:
+   - A notice that the package is distributed through GNU ELPA.
+   - A statement that contributors must assign copyright for their
+     contributions to the FSF if the contribution is significant
+     (e.g., more than a few lines of code, following the fifteen-line
+     thumb-rule).
+   - For complete information, see the CONTRIBUTE file in the Emacs
+     repository.
+
+2. Handling contributions requiring copyright assignment
+   When a contributor submits a pull request or patch that requires
+   copyright assignment:
+   - Acknowledge the contribution: Thank the contributor and let them
+     know that their contribution will need to go through the FSF’s
+     copyright assignment process before it can be merged.
+   - Explain the process: Provide the contributor with clear
+     instructions on how to complete the copyright assignment process.
+     This typically involves:
+     - Filling out the FSF’s copyright assignment form.
+     - Sending the signed form to the FSF.
+     - Waiting for confirmation from the FSF that the assignment has
+       been processed.
+   - Point to resources: Direct the contributor to the FSF’s copyright
+     assignment page for more information:
+     https://www.fsf.org/licensing/assigning.html
+
+3. Consult with GNU ELPA administrators
+   If you’re unsure whether a contribution requires copyright
+   assignment or how to handle a specific case:
+   - Reach out to the GNU ELPA administrators by emailing
+     emacs-devel <at> gnu.org.
+   - Provide details about the contribution (e.g., the size of the
+     patch, the contributor’s contact information, and any relevant
+     context).
+
+4. Merging contributions
+   Once the contributor has completed the copyright assignment process
+   and you’ve received confirmation from the FSF:
+   - Merge the contribution into your external repository.  Note that
+     repositories under `elpa.git` should not be modified directly by
+     Emacs developers, as their upstreams are not expected to merge
+     changes made there.  Instead, contributions should be made to the
+     external repository and then synchronized with `elpa.git`.
+     However, if the upstream development appears to have stagnated and
+     the maintainers are unreachable, the GNU ELPA administrators may
+     commit changes directly to `elpa.git` to ensure the package remains
+     functional and up-to-date.
+   - In exceptional cases, minor local changes may be made directly in
+     `elpa.git` (e.g., to adapt the package to the ELPA environment).
+     However, these changes will not be reflected in the upstream
+     repository and should be kept to a minimum.
+   - Make sure to credit the contributor in the commit history.
+   - If applicable, update the AUTHORS or THANKS file in your
+     repository to acknowledge their contribution.
+
+5. Maintaining compliance
+   - It’s a good idea to periodically review your repository’s
+     contribution guidelines to keep them up-to-date and aligned with
+     GNU ELPA policies.
+   - Stay in touch with the GNU ELPA administrators to address any
+     questions or concerns about contributions and copyright assignment.
+
+By following these steps, you can help ensure that contributions to your
+externally hosted package are handled in a way that complies with GNU
+ELPA policies and respects the FSF’s copyright requirements.
-- 
2.48.1

Message #32 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: 76925 <at> debbugs.gnu.org
Cc: Po Lu <luangruo <at> yahoo.com>, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>,
 monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Fri, 21 Mar 2025 10:12:44 -0400

david <davidimagid <at> gmail.com> writes:

> Updated patch incorporating feedback:
>
> - Adjusted tone to be more collaborative.
> - Clarified GNU ELPA admins' role in upstream stagnation.
> - Ensured consistent sentence case in headings.
>
> Please review and suggest further improvements.
>
> Thanks,
> David D.
>
> From 09842ebfbf8b123351bdec9c05e4aedff7ab640d Mon Sep 17 00:00:00 2001
> From: dimagid <dimagidve <at> gmail.com>
> Date: Mon, 10 Mar 2025 08:39:40 -0400
> Subject: [PATCH Bug#76925] Add note about externally hosted packages to
>  admin/notes/elpa
>
> This commit adds a section to admin/notes/elpa documenting best practices
> for maintaining externally hosted GNU ELPA packages.  It covers contribution
> guidelines, copyright assignment, and synchronization with elpa.git, while
> emphasizing a collaborative and relaxed approach to package maintenance.
> ---
>  admin/notes/elpa | 77 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
>
> diff --git a/admin/notes/elpa b/admin/notes/elpa
> index afcda71d1dd..6a5f2a5c360 100644
> --- a/admin/notes/elpa
> +++ b/admin/notes/elpa
> @@ -33,3 +33,80 @@ the package.
>  
>  It is easy to use the elpa branch to deploy a "local" copy of the
>  package archive.  For details, see the README file in the elpa branch.
> +
> +* Contributing to externally hosted packages
> +
> +Some GNU ELPA packages are primarily developed in external repositories
> +(e.g., on GitHub, GitLab, or similar platforms).  If you maintain such
> +a package, it’s important to help contributors understand the
> +requirements for contributing, especially when it comes to copyright
> +assignment to the Free Software Foundation (FSF).  Here’s what you can
> +do:
> +
> +1. Include clear contribution guidelines in your repository
> +   If you include a README or CONTRIBUTING file in your external
> +   repository, consider adding the following:
> +   - A notice that the package is distributed through GNU ELPA.
> +   - A statement that contributors must assign copyright for their
> +     contributions to the FSF if the contribution is significant
> +     (e.g., more than a few lines of code, following the fifteen-line
> +     thumb-rule).
> +   - For complete information, see the CONTRIBUTE file in the Emacs
> +     repository.
> +
> +2. Handling contributions requiring copyright assignment
> +   When a contributor submits a pull request or patch that requires
> +   copyright assignment:
> +   - Acknowledge the contribution: Thank the contributor and let them
> +     know that their contribution will need to go through the FSF’s
> +     copyright assignment process before it can be merged.
> +   - Explain the process: Provide the contributor with clear
> +     instructions on how to complete the copyright assignment process.
> +     This typically involves:
> +     - Filling out the FSF’s copyright assignment form.
> +     - Sending the signed form to the FSF.
> +     - Waiting for confirmation from the FSF that the assignment has
> +       been processed.
> +   - Point to resources: Direct the contributor to the FSF’s copyright
> +     assignment page for more information:
> +     https://www.fsf.org/licensing/assigning.html
> +
> +3. Consult with GNU ELPA administrators
> +   If you’re unsure whether a contribution requires copyright
> +   assignment or how to handle a specific case:
> +   - Reach out to the GNU ELPA administrators by emailing
> +     emacs-devel <at> gnu.org.
> +   - Provide details about the contribution (e.g., the size of the
> +     patch, the contributor’s contact information, and any relevant
> +     context).
> +
> +4. Merging contributions
> +   Once the contributor has completed the copyright assignment process
> +   and you’ve received confirmation from the FSF:
> +   - Merge the contribution into your external repository.  Note that
> +     repositories under `elpa.git` should not be modified directly by
> +     Emacs developers, as their upstreams are not expected to merge
> +     changes made there.  Instead, contributions should be made to the
> +     external repository and then synchronized with `elpa.git`.
> +     However, if the upstream development appears to have stagnated and
> +     the maintainers are unreachable, the GNU ELPA administrators may
> +     commit changes directly to `elpa.git` to ensure the package remains
> +     functional and up-to-date.
> +   - In exceptional cases, minor local changes may be made directly in
> +     `elpa.git` (e.g., to adapt the package to the ELPA environment).
> +     However, these changes will not be reflected in the upstream
> +     repository and should be kept to a minimum.
> +   - Make sure to credit the contributor in the commit history.
> +   - If applicable, update the AUTHORS or THANKS file in your
> +     repository to acknowledge their contribution.
> +
> +5. Maintaining compliance
> +   - It’s a good idea to periodically review your repository’s
> +     contribution guidelines to keep them up-to-date and aligned with
> +     GNU ELPA policies.
> +   - Stay in touch with the GNU ELPA administrators to address any
> +     questions or concerns about contributions and copyright assignment.
> +
> +By following these steps, you can help ensure that contributions to your
> +externally hosted package are handled in a way that complies with GNU
> +ELPA policies and respects the FSF’s copyright requirements.

Hello everyone,

I wanted to check if there’s any feedback on this PATCH. It was updated
on the 12th of this month, incorporating previous recommendations and
suggestions, but I haven’t received any further comments since
then. Could you let me know what steps are needed to move forward with
incorporating this change?

Thank you in advance!

Message #35 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: david <davidimagid <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing to
 external packages
Date: Sat, 22 Mar 2025 17:39:44 -0500

david <davidimagid <at> gmail.com> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>>
>> (A general comment on the tone makes this sound more micro-managey than
>> I think is necessary.  IMO it is better to have a relaxed atmosphere
>> than having it sound too "corporate" for lack of a better word.)
>
> Updated patch incorporating feedback:
>
> - Adjusted tone to be more collaborative.

Thanks.

> - Clarified GNU ELPA admins' role in upstream stagnation.

What does this mean?

>>From 09842ebfbf8b123351bdec9c05e4aedff7ab640d Mon Sep 17 00:00:00 2001
> From: dimagid <dimagidve <at> gmail.com>
> Date: Mon, 10 Mar 2025 08:39:40 -0400
> Subject: [PATCH Bug#76925] Add note about externally hosted packages to
>  admin/notes/elpa
>
> This commit adds a section to admin/notes/elpa documenting best practices
> for maintaining externally hosted GNU ELPA packages.  It covers contribution
> guidelines, copyright assignment, and synchronization with elpa.git, while
> emphasizing a collaborative and relaxed approach to package maintenance.
> ---
>  admin/notes/elpa | 77 ++++++++++++++++++++++++++++++++++++++++++++++++
>  1 file changed, 77 insertions(+)
>
> diff --git a/admin/notes/elpa b/admin/notes/elpa
> index afcda71d1dd..6a5f2a5c360 100644
> --- a/admin/notes/elpa
> +++ b/admin/notes/elpa
> @@ -33,3 +33,80 @@ the package.
>
>  It is easy to use the elpa branch to deploy a "local" copy of the
>  package archive.  For details, see the README file in the elpa branch.
> +
> +* Contributing to externally hosted packages
> +
> +Some GNU ELPA packages are primarily developed in external repositories
> +(e.g., on GitHub, GitLab, or similar platforms).  If you maintain such
> +a package, it’s important to help contributors understand the
> +requirements for contributing, especially when it comes to copyright
> +assignment to the Free Software Foundation (FSF).  Here’s what you can
> +do:

Please don't use the ’ code point (0x2019 RIGHT SINGLE QUOTATION MARK);
use the ' code point (0x27 APOSTROPHE) instead.  This is for
consistency.

BTW, which Emacs mode are you editing this in to automatically insert
0x2019?  Here, I usually only get that character in Emacs when I have copied
from other software, such as an LLM, or when I copy from *Help* buffers
or *Messages* (where it's inserted automatically).

> +1. Include clear contribution guidelines in your repository
> +   If you include a README or CONTRIBUTING file in your external
> +   repository, consider adding the following:
> +   - A notice that the package is distributed through GNU ELPA.
> +   - A statement that contributors must assign copyright for their
> +     contributions to the FSF if the contribution is significant
> +     (e.g., more than a few lines of code, following the fifteen-line
> +     thumb-rule).

Clarify what is the "fifteen-line thumb-rule" here.

> +   - For complete information, see the CONTRIBUTE file in the Emacs
> +     repository.
> +
> +2. Handling contributions requiring copyright assignment
> +   When a contributor submits a pull request or patch that requires
> +   copyright assignment:
> +   - Acknowledge the contribution: Thank the contributor and let them
> +     know that their contribution will need to go through the FSF’s
> +     copyright assignment process before it can be merged.
> +   - Explain the process: Provide the contributor with clear
> +     instructions on how to complete the copyright assignment process.
> +     This typically involves:
> +     - Filling out the FSF’s copyright assignment form.
> +     - Sending the signed form to the FSF.
> +     - Waiting for confirmation from the FSF that the assignment has
> +       been processed.

Instead of "typically", say "always".

> +   - Point to resources: Direct the contributor to the FSF’s copyright
> +     assignment page for more information:
> +     https://www.fsf.org/licensing/assigning.html

The bullet point headings "Acknowledge the contribution", "Explain the
process", "Point to resources" can be taken out.

> +3. Consult with GNU ELPA administrators
> +   If you’re unsure whether a contribution requires copyright
> +   assignment or how to handle a specific case:
> +   - Reach out to the GNU ELPA administrators by emailing
> +     emacs-devel <at> gnu.org.
> +   - Provide details about the contribution (e.g., the size of the
> +     patch, the contributor’s contact information, and any relevant
> +     context).

Change "contact information" to "email address".  We don't need or want
more specific information than that.

> +4. Merging contributions
> +   Once the contributor has completed the copyright assignment process
> +   and you’ve received confirmation from the FSF:
> +   - Merge the contribution into your external repository.  Note that
> +     repositories under `elpa.git` should not be modified directly by
> +     Emacs developers, as their upstreams are not expected to merge
> +     changes made there.  Instead, contributions should be made to the
> +     external repository and then synchronized with `elpa.git`.

Yes.

> +     However, if the upstream development appears to have stagnated and
> +     the maintainers are unreachable, the GNU ELPA administrators may
> +     commit changes directly to `elpa.git` to ensure the package remains
> +     functional and up-to-date.

This is not our process in that case.  We would reach out to upstream,
look for a new maintainer, etc.  IOW, many other steps become relevant
before we take that drastic step.

In particular, we would always set `:url nil` first.

> +   - In exceptional cases, minor local changes may be made directly in
> +     `elpa.git` (e.g., to adapt the package to the ELPA environment).
> +     However, these changes will not be reflected in the upstream
> +     repository and should be kept to a minimum.

I wouldn't mention this here.  "Be kept to a minimum" is a bit
misleading, since AFAIK this has never happened.  If we should say
anything, we should say that.

> +   - Make sure to credit the contributor in the commit history.
> +   - If applicable, update the AUTHORS or THANKS file in your
> +     repository to acknowledge their contribution.

Fair enough, but do we really need to repeat that?

> +5. Maintaining compliance
> +   - It’s a good idea to periodically review your repository’s
> +     contribution guidelines to keep them up-to-date and aligned with
> +     GNU ELPA policies.

What would this look like?  I'm not aware that any maintainer is doing
specific review work besides what happens when new contributors show up.

> +   - Stay in touch with the GNU ELPA administrators to address any
> +     questions or concerns about contributions and copyright assignment.

I'm even less sure what this might concretely look like.

> +By following these steps, you can help ensure that contributions to your
> +externally hosted package are handled in a way that complies with GNU
> +ELPA policies and respects the FSF’s copyright requirements.

I'm not sure what this paragraph specifically adds.

In general, I'm not sure about the intended target audience for this
documentation.  The documentation in admin/notes is usually directed at
people maintaining Emacs, while documentation directed at package
maintainers usually go to elpa.git/README (and related files).

Maybe we should keep only the small note that boils down to:

    Don't commit changes directly to packages in GNU ELPA without
    checking first that they have :url nil.

And related explanations.

Message #38 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, monnier <at> iro.umontreal.ca
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sat, 22 Mar 2025 21:20:38 -0400

[Message part 1 (text/plain, inline)]

Stefan Kangas <stefankangas <at> gmail.com> writes:

> BTW, which Emacs mode are you editing this in to automatically insert
> 0x2019?
>
I manually used the ’ character in the text.

>> +1. Include clear contribution guidelines in your repository
>> +   If you include a README or CONTRIBUTING file in your external
>> +   repository, consider adding the following:
>> +   - A notice that the package is distributed through GNU ELPA.
>> +   - A statement that contributors must assign copyright for their
>> +     contributions to the FSF if the contribution is significant
>> +     (e.g., more than a few lines of code, following the fifteen-line
>> +     thumb-rule).
>
> Clarify what is the "fifteen-line thumb-rule" here.
>
>> +   - For complete information, see the CONTRIBUTE file in the Emacs
>> +     repository.
>> +
>> +2. Handling contributions requiring copyright assignment
>> +   When a contributor submits a pull request or patch that requires
>> +   copyright assignment:
>> +   - Acknowledge the contribution: Thank the contributor and let them
>> +     know that their contribution will need to go through the FSF’s
>> +     copyright assignment process before it can be merged.
>> +   - Explain the process: Provide the contributor with clear
>> +     instructions on how to complete the copyright assignment process.
>> +     This typically involves:
>> +     - Filling out the FSF’s copyright assignment form.
>> +     - Sending the signed form to the FSF.
>> +     - Waiting for confirmation from the FSF that the assignment has
>> +       been processed.
>
> Instead of "typically", say "always".
>
>> +   - Point to resources: Direct the contributor to the FSF’s copyright
>> +     assignment page for more information:
>> +     https://www.fsf.org/licensing/assigning.html
>
> The bullet point headings "Acknowledge the contribution", "Explain the
> process", "Point to resources" can be taken out.
>
>> +3. Consult with GNU ELPA administrators
>> +   If you’re unsure whether a contribution requires copyright
>> +   assignment or how to handle a specific case:
>> +   - Reach out to the GNU ELPA administrators by emailing
>> +     emacs-devel <at> gnu.org.
>> +   - Provide details about the contribution (e.g., the size of the
>> +     patch, the contributor’s contact information, and any relevant
>> +     context).
>
> Change "contact information" to "email address".  We don't need or want
> more specific information than that.
>
>> +4. Merging contributions
>> +   Once the contributor has completed the copyright assignment process
>> +   and you’ve received confirmation from the FSF:
>> +   - Merge the contribution into your external repository.  Note that
>> +     repositories under `elpa.git` should not be modified directly by
>> +     Emacs developers, as their upstreams are not expected to merge
>> +     changes made there.  Instead, contributions should be made to the
>> +     external repository and then synchronized with `elpa.git`.
>
> Yes.
>
>> +     However, if the upstream development appears to have stagnated and
>> +     the maintainers are unreachable, the GNU ELPA administrators may
>> +     commit changes directly to `elpa.git` to ensure the package remains
>> +     functional and up-to-date.
>
> This is not our process in that case.  We would reach out to upstream,
> look for a new maintainer, etc.  IOW, many other steps become relevant
> before we take that drastic step.
>
> In particular, we would always set `:url nil` first.
>
>> +   - In exceptional cases, minor local changes may be made directly in
>> +     `elpa.git` (e.g., to adapt the package to the ELPA environment).
>> +     However, these changes will not be reflected in the upstream
>> +     repository and should be kept to a minimum.
>
> I wouldn't mention this here.  "Be kept to a minimum" is a bit
> misleading, since AFAIK this has never happened.  If we should say
> anything, we should say that.
>
>> +   - Make sure to credit the contributor in the commit history.
>> +   - If applicable, update the AUTHORS or THANKS file in your
>> +     repository to acknowledge their contribution.
>
> Fair enough, but do we really need to repeat that?
>
>> +5. Maintaining compliance
>> +   - It’s a good idea to periodically review your repository’s
>> +     contribution guidelines to keep them up-to-date and aligned with
>> +     GNU ELPA policies.
>
> What would this look like?  I'm not aware that any maintainer is doing
> specific review work besides what happens when new contributors show up.
>
>> +   - Stay in touch with the GNU ELPA administrators to address any
>> +     questions or concerns about contributions and copyright assignment.
>
> I'm even less sure what this might concretely look like.
>
>> +By following these steps, you can help ensure that contributions to your
>> +externally hosted package are handled in a way that complies with GNU
>> +ELPA policies and respects the FSF’s copyright requirements.
>
> I'm not sure what this paragraph specifically adds.
>
> In general, I'm not sure about the intended target audience for this
> documentation.  The documentation in admin/notes is usually directed at
> people maintaining Emacs, while documentation directed at package
> maintainers usually go to elpa.git/README (and related files).
>
The addition of this section aims to provide guidance for new GNU ELPA
package developers.  It serves as a reminder in admin/notes about the
process for accepting contributions and maintaining packages, ensuring
ongoing compliance with GNU ELPA licensing policies.

> Maybe we should keep only the small note that boils down to:
>
>     Don't commit changes directly to packages in GNU ELPA without
>     checking first that they have :url nil.
>
> And related explanations.

I've attached the updated patch incorporating your feedback, emphasizing
the need to check `:url nil` before direct commits to GNU ELPA.  I'll
wait for further instructions to proceed.

[0001-Add-note-about-externally-hosted-packages-to-admin-n.patch (text/x-patch, attachment)]

Message #41 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: 76925 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sat, 22 Mar 2025 22:39:42 -0400

david [2025-03-22 21:20:38] wrote:
> Stefan Kangas <stefankangas <at> gmail.com> writes:
>> BTW, which Emacs mode are you editing this in to automatically insert
>> 0x2019?
> I manually used the ’ character in the text.

How?


        Stefan

Message #44 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, Philip Kaludercic <philipk <at> posteo.net>,
 76925 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sat, 22 Mar 2025 22:44:06 -0400

>> This commit adds a section to admin/notes/elpa documenting best practices
>> for maintaining externally hosted GNU ELPA packages.  It covers contribution
>> guidelines, copyright assignment, and synchronization with elpa.git, while
>> emphasizing a collaborative and relaxed approach to package maintenance.

I don't understand this.  Who is this for?  What problem does it aim to solve?
Why hide it in that location?


        Stefan "who hasn't looked at the presumably preceding discussion
                in emacs-devel"

Message #47 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Po Lu <luangruo <at> yahoo.com>, Philip Kaludercic <philipk <at> posteo.net>,
 76925 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 07:45:45 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>>> This commit adds a section to admin/notes/elpa documenting best practices
>>> for maintaining externally hosted GNU ELPA packages.  It covers contribution
>>> guidelines, copyright assignment, and synchronization with elpa.git, while
>>> emphasizing a collaborative and relaxed approach to package maintenance.
>
> I don't understand this.  Who is this for?  What problem does it aim to solve?
> Why hide it in that location?
>
>
>         Stefan "who hasn't looked at the presumably preceding discussion
>                 in emacs-devel"

This discussion started on emacs-devel but was moved here to
bug-gnu-emacs for further review and tracking.  If you think this
information should also go elsewhere, I'm happy to do that.  However, I
don't believe admin/notes/elpa is a hidden location for Emacs
developers.

This addition to admin/notes/elpa targets developers maintaining
externally hosted GNU ELPA packages, especially newcomers.  It provides
guidance on contributions, copyright assignment, and synchronization
with elpa.git, ensuring compliance with GNU ELPA policies.

Related questions that may arise:

- Can GNU ELPA packages be developed in unofficial repositories,
  potentially violating GNU Emacs policies?  (Yes: some packages stop
  updating in GNU ELPA but continue in unofficial repos, detaching them
  from GNU Emacs if added to `package-archives`.)

- Can Emacs recommend updates for GNU ELPA packages from NonGNU ELPA or
  unofficial archives?  (Yes: I've seen built-in packages that can be
  updated—as long as the archive is added to `package-archives`—from
  unofficial repositories, bypassing GNU ELPA policies.  Ideally,
  development should continue in GNU ELPA, and a warning should be shown
  when a built-in package or a package originally from GNU ELPA is
  proposed to be updated from outside GNU ELPA.)

- Are these cases considered policy violations for packages in GNU ELPA?

The proposed section in the Emacs developer notes aims to address these
questions in a general sense, providing guidance for new developers on
these topics.  When GNU ELPA policies are violated—or could be violated,
such as by accepting a pull request or incorporating code that is not
under FSF copyright—Emacs maintainers and developers will have the
clarity and guidelines needed to take appropriate action and defend GNU
Emacs' interests.

Message #50 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: david <davidimagid <at> gmail.com>
Cc: luangruo <at> yahoo.com, philipk <at> posteo.net, 76925 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, stefankangas <at> gmail.com
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 14:02:16 +0200

> From: david <davidimagid <at> gmail.com>
> Cc: 76925 <at> debbugs.gnu.org,  Po Lu <luangruo <at> yahoo.com>,  Philip Kaludercic
>  <philipk <at> posteo.net>,  Eli Zaretskii <eliz <at> gnu.org>,  Stefan Kangas
>  <stefankangas <at> gmail.com>
> Date: Sun, 23 Mar 2025 07:45:45 -0400
> 
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
> 
> > I don't understand this.  Who is this for?  What problem does it aim to solve?
> > Why hide it in that location?
> >
> >
> >         Stefan "who hasn't looked at the presumably preceding discussion
> >                 in emacs-devel"
> 
> This discussion started on emacs-devel but was moved here to
> bug-gnu-emacs for further review and tracking.  If you think this
> information should also go elsewhere, I'm happy to do that.  However, I
> don't believe admin/notes/elpa is a hidden location for Emacs
> developers.

Why do you think admin/notes/elpa is not a hidden location for Emacs
developers?  Who do you think the admin/notes/ directory is for?

> Related questions that may arise:

Who may raise this questions, and in what contexts?

> - Are these cases considered policy violations for packages in GNU ELPA?

Which cases, and why do you think they might be policy violations?

> The proposed section in the Emacs developer notes aims to address these
> questions in a general sense

How can a question be addressed "in a general sense"?  Shouldn't every
question be addressed specifically and in a targeted manner, answering
exactly the question and nothing else?

> When GNU ELPA policies are violated—or could be violated,
> such as by accepting a pull request or incorporating code that is not
> under FSF copyright—Emacs maintainers and developers will have the
> clarity and guidelines needed to take appropriate action and defend GNU
> Emacs' interests.

If code that violates the policies is accepted, how can the Emacs
maintainers do anything post-factum to defend GNU interests?  Code
that is accepted into the Git repository is carved in stone, and
cannot be removed from Git, ever.

Message #53 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, philipk <at> posteo.net, 76925 <at> debbugs.gnu.org,
 monnier <at> iro.umontreal.ca, stefankangas <at> gmail.com
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 09:27:38 -0400

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: david <davidimagid <at> gmail.com>
>> Cc: 76925 <at> debbugs.gnu.org,  Po Lu <luangruo <at> yahoo.com>,  Philip Kaludercic
>>  <philipk <at> posteo.net>,  Eli Zaretskii <eliz <at> gnu.org>,  Stefan Kangas
>>  <stefankangas <at> gmail.com>
>> Date: Sun, 23 Mar 2025 07:45:45 -0400
>> 
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> 
>> > I don't understand this.  Who is this for?  What problem does it aim to solve?
>> > Why hide it in that location?
>> >
>> >
>> >         Stefan "who hasn't looked at the presumably preceding discussion
>> >                 in emacs-devel"
>> 
>> This discussion started on emacs-devel but was moved here to
>> bug-gnu-emacs for further review and tracking.  If you think this
>> information should also go elsewhere, I'm happy to do that.  However, I
>> don't believe admin/notes/elpa is a hidden location for Emacs
>> developers.
>
> Why do you think admin/notes/elpa is not a hidden location for Emacs
> developers?  Who do you think the admin/notes/ directory is for?
>
Eli, are you suggesting this section should be added to a more visible
location than admin/notes/elpa?  If so, I'm happy to propose adding it
elsewhere.  I chose admin/notes/elpa because it was one of the places I
looked for this information and noticed it was missing.  I also checked
the elpa README and found it lacking there as well.  Of course, it's up
to the Emacs maintainers to decide the best location for this section.

>> Related questions that may arise:
>
> Who may raise this questions, and in what contexts?
>
The proposed section helps Emacs and GNU ELPA developers ensure their
code is up-to-date and compliant with Emacs policies.  It addresses
questions arising during contributions, updates, or policy reviews.

>> - Are these cases considered policy violations for packages in GNU ELPA?
>
> Which cases, and why do you think they might be policy violations?
>
The cases I'm referring to are when a built-in package or a GNU ELPA
package continues development outside GNU ELPA without adhering to its
policies.

>> The proposed section in the Emacs developer notes aims to address these
>> questions in a general sense
>
> How can a question be addressed "in a general sense"?  Shouldn't every
> question be addressed specifically and in a targeted manner, answering
> exactly the question and nothing else?
>
The focus is on helping developers navigate GNU ELPA package maintenance
in external repositories.  Specific details can be added if needed.

>> When GNU ELPA policies are violated—or could be violated,
>> such as by accepting a pull request or incorporating code that is not
>> under FSF copyright—Emacs maintainers and developers will have the
>> clarity and guidelines needed to take appropriate action and defend GNU
>> Emacs' interests.
>
> If code that violates the policies is accepted, how can the Emacs
> maintainers do anything post-factum to defend GNU interests?  Code
> that is accepted into the Git repository is carved in stone, and
> cannot be removed from Git, ever.

That's precisely the point.  Maintainers of GNU ELPA packages hosted
externally need clear guidelines for proper maintenance.  The GNU ELPA
team must review updates before merging them to ensure compliance with
Emacs policies.  This includes verifying that contributors with
significant changes (e.g., over 15 lines of code) complete the FSF
copyright assignment process, notifying maintainers of policy
violations, etc.  While I'm unfamiliar with the current process, I
propose adding a section to guide external maintainers on GNU ELPA best
practices.

Message #56 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 09:53:43 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> david [2025-03-22 21:20:38] wrote:
>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>> BTW, which Emacs mode are you editing this in to automatically insert
>>> 0x2019?
>> I manually used the ’ character in the text.
>
> How?
>
Hi Stefan, to manually insert that character, you can run `C-x 8 RET
2019 RET`.  Alternatively, you could copy the character from the scratch
buffer header and use it wherever needed.  You could also create an
abbrev or a keyboard macro to insert it.  Emacs offers many ways to
manually insert a symbol.

What do you think about the patch update?  I'm open to any suggestions
from you.  Thanks.

Message #59 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 10:07:10 -0400

david [2025-03-23 09:53:43] wrote:
> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>> david [2025-03-22 21:20:38] wrote:
>>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>>> BTW, which Emacs mode are you editing this in to automatically insert
>>>> 0x2019?
>>> I manually used the ’ character in the text.
>>
>> How?
>>
> Hi Stefan, to manually insert that character, you can run `C-x 8 RET
> 2019 RET`.  Alternatively, you could copy the character from the scratch
> buffer header and use it wherever needed.  You could also create an
> abbrev or a keyboard macro to insert it.  Emacs offers many ways to
> manually insert a symbol.

[ That doesn't answer my question.  ]


        Stefan

Message #62 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 10:43:27 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

> david [2025-03-23 09:53:43] wrote:
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>> david [2025-03-22 21:20:38] wrote:
>>>> Stefan Kangas <stefankangas <at> gmail.com> writes:
>>>>> BTW, which Emacs mode are you editing this in to automatically insert
>>>>> 0x2019?
>>>> I manually used the ’ character in the text.
>>>
>>> How?
>>>
>> Hi Stefan, to manually insert that character, you can run `C-x 8 RET
>> 2019 RET`.  Alternatively, you could copy the character from the scratch
>> buffer header and use it wherever needed.  You could also create an
>> abbrev or a keyboard macro to insert it.  Emacs offers many ways to
>> manually insert a symbol.
>
> [ That doesn't answer my question.  ]
>
>
>         Stefan

Your question seems unrelated to the patch, but I provided an answer
anyway to be helpful.

Message #65 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: david <davidimagid <at> gmail.com>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 11:11:01 -0400

> What do you think about the patch update?  I'm open to any suggestions
> from you.  Thanks.

FWIW, I don't see any need to add anything of that kind to `admin/notes/elpa`.


        Stefan

Message #68 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Philip Kaludercic <philipk <at> posteo.net>, 76925 <at> debbugs.gnu.org,
 Eli Zaretskii <eliz <at> gnu.org>, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sun, 23 Mar 2025 12:17:45 -0400

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> What do you think about the patch update?  I'm open to any suggestions
>> from you.  Thanks.
>
> FWIW, I don't see any need to add anything of that kind to `admin/notes/elpa`.
>
>
>         Stefan

Thanks, Stefan.  Could you share what you propose instead?  This thread
stems from an issue about missing information that we could address.
Several developers have discussed the patch, and I believe that when
joining a thread to express disagreement, it's helpful to offer an
alternative or explanation—especially when others see value in the
change.  If the patch had been dismissed from the start as unnecessary
or irrelevant, there would be no issue.  But when multiple developers
are actively discussing it, simply stating it's unnecessary without
elaboration can come across as lacking tact.  I say this because I feel
a sense of responsibility for a thread I started.

Looking forward to your thoughts.

Message #71 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: david <davidimagid <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Thu, 27 Mar 2025 18:17:31 +0000

david <davidimagid <at> gmail.com> writes:

> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>
>>> What do you think about the patch update?  I'm open to any suggestions
>>> from you.  Thanks.
>>
>> FWIW, I don't see any need to add anything of that kind to `admin/notes/elpa`.
>>
>>
>>         Stefan
>
> Thanks, Stefan.  Could you share what you propose instead?  This thread
> stems from an issue about missing information that we could address.
> Several developers have discussed the patch, and I believe that when
> joining a thread to express disagreement, it's helpful to offer an
> alternative or explanation—especially when others see value in the
> change.  If the patch had been dismissed from the start as unnecessary
> or irrelevant, there would be no issue.  But when multiple developers
> are actively discussing it, simply stating it's unnecessary without
> elaboration can come across as lacking tact.  I say this because I feel
> a sense of responsibility for a thread I started.
>
> Looking forward to your thoughts.

If I may propose a idea I have been playing around with for a while in
my head:  I think it would be nice to have a wizard-like interface that
prepares a submission request.  It should both be able to set up a
project if the user is just starting out and provide some basic checks
for a user who has some ready code they wish to add to ELPA.  In the
process, the package should go through and explain the most common
questions ("how to release a package?", "when is it updated?", "what is
the difference between GNU and NonGNU ELPA?", etc.).

If you are interested in contributing to ELPA, I think that working on
this kind of a user-facing package would be more useful than commenting
on a admin/notes file that most people don't even know about.  I would
be more than glad to shepherd you through the process 1:1, as I have had
a good experience with the approach in the past.  How does that sound
like?

(Package name suggestion: "elpa-helper".)

Message #74 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Thu, 27 Mar 2025 15:38:03 -0400

Philip Kaludercic <philipk <at> posteo.net> writes:

> david <davidimagid <at> gmail.com> writes:
>
>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>
>>>> What do you think about the patch update?  I'm open to any suggestions
>>>> from you.  Thanks.
>>>
>>> FWIW, I don't see any need to add anything of that kind to `admin/notes/elpa`.
>>>
>>>
>>>         Stefan
>>
>> Thanks, Stefan.  Could you share what you propose instead?  This thread
>> stems from an issue about missing information that we could address.
>> Several developers have discussed the patch, and I believe that when
>> joining a thread to express disagreement, it's helpful to offer an
>> alternative or explanation—especially when others see value in the
>> change.  If the patch had been dismissed from the start as unnecessary
>> or irrelevant, there would be no issue.  But when multiple developers
>> are actively discussing it, simply stating it's unnecessary without
>> elaboration can come across as lacking tact.  I say this because I feel
>> a sense of responsibility for a thread I started.
>>
>> Looking forward to your thoughts.
>
> If I may propose a idea I have been playing around with for a while in
> my head:  I think it would be nice to have a wizard-like interface that
> prepares a submission request.  It should both be able to set up a
> project if the user is just starting out and provide some basic checks
> for a user who has some ready code they wish to add to ELPA.  In the
> process, the package should go through and explain the most common
> questions ("how to release a package?", "when is it updated?", "what is
> the difference between GNU and NonGNU ELPA?", etc.).
>
> If you are interested in contributing to ELPA, I think that working on
> this kind of a user-facing package would be more useful than commenting
> on a admin/notes file that most people don't even know about.  I would
> be more than glad to shepherd you through the process 1:1, as I have had
> a good experience with the approach in the past.  How does that sound
> like?
>
> (Package name suggestion: "elpa-helper".)

Thank you, Philip. This is an interesting and valuable initiative. While
I lack experience with wizard interfaces, I'd be happy to contribute
where most useful. What first steps would you suggest?

Message #77 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: david <davidimagid <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Fri, 28 Mar 2025 11:20:57 +0000

david <davidimagid <at> gmail.com> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>> david <davidimagid <at> gmail.com> writes:
>>
>>> Stefan Monnier <monnier <at> iro.umontreal.ca> writes:
>>>
>>>>> What do you think about the patch update?  I'm open to any suggestions
>>>>> from you.  Thanks.
>>>>
>>>> FWIW, I don't see any need to add anything of that kind to `admin/notes/elpa`.
>>>>
>>>>
>>>>         Stefan
>>>
>>> Thanks, Stefan.  Could you share what you propose instead?  This thread
>>> stems from an issue about missing information that we could address.
>>> Several developers have discussed the patch, and I believe that when
>>> joining a thread to express disagreement, it's helpful to offer an
>>> alternative or explanation—especially when others see value in the
>>> change.  If the patch had been dismissed from the start as unnecessary
>>> or irrelevant, there would be no issue.  But when multiple developers
>>> are actively discussing it, simply stating it's unnecessary without
>>> elaboration can come across as lacking tact.  I say this because I feel
>>> a sense of responsibility for a thread I started.
>>>
>>> Looking forward to your thoughts.
>>
>> If I may propose a idea I have been playing around with for a while in
>> my head:  I think it would be nice to have a wizard-like interface that
>> prepares a submission request.  It should both be able to set up a
>> project if the user is just starting out and provide some basic checks
>> for a user who has some ready code they wish to add to ELPA.  In the
>> process, the package should go through and explain the most common
>> questions ("how to release a package?", "when is it updated?", "what is
>> the difference between GNU and NonGNU ELPA?", etc.).
>>
>> If you are interested in contributing to ELPA, I think that working on
>> this kind of a user-facing package would be more useful than commenting
>> on a admin/notes file that most people don't even know about.  I would
>> be more than glad to shepherd you through the process 1:1, as I have had
>> a good experience with the approach in the past.  How does that sound
>> like?
>>
>> (Package name suggestion: "elpa-helper".)
>
> Thank you, Philip. This is an interesting and valuable initiative. 

If you are interested in it, we can close this bug report and continue
the discussion in private.  Are you OK with that?

>                                                                    While
> I lack experience with wizard interfaces, I'd be happy to contribute
> where most useful. What first steps would you suggest?

I have a sketch I can share with you, but this is really an open-ended
idea.

Message #80 received at 76925 <at> debbugs.gnu.org (full text, mbox):

From: david <davidimagid <at> gmail.com>
To: Philip Kaludercic <philipk <at> posteo.net>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925 <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sat, 29 Mar 2025 11:23:26 -0400

Philip Kaludercic <philipk <at> posteo.net> writes:

>>> If I may propose a idea I have been playing around with for a while in
>>> my head:  I think it would be nice to have a wizard-like interface that
>>> prepares a submission request.  It should both be able to set up a
>>> project if the user is just starting out and provide some basic checks
>>> for a user who has some ready code they wish to add to ELPA.  In the
>>> process, the package should go through and explain the most common
>>> questions ("how to release a package?", "when is it updated?", "what is
>>> the difference between GNU and NonGNU ELPA?", etc.).
>>>
>>> If you are interested in contributing to ELPA, I think that working on
>>> this kind of a user-facing package would be more useful than commenting
>>> on a admin/notes file that most people don't even know about.  I would
>>> be more than glad to shepherd you through the process 1:1, as I have had
>>> a good experience with the approach in the past.  How does that sound
>>> like?
>>>
>>> (Package name suggestion: "elpa-helper".)
>>
>> Thank you, Philip. This is an interesting and valuable initiative. 
>
> If you are interested in it, we can close this bug report and continue
> the discussion in private.  Are you OK with that?
>
Yes.

>> While I lack experience with wizard interfaces, I'd be happy to
>> contribute where most useful. What first steps would you suggest?
>
> I have a sketch I can share with you, but this is really an open-ended
> idea.

Message #85 received at 76925-done <at> debbugs.gnu.org (full text, mbox):

From: Philip Kaludercic <philipk <at> posteo.net>
To: david <davidimagid <at> gmail.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 76925-done <at> debbugs.gnu.org,
 Stefan Monnier <monnier <at> iro.umontreal.ca>,
 Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing
 to external packages
Date: Sat, 29 Mar 2025 17:41:59 +0000

david <davidimagid <at> gmail.com> writes:

> Philip Kaludercic <philipk <at> posteo.net> writes:
>
>>>> If I may propose a idea I have been playing around with for a while in
>>>> my head:  I think it would be nice to have a wizard-like interface that
>>>> prepares a submission request.  It should both be able to set up a
>>>> project if the user is just starting out and provide some basic checks
>>>> for a user who has some ready code they wish to add to ELPA.  In the
>>>> process, the package should go through and explain the most common
>>>> questions ("how to release a package?", "when is it updated?", "what is
>>>> the difference between GNU and NonGNU ELPA?", etc.).
>>>>
>>>> If you are interested in contributing to ELPA, I think that working on
>>>> this kind of a user-facing package would be more useful than commenting
>>>> on a admin/notes file that most people don't even know about.  I would
>>>> be more than glad to shepherd you through the process 1:1, as I have had
>>>> a good experience with the approach in the past.  How does that sound
>>>> like?
>>>>
>>>> (Package name suggestion: "elpa-helper".)
>>>
>>> Thank you, Philip. This is an interesting and valuable initiative. 
>>
>> If you are interested in it, we can close this bug report and continue
>> the discussion in private.  Are you OK with that?
>>
> Yes.

OK, I'm closing the bug report with this message then.

>>> While I lack experience with wizard interfaces, I'd be happy to
>>> contribute where most useful. What first steps would you suggest?
>>
>> I have a sketch I can share with you, but this is really an open-ended
>> idea.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.