Subject: Re: bug#76925: [PATCH] admin/notes/elpa: Add note on contributing to external packages

From: david <[email-masked]>
Date: Fri, 21 Mar 2025 10:12:44 -0400

david <[email-masked]> 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 <[email-masked]>
> 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
> +     [email-masked].
> +   - 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!