Stefan Kangas 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@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.