Contribute | Org mode


Org mode is built on the efforts of enthusiastic volunteers. The two best ways to contribute to Org are with time or money. Donations support Org's primary maintainer Bastien Guerry.

You can also support Org with your time, no matter your level of experience.

The fastest way to get involved is by subscribing to the mailing list. You can also always get in touch via to help move the project forward.

Very little experience
Give feedback about your experience with org.
A dash of experience
Help improve the documentation.
Some experience
Help test patches, track down bugs.
Moderate experience
Submit bug-fixes, improve features.

Whatever your contribution, it is appreciated 😀.

Submitting patches

Suggested workflow

~$ git pull
~$ git checkout -b my-changes
# make some changes
~$ git commit -a -m "Definitely following the commit conventions"
# repeat a few times, as appropriate
~$ git format-patch master
# optional, see:
~$ git send-email --to="" HEAD^

Coding conventions

Org is part of Emacs, so any contribution should follow the GNU Emacs Lisp coding conventions described in Emacs manual.

Commit messages

Commit messages also need to be structured according to Emacs conventions.

main file/feature: Overall change summary

* file-changed.el (function-changed, another-function): Description of
the change implemented, reference any relevant `other-functions' or
`variables' here.
(another-changed-function): Change something.  Use active voice,
and avoid passive forms.  Please write in full sentences.

More formally,

  1. The first line should include the file/feature affected, followed by a colon and an short description of the overall change (this description starts with an uppercase letter and does not end with a dot.)
  2. The second line should be left blank
  3. Start on the third line there should be a ChangeLog entry for each file changed, as seen in the example above
    • Quote variables and function names like `this'
    • Separate sentences with two spaces
    • Use active voice instead of passive voice
    • Try to be terse
  4. The line after the final ChangeLog entry should be left blank
  5. Optionally this may be followed by any supplementary information explaining the patch
  6. If the patch is from a contributor without FSF assignment, it can be accepted as long as it contains no more than 15 lines. In this case add the TINYCHANGE cookie (anywhere in the message)

Sending patches

You can use git format-patch or git diff to generate the patch files and then include them in an email to describing what you've done. If you have configured git to use send-email, then you can use that. If you are sending the patch manually, please add the phrase [PATCH] to the beginning of the Subject: line of your e-mail, your submission will then be tracked on

If your mail has not appeared on the list after waiting at least 15 minutes, it may have been flagged as spam by the robot email overlords. If this happens, you should be able to get the email to go through by subscribing to the mailing list.

Site created by TEC with Org mode unicorn logo

licensed under the GNU FDL 1.3