Support via Liberapay, GitHub or PayPal

How to contribute to Org?

Table of Contents

{Back to Worg's index}

Types of contributions

Every contribution to Org is very welcome. Here is a list of areas where your contribution will be useful:

bug reports
Before sending a bug report, make sure you have read this section of Org's manual: Feedback You can also read this great text: "How to Send Bug Reports Effectively"

You can submit patches to the mailing list. See the Preferred way of submitting patches section for details. You can run make test to check that your patch does not introduce new bugs.

If your patch is against a file that is part of Emacs, then your total contribution (all patches you submit) should change less than 15 lines (See the CONTRIBUTE file in GNU Emacs.) If you contribute more, you have to assign the copyright of your contribution to the Free Software Foundation (see below).

material to the Worg website
This website is made of Org files that you can contribute to. Learn what Worg is about and how to contribute to it through git.
feature requests
Org is already mature, but new ideas keep popping up. If you want to request a feature, first dig into the mailing list to find similar proposals. If you cannot find any, subscribe to the mailing list, read it for a while, then make your proposal. Formulate it as detailed as possible, if possible with examples.
Org add-ons
there are many Org add-ons.
  • The best way is to submit your code to the mailing list to discuss it with people.
  • If it is useful, you might consider contributing it to the lisp/contrib/ directory in the git repository. It will be reviewed, and if it passes, it will be included. The lisp/contrib/ directory is somehow relaxed: it is not distributed with Emacs, and does not require a formal copyright assignment.
  • If you decide to sign the assignment contract with the FSF, we might include your contribution in the distribution, and then in GNU Emacs.

For Org developers

Org developers are those who have write access to the repository.

Git branches

Please read Worg's page on Org maintainance.

Pushing your first commit

  1. Send Bastien the username you want for
  2. Add your public key to the account
  3. Clone org-mode.git: ~$ git clone
  4. Commit your changes against the code and the documentation.
  5. Run make test
  6. If the tests pass, push your changes.

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

For Org contributors: preferred way of submitting patches

Coding conventions

Org is part of Emacs, so any contribution should follow the 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 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:

~$ 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.

To finally send the patches, you can either add them as attachments to your email, or use 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 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:

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.

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

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 this:

    * org-timer.el (org-timer-cancel-timer, org-timer-stop): Enhance
    (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:

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.


If you are using magit.el in Emacs, the ChangeLog for such entries are easily produced by pressing C in the diff listing.

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.

Copyrighted contributors to Org mode

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

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
  • Daniel M German
  • Daniel M. 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. Fraga
  • Erik Hetzner
  • Erik Iverson
  • Ethan Ligon
  • Feng Shu
  • 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
  • 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. Doménech
  • Juan Pechiar
  • Julian Gehring
  • Julien Barnier
  • Julien Danjou
  • 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. Hershberger
  • Martin Pohlack
  • Martyn Jago
  • Matt Lundin
  • Max Mikhanosha
  • Michael Albinus
  • Michael Brand
  • Michael Gauland
  • Michael Sperber
  • Miguel A. Figueroa-Villanueva
  • Mikael Fornius
  • Moritz Ulrich
  • Nathaniel Flath
  • Nathan Neff
  • Neil Jerram
  • Nicholas Dokos
  • Nicolas Berthier
  • Nicolas Dudebout
  • Nicolas Goaziou
  • Nicolas Richard
  • Niels Giessen
  • Nikolai Weibull
  • Noorul Islam K M
  • No Wayman (Nicholas Vollmer)
  • Oleh Krehel
  • Paul Sexton
  • Pedro Alexandre Marcelino Costa da Silva
  • Peter Jones
  • Phil Hudson
  • Philip Rooke
  • Phil Jackson
  • Pierre Téchoueyres
  • Pieter Praet
  • Piotr Zielinski
  • Puneeth Chaganti
  • Rafael Laboissière
  • Rainer M Krug
  • Rasmus Pank Roulund
  • Richard Kim
  • Richard Klinda
  • Richard Riley
  • Rick Frankel
  • Robert Michael Irelan
  • Roland Coeurjoly
  • Rüdiger Sonderfeld
  • Russell Adams
  • Ryo Takaishi
  • Sacha Chua
  • Samuel Loury
  • Sebastian Miele
  • Sebastian Reuße
  • Sebastian Rose
  • Sebastien Vauban
  • Sergey Litvinov
  • Seweryn Kokot
  • Simon Michael
  • Siraphob Phipathananunth
  • stardiviner
  • Stefan Kangas
  • Stephen Eglen
  • Steven Rémot
  • Suvayu Ali
  • Takaaki Ishikawa
  • Tassilo Horn
  • T.F. Torrey
  • Thibault Marin
  • Thierry Banel
  • Thomas Baumann
  • Thomas Fitzsimmons
  • Thomas Holst
  • Thomas S. 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. Lensky
  • Zhang Weize
  • Zhuo Qingliang (Killy Draw)


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 Tue]
  • Terje Larsen [2020-02-17 Mon]
  • Brian Carlson [2016-05-24 Tue]
  • Mats Kindahl (as of 2013-04-06) for this patch
  • Bill Wishon [?]

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 this document.

  • Aaron L. Zeng
  • Abhishek Chandratre
  • Adam Aviv
  • akater
  • 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
  • Brad Knotwell
  • Brian Powell
  • Cheong Yiu Fung
  • Christian Hopps
  • Christian Schwarzgruber
  • Chunyang Xu
  • Claudiu Tănăselia
  • Craig Tanis
  • Dan Drake
  • Daniel Peres Gomez
  • Derek Feichtinger
  • Dima Gerasimov
  • Dominik Schrempf
  • Doro Rose
  • Eduardo Bellani
  • Eric Danan
  • Eric Timmons
  • Federico Beffa
  • Feng Zhou
  • Fernando Varesi
  • Florian Beck
  • Francesco Montanari
  • Galen Menzel
  • Georgiy Tugai
  • Gong Qijian
  • Gregor Zattler
  • Greg Tucker-Kellogg
  • Hiroshi Saito
  • Ivan Vilata i Balaguer
  • Jack Henahan
  • Jacob Gerlach
  • Jacob Matthews
  • Jakob Lombacher
  • Jamie Forth
  • Jan Seeger
  • Jason Dunsmore
  • Jason Furtney
  • Jeff Larson
  • Joaquín Aguirrezabalaga
  • Joe Hirn
  • John Foerch
  • John Lee
  • Jonas Hörsch
  • Jon Miller
  • Joost Diepenmaat
  • Jose Robins
  • Kodi Arfer
  • Konstantin Kliakhandler
  • Kovacsics Robert
  • Leslie Harlley Watter
  • Leslie Watter
  • Lixin Chin
  • Luke Amdor
  • Mak Kolybabi
  • Marc Ihm
  • Mario Martelli
  • Marshall Flax
  • Martin Šlouf
  • Martin Vuk
  • Matthew Gidden
  • Matthew MacLean
  • Matt Huszagh
  • 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 Gunn
  • Nicolò Balzarotti
  • Peter Feigl
  • Peter Moresi
  • Philip (Pip Cet)
  • Piet van Oostrum
  • Renato Ferreira
  • Richard Hansen
  • Richard Lawrence
  • Richard Y. Kim (Kim)
  • Robert Hambrock
  • Roberto Huelga
  • Robert P. Goldman
  • Roger Welsh
  • Ruben Maher
  • Sami Airaksinen
  • Saulius Menkevičius
  • Sebastien Le Maguer
  • Sergey Gordienko
  • Seth Robertson
  • Sigmund Tzeng
  • Stacey Marshall
  • Stanley Jaddoe
  • Stefano Rodighiero
  • Stefan-W. Hahn
  • Stig Brautaset
  • Sylvain Chouleur
  • Tadashi Hirata
  • Teika Kazura
  • Terje Larsen
  • Thierry Pellé
  • Thomas Alexander Gerds
  • Thomas Plass
  • Thomas Rikl
  • Tim Visher
  • Tobias Schlemmer
  • Tom Hinton
  • Vicente Vera Parra
  • Viktor Rosenfeld
  • Vladimir Lomov
  • Wojciech Gac
  • Xavier Martinez-Hidalgo
  • Xi Shen
  • Yann Esposito
  • York Zhao
  • Yue Zhu
  • Zane D. 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.

Documentation from the website (either in its HTML format or in its Org format) is licensed under the GNU Free Documentation License version 1.3 or later. The code examples and css stylesheets are licensed under the GNU General Public License v3 or later.