.gitignore: Ignore *patch

[worg.git] / org-contribute.org

#+TITLE:      How to contribute to Org?
#+AUTHOR:     Worg people
#+EMAIL:      mdl AT imapmail DOT org
#+OPTIONS:    H:3 num:nil toc:t \n:nil ::t |:t ^:nil -:t f:t *:t tex:t d:(HIDE) tags:not-in-toc
#+STARTUP:    align fold nodlcheck hidestars oddeven lognotestate
#+SEQ_TODO:   TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
#+TAGS:       Write(w) Update(u) Fix(f) Check(c)
#+LANGUAGE:   en
#+PRIORITIES: A C B
#+CATEGORY:   worg
#+HTML_LINK_UP:    index.html
#+HTML_LINK_HOME:  https://orgmode.org/worg/

# This file is released by its authors and contributors under the GNU
# Free Documentation license v1.3 or later, code examples are released
# under the GNU General Public License v3 or later.

# This file is the default header for new Org files in Worg.  Feel free
# to tailor it to your needs.

* Various ways of contributing to Org
:PROPERTIES:
:CUSTOM_ID: types-of-contributions
:END:

Every contribution to Org is very welcome.

- You can [[file:donate.org][make a donation]].

- You can check the community's *requests for help* on
  [[https://updates.orgmode.org/#help][updates.orgmode.org]] and subscribe to [[https://updates.orgmode.org/feed/help][this RSS feed]] to track them.

- You can *fix bugs* referenced on [[https://updates.orgmode.org/#bugs][updates.orgmode.org]] and subscribe to
  [[https://updates.orgmode.org/feed/bugs][this RSS feed]].

- You can try to *reproduce bugs*: subscribe to [[https://lists.gnu.org/mailman/listinfo/emacs-orgmode][Org's mailing list]] and
  monitor new unreferenced bugs.  Try to reproduce them.  If you can
  reproduce a bug, reply to the OP and add =X-Woof-Bug: confirmed= to
  your mail headers, the bug will then pop up on [[https://updates.orgmode.org/][updates.orgmode.org]].

- You can *help other users by replying to their questions* [[file:org-mailing-list.org][on the
  mailing list]] or on [[file:org-web-social.org][other web places]].

- You can *send bug reports*.  Before sending a bug report, make sure
  you have read the [[https://orgmode.org/org.html#Feedback][Feedback]] section of Org's manual or this other
  great text: [[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html][How to Send Bug Reports Effectively]]

- You can *submit patches* to the mailing list.  See [[#first-patch][Your first patch]]
  and [[#patches][Details on how to submit patches]].

- You can *contribute to Worg*.  Learn what Worg is [[file:worg-about.org][about]] and how to
  contribute to it [[file:worg-git.org][through git]].

- You can *write add-ons*. The best way is to submit your code to [[file:org-mailing-list.org][the
  mailing list]] to discuss it with people.  If you decide to sign the [[*Copyright issues when
  contributing to Emacs Org mode][assignment contract with the FSF]],
  we might include your contribution in the distribution, and then in
  GNU Emacs.

- You can *share ideas and feature requests*.  Org is already mature,
  but new ideas keep popping up.  If you want to request a feature,
  first dig into [[file:org-mailing-list.org][the mailing list]] to find similar proposals.  If you
  cannot find any, subscribe to [[file:org-mailing-list.org][the mailing list]], read it for a while,
  then make your proposal.  Formulate it as detailed as possible, if
  possible with examples.

* As a contributor, what can I expect?
:PROPERTIES:
:CUSTOM_ID: what-can-I-expect
:END:

Contributions are discussed on the [[https://orgmode.org/worg/org-mailing-list.html][Org mailing list]].

- When you contribute with a bug report :: Expect someone to try
  reproducing the bug.  Please make it easier by providing a minimal
  reproducible recipe.  Check the manual on how to provide [[https://orgmode.org/manual/Feedback.html][feedback]].
  If no one replies, don't take it personally: it either means that
  nobody was able to reproduce the bug or that the bug is not that
  critical for someone else to confirm it.  

- When you contribute with a patch :: Your patch will be listed on
  [[https://updates.orgmode.org][updates.orgmode.org]].  If this is your first patch, don't expect the
  patch to be applied immediately.  You can expect someone to review
  it and to suggest changes, either on the technical or formal aspects
  of the patch.  If nobody seems to care enough to reply, don't take
  it personally: it means that maintainers are busy and/or that the
  patch does not seem critical enough.

- When you contribute with an idea or a feature request ::  The best
  way to convince maintainers that your idea is worth considering is
  by detailing your use-case and by proposing a patch for it.  Expect
  people to discuss the idea on the list, but please remember Org is
  very old now, used by many people with various needs.  If nobody
  replies, don't take it personally.

In general, if you want to raise awareness on an email you sent,
please wait at least for *one month* before bumping a thread.  See [[file:org-mailing-list.org::#i-didnt-receive-an-answer][What
to do if you don't receive an answer]].

The Org mailing list has *contributor stewards* who will try their best
to make sure your contributions get all the attention they deserve.

* Your first patch as an occasional contributor
:PROPERTIES:
:CUSTOM_ID: first-patch
:END:

You don't need write access to the repository to contribute with
patches, just send them to [[file:org-mailing-list.org][the mailing list]].  Here is a checklist to
go through before submitting a patch:
  
1. Make your patch against the latest maint or master branch
2. Run =~$ make test= to catch broken tests
3. Check compilation warning with =~$ make compile=
4. If relevant, include or update tests
5. If your patch is adding a feature, please update =etc/ORG-NEWS=
6. If relevant, don't forget to update =doc/org-manual.org=
7. Take extra care of the commit message (see [[#commit-messages][Commit messages and ChangeLog entries]])
8. If your change is small enough, include =TINYCHANGE= at the bottom
   of the commit message.

If your patch is against an Org file that is part of Emacs, then your
total contribution (all patches you submit) should change /less than 15
lines/ (See the [[http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE][CONTRIBUTE file in GNU Emacs]].)  

If you contribute more, you have to assign the [[#copyright][copyright]] of your
contribution to the Free Software Foundation.  See [[#devs][Your first commit
as an Org committer]].

* Your first commit as an Org committer
:PROPERTIES:
:CUSTOM_ID: devs
:END:

Org regular contributors and maintainers have write access to the Git
repository.

1. Fill in [[https://orgmode.org/request-assign-future.txt][this form]] and wait for the FSF feedback
2. Send [[mailto:bzgATgnuDOTorg][Bastien]] the username you want for https://code.orgmode.org
3. Add your public key to your account, once its creation is confirmed
4. Clone =org-mode.git=: =~$ git clone git@code.orgmode.org:bzg/org-mode.git=
5. Commit your changes against the code and the documentation
6. Run =make test=
7. If the tests pass, push your changes

If you are undertaking big changes, please create a dedicated branch
locally and make sure you have a clean commit history before merging
it into the maint or master branch.

To check our Git workflow, please read [[https://orgmode.org/worg/org-maintenance.html][Org maintenance]].

* Details on how to submit patches
:PROPERTIES:
:CUSTOM_ID: patches
:END:

** Coding conventions

Org is part of Emacs, so any contribution should follow the [[http://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html][GNU Emacs
Lisp coding conventions]] described in Emacs manual.

** Sending patch with Git

Please use Git to make patches and send them via email -- this is
perfectly fine for major and minor changes.

When sending a patch (either using =git diff= or =git format-patch=)
please *always add a properly formatted Emacs ChangeLog entry*.  See
[[#commit-messages][this section]] for details on how to create such a ChangeLog.

** Sending commits

For every patch you send, we suggest to use =git format-patch=.

This is easy for small patches and more consequent ones.  Sometimes,
you might even want to work in several steps and send each commit
separately.  Here is the suggested workflow:

#+begin_quote
:   ~$ git pull                 # make sure your repo is up to date
:   ~$ git branch my-changes    # create a new branch from master
:   ~$ git checkout my-changes  # switch to this new branch

  ... make some changes (1) ...

:   ~$ git commit -a -m "This is change (1)"  # Commit your change

  ... make another change (2) ...

:   ~$ git commit -a -m "This is change (2)"  # Commit your change
:   ~$ git format-patch master                # Creates two patches

  ... Then two patches for your two commits are ready to be sent to
  the list.
#+end_quote

To finally send the patches, you can either add them as attachments to
your email, or use [[https://git-scm.com/docs/git-send-email][git send-email]], if it's properly configured.

Write useful commit messages: please provide 1) a reason for it in
your email and 2) a ChangeLog entry in the commit message (see [[#commit-messages][this
section]] on how to format a ChangeLog entry.)

** Sending quick fixes for testing purpose

If you want to send a quick fix that needs to be further tested by
other people (before you submit a real patch), here is how you can do:

#+begin_quote
  This command will make a patch between the staging area (in your
  computer), and the file you modified:

  : git diff -p org-whatever.el > org-whatever.el.diff

  If you already committed your changes to your index (staging area), then
  you should compare against a particular branch (in this example,
  origin/master):

  : git diff -p origin/master org-whatever.el > org-whatever.el.diff

  You email the output to the mailing list, adding =[PATCH]= to the
  subject, and description of what you fixed or changed.
#+end_quote

Note that small patches sent like this still need to have a ChangeLog
entry to be applied.  If your patch looks good to you, it's always
better to send a patch through =git format-patch=.

** Sharing changes from a public branch

When discussing important changes, it is sometimes not so useful to
send long and/or numerous patches.

In this case, you can maintain your changes on a public branch of a
public clone of Org and send a link to the diff between your changes
and the latest Org commit that sits in your clone.

If the discussion settles and your change is accepted, you can now
send it as (a list of) patch(es) to the latest Org version.

* Commit messages and ChangeLog entries
:PROPERTIES:
:CUSTOM_ID: commit-messages
:END:

We have decided to no longer keep a ChangeLog file to record changes
to individual functions.

A commit message should be constructed in the following way:

- Line 1 of the commit message should always be a short description of
  the overall change.  Line 1 does /not/ get a dot at the end and does
  not start with a star.  Generally, it starts with the filename that
  has been changed, followed by a colon.

- Line 2 is an empty line.

- In line 3, the ChangeLog entry should start.  A ChangeLog entry
  looks like [[https://code.orgmode.org/bzg/org-mode/commit/d49957ef021e256f19092c907d127390d39ec1ed][this]]:

  : * org-timer.el (org-timer-cancel-timer, org-timer-stop): Enhance
  : message.
  : (org-timer-set-timer): Use the number of minutes in the Effort
  : property as the default timer value. Three prefix arguments will
  : ignore the Effort value property.

- After the changelog, another empty line should come before any
  additional information that the committer wishes to provide in order
  to explain the patch.

- If the change is a minor change made by a committer without
  copyright assignment to the FSF, the commit message should also
  contain the cookie =TINYCHANGE= (anywhere in the message).  When we
  later produce the ChangeLog file for Emacs, the change will be
  marked appropriately.

- Variables and functions names are quoted like `this' (backquote and
  single quote).

- Sentences should be separated by two spaces.

- Sentences should start with an uppercase letter.

- Avoid the passive form: i.e., use "change" instead of "changed".

Here is an example for such a message:

#+begin_example
  org-capture.el: Fix the case of using a template file

  ,* lisp/org-capture.el (org-capture-set-plist): Make sure txt is a
  string before calling `string-match'.
  (org-capture-templates): Fix customization type.

  ,* doc/org.texi (Capture): Document using a file for a template.

  The problem here was that a wrong keyword was given in the
  customization type.  This let to a string-match against a list value.

  Modified from a patch proposal by Johan Friis.

  TINYCHANGE
#+end_example

If you are using [[https://magit.vc/][magit]] in Emacs, the ChangeLog for such entries can be
produced by pressing =C= (for ~magit-commit-add-log~) on the diff chunks
of a staged file.  (If you prefer storing your ChangeLog entries in a
file, you can also use =C-x 4 a=
(~magit-add-change-log-entry-other-window~) from within magit display of
diff chunks.)

Another option to produce the entries is to use `C-x 4 a' in the
changed function or in the diff listing.  This will create entries in
the ChangeLog file, and you can then cut and paste these to the commit
message and remove the indentation.

Further reference:
- [[https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs][Standard Emacs change log entry format]]
- [[http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE][Contribution guide from Emacs repo]]

* Dealing with copyright when contributing to Org mode
:PROPERTIES:
:CUSTOM_ID: copyright
:END:

Org is made of many files.  Most of them are also distributed as part
of GNU Emacs.  These files are called the /Org core/, and they are all
copyrighted by the [[http://www.fsf.org][Free Software Foundation, Inc]].

If you consider contributing to these files, your first need to grant
the right to include your works in GNU Emacs to the FSF.  For this you
need to complete [[https://orgmode.org/request-assign-future.txt][this form]], and send it to [[mailto:assign@gnu.org][assign@gnu.org]].

The FSF will send you the assignment contract that both you and the
FSF will sign.  Please let the Org mode maintainer know when this
process is complete.

If you want to learn more about /why/ copyright assignments are
collected, read this: [[http://www.gnu.org/licenses/why-assign.html][Why the FSF gets copyright assignments from
contributors?]]

By submitting patches to =emacs-orgmode@gnu.org= or by pushing changes
to Org's core files, you are placing these changes under the same
licensing terms as those under which GNU Emacs is published.

#+begin_example
;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
#+end_example

If at the time you submit or push these changes you do have active
copyright assignment papers with the FSF, for future changes to either
Org mode or to Emacs, this means that copyright to these changes is
automatically transferred to the FSF.

The Org mode repository is seen as upstream repository for Emacs,
anything contained in it can potentially end up in Emacs.  If you do
not have signed papers with the FSF, only changes to files in the
=contrib/= part of the repository will be accepted, as well as very
minor changes (so-called /tiny changes/) to core files.  We will ask you
to sign FSF papers at the moment we attempt to move a =contrib/= file
into the Org core, or into Emacs.

* Copyrighted contributors to Org mode
:PROPERTIES:
:CUSTOM_ID: copyrighted-contributors
:END:

Here is the list of people who have contributed actual code to the Org
mode core.  Note that the manual contains a more extensive list with
acknowledgments, including contributed ideas!  The lists below are
mostly for house keeping, to help the maintainers keep track of
copyright issues.

** Current contributors
  :PROPERTIES:
  :CUSTOM_ID: contributors_with_fsf_papers
  :END:

Here is the list of people who signed the papers with the Free Software
Foundation and can now freely submit code to Org files that are included
within GNU Emacs:

- Aaron Ecay
- Aaron Jensen
- Abdó Roig-Maranges
- Achim Gratz
- Adam Elliott
- Adam Porter
- Adam Spiers
- Alan Schmitt
- Alex Branham
- Alexey Lebedeff
- Allen Li
- Andreas Burtzlaff
- Andreas Leha
- Andrew Hyatt
- Andrzej Lichnerowicz
- Andy Steward
- Anthony John Day
- Anthony Lander
- Arni Magnusson
- Arun Isaac
- Baoqiu Cui
- Barry Leonard Gidden
- Bastien Guerry
- Benjamin Andresen
- Bernd Grobauer
- Bernt Hansen
- Bjarte Johansen
- Brian James Gough
- Brice Waegenire
- Carlos Pita
- Carsten Dominik
- Charles Berry
- Charles Sebold
- Christian Egli
- Christian Garbs
- Christian Moe
- Christopher League
- Christopher Miles Gray
- Christopher Schmidt
- Christopher Suckling
- Clément Pit--Claudel
- Dan Davison
- Daniele Nicolodi
- Daniel M German
- Daniel M.\nbsp{}Hackney
- David Arroyo Menéndez
- David Maus
- David O'Toole
- Dieter Schoen
- Dima Kogan
- Dmitry Antipov
- Don March
- Emmanuel Charpentier
- Eric Abrahamsen
- Eric Schulte
- Eric S.\nbsp{}Fraga
- Erik Hetzner
- Erik Iverson
- Ethan Ligon
- Feng Shu
- Ferdinand Pieper
- Florian Lindner
- Francesco Pizzolante
- Frederick Giasson
- Gary Oberbrunner
- George Kettleborough
- Georg Lehner
- Giovanni Ridolfi
- Greg Minshall
- Grégoire Jadi (aka Daimrod)
- Gustav Wikström
- Henning Dietmar Weiss
- Henry Blevins
- Ian Barton
- Ian Dunn
- Ian Kelling
- Ian Martins
- Ihor Radchenko
- Ilya Shlyakhter
- Ingo Lohmar
- Ippei Furuhashi
- Jack Kamm
- Jake Romer
- James TD Smith
- Jan Böcker
- Jan Malakhovski
- Jarmo Hurri
- Jason Riedy
- Jay Kamat
- Jay Kerns
- Jeffrey Ryan Horn
- Jens Lechtenboerg
- Joe Corneli
- Joel Boehland
- John Kitchin
- John Wiegley
- Jonas Bernoulli
- Jonathan Leech-Pepin
- Jon Snader
- José L.\nbsp{}Doménech
- Juan Pechiar
- Julian Gehring
- Julien Barnier
- Julien Danjou
- Juri Linkov
- Justin Abrahms
- Justin Gordon
- Justus Piater
- Karl Fogel
- Kaushal Modi
- Ken Mankoff
- Kevin Brubeck Unhammer
- Kevin Foley
- Kévin Le Gouguec
- Konstantin Antipin
- Kyle Meyer
- Lambda Coder
- Lawrence Mitchell
- Lele Gaifax
- Lennart Borgman
- Leonard Avery Randall
- Leo Vivier
- Le Wang
- Luis Anaya
- Lukasz Stelmach
- Madan Ramakrishnan
- Magnus Henoch
- Manuel Giraud
- Marcin Borkowski
- Marco Wahl
- Mario Frasca
- Mark A.\nbsp{}Hershberger
- Martin Pohlack
- Martyn Jago
- Matt Huszagh
- Matt Lundin
- Maxim Nikulin
- Max Mikhanosha
- Michael Albinus
- Michael Brand
- Michael Gauland
- Michael Sperber
- Miguel A.\nbsp{}Figueroa-Villanueva
- Mikael Fornius
- Morgan Smith
- Moritz Ulrich
- Nathaniel Flath
- Nathan Neff
- Neil Jerram
- Nicholas Dokos
- Nicholas Savage
- Nicolas Berthier
- Nicolas Dudebout
- Nicolas Goaziou
- Nicolas Richard
- Niels Giessen
- Nikolai Weibull
- Noorul Islam K M
- No Wayman (Nicholas Vollmer)
- Oleh Krehel
- Palak Mathur
- Paul Sexton
- Pedro Alexandre Marcelino Costa da Silva
- Peter Jones
- Phil Hudson
- Philip Rooke
- Phil Jackson
- Pierre Téchoueyres
- Pieter Praet
- Piotr Zielinski
- Protesilaos Stavrou
- Puneeth Chaganti
- Rafael Laboissière
- Rainer M Krug
- Rasmus Pank Roulund
- Richard Kim
- Richard Klinda
- Richard Riley
- Rick Frankel
- Robert Michael Irelan
- Robin Campbell
- Roland Coeurjoly
- Rüdiger Sonderfeld
- Russell Adams
- Ryo Takaishi
- Sacha Chua
- Samuel Loury
- Sebastian Miele
- Sebastian Reuße
- Sebastian Rose
- Sébastien Miquel
- Sebastien Vauban
- Sergey Litvinov
- Seweryn Kokot
- Simon Michael
- Siraphob Phipathananunth
- stardiviner
- Stefan Kangas
- Stefan Monnier
- Stephen Eglen
- Steven Rémot
- Suvayu Ali
- Takaaki Ishikawa
- Tassilo Horn
- Terje Larsen
- T.F. Torrey
- Thibault Marin
- Thierry Banel
- Thomas Baumann
- Thomas Fitzsimmons
- Thomas Holst
- Thomas S.\nbsp{}Dye
- Thorsten Jolitz
- Tim Burt
- Tim Landscheidt
- Timothy E Chapman (TEC)
- Titus von der Malsburg
- Toby Cubitt
- Tokuya Kameshima
- Tomas Hlavaty
- Tom Breton
- Tom Gillespie
- Tony Day
- Toon Claes
- Trevor Murphy
- Ulf Stegemann
- Vitalie Spinu
- Vladimir Panteleev
- Yann Hodique
- Yasushi Shoji
- Yoshinari Nomura
- Yuri D.\nbsp{}Lensky
- Zhang Weize
- Zhuo Qingliang (Killy Draw)

** Processing

These people have been asked to sign the papers, and they are
currently considering it or a request is being processed by the FSF.

- Felipe Lema [2020-02-25 mar.]
- Brian Carlson [2016-05-24 Tue]
- Mats Kindahl (as of 2013-04-06) for [[http://mid.gmane.org/513BAB7D.1000603@oracle.com][this patch]]
- Bill Wishon [?]
- Lawrence Bottorff

** Tiny Changes

These people have submitted tiny change patches that made it into Org
without FSF papers.  When they submit more, we need to get papers
eventually.  The limit is a cumulative change of 20 non-repetitive
change lines.  Details are given in [[http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant ][this document]].

- Aaron L.\nbsp{}Zeng
- Aaron Madlon-Kay
- Abhishek Chandratre
- Adam Aviv
- akater
- Alan D. Salewski
- Alan Light
- Albert Krewinkel
- Alexandru-Sergiu Marton
- Aliaksey Artamonau
- Aman Yang
- Anders Johansson
- Andrew Burgess
- Andrew Eggenberger
- Andrii Kolomoiets
- Andy Lutomirski
- Anthony Cowley
- Anton Latukha
- Arne Babenhauserheide
- Arun Persaud
- Augustin Fabre
- Aurélien Aptel
- Austin Walker
- Axel Kielhorn
- Basile Pesin
- Benson Chu
- Brad Knotwell
- Brian Powell
- Cheong Yiu Fung
- Christian Hopps
- Christian Schwarzgruber
- Chunyang Xu
- Claudiu Tănăselia
- Craig Tanis
- Dan Drake
- Daniel Gröber
- Daniel Peres Gomez
- Derek Feichtinger
- Dieter Faulbaum
- Dima Gerasimov
- Dominik Schrempf
- Doro Rose
- Eduardo Bellani
- Eric Danan
- Eric Timmons
- Fatih Aydin
- Federico Beffa
- Feng Zhou
- Fernando Varesi
- Florian Beck
- Florian Dufour
- Francesco Montanari
- Galen Menzel
- Georgiy Tugai
- Gong Qijian
- Gregor Zattler
- Greg Tucker-Kellogg
- Hiroshi Saito
- Ivan Sokolov
- Ivan Vilata i Balaguer
- Jack Henahan
- Jacob Gerlach
- Jacob Matthews
- Jakob Lombacher
- Jamie Forth
- Jan Seeger
- Jason Dunsmore
- Jason Furtney
- Jean-Marie Gaillourdet
- Jeff Larson
- Joaquín Aguirrezabalaga
- Joe Hirn
- John Foerch
- John Herrlin
- John Lee
- Jonas Hörsch
- Jon Miller
- Joost Diepenmaat
- Jose Robins
- Karol Wójcik
- Kodi Arfer
- Konstantin Kliakhandler
- Kovacsics Robert
- Lein Matsumaru
- Leslie Harlley Watter
- Leslie Watter
- Lixin Chin
- Luke Amdor
- Mak Kolybabi
- Marc Ihm
- Mario Martelli
- Marshall Flax
- Martin Kampas
- Martin Šlouf
- Martin Vuk
- Matthew Gidden
- Matthew MacLean
- Matt Price
- Max Mouratov
- Michaël Cadilhac
- Michael O'Connor
- Michael Strey
- Michael Welle
- Michael Weylandt
- Mike Ivanov
- Mike McLean
- Miro Bezjak
- Moritz Kiefer
- Muchenxuan Tong
- Myles English
- Myq Larson
- Nathaniel Nicandro
- Nick Daly
- Nick Gunn
- Nicolò Balzarotti
- Pablo Barraza Cornejo
- Peter Feigl
- Peter Moresi
- Philip (Pip Cet)
- Piet van Oostrum
- Renato Ferreira
- Richard Hansen
- Richard Lawrence
- Richard Y.\nbsp{}Kim (Kim)
- Robert Hambrock
- Roberto Huelga
- Robert P.\nbsp{}Goldman
- Roger Welsh
- Ruben Maher
- Sameer Rahmani
- Sami Airaksinen
- Saulius Menkevičius
- Sebastien Le Maguer
- Sébastien Miquel
- Sergey Gordienko
- Seth Robertson
- Sigmund Tzeng
- Stacey Marshall
- Stanley Jaddoe
- Stefano Rodighiero
- Stefan-W.\nbsp{}Hahn
- Stig Brautaset
- Sylvain Chouleur
- Tadashi Hirata
- Tara Lorenz
- Teika Kazura
- Terje Larsen
- Thierry Pellé
- Thomas Alexander Gerds
- Thomas Plass
- Thomas Rikl
- Tim Visher
- Tobias Schlemmer
- Tom Hinton
- TRS-80
- Utkarsh Singh
- Vicente Vera Parra
- Viktor Rosenfeld
- Vladimir Lomov
- Wojciech Gac
- Xavier Martinez-Hidalgo
- Xi Shen
- Yann Esposito
- York Zhao
- Yue Zhu
- Zane D.\nbsp{}Purvis
- Иван Трусков

(This list may be incomplete - please help completing it.)

** No FSF assignment

These people cannot or prefer to not sign the FSF copyright papers,
and we can only accept patches that do not change the core files (the
ones that are also in Emacs).

Luckily, this list is still empty.

#+BEGIN: timestamp :string "Last update: " :format "%Y-%m-%d @ %H:%M"

#+END: