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

Previous Next

Full log

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

Previous Next

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