5.4 KB



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 joining the community and 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 😀.

Copyright assignment


Org mode has a substantial code base composed of many files, most of which are distributed as part of GNU Emacs.

These files make up the Org core and are copyrighted by the Free Software Foundation (FSF).

If you want to contribute more than 15 lines of code to Org mode you will need to assign the copyright for your contributions to the FSF so that they can be included in GNU Emacs. To start the copyright assignment process fill out this form and email it to

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

Commit messages

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

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
  2. 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.)
  3. The second line should be left blank
  4. Start on the third line there should be a ChangeLog entry for each
  5. file changed, as seen in the example above
  6. Quote variables and function names like `this'
  7. Separate sentences with two spaces
  8. Use active voice instead of passive voice
  9. Try to be terse
  10. The line after the final ChangeLog entry should be left blank
  11. Optionally this may be followed by any supplementary information
  12. explaining the patch
  13. If the patch is from a contributor without FSF assignment, it can
  14. 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

Use git diff or git format-patch 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 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.