Contributing to Org

• Send bug reports. Before sending a bug report, make sure you read the section of the manual on how to provide useful feedback or this other great text: How to Send Bug Reports Effectively.
• Try to reproduce bugs: That's always very helpful. Do subscribe to Org's mailing list and monitor new unreferenced bugs. Try to reproduce them. If you can reproduce a bug, reply to the original poster and add Confirmed. in a separate line of your email text, and the bug will then be shown on tracker.orgmode.org.
• Help other users by replying to their questions on the mailing list or on other web places.
• Contribute to Worg. Worg is collaborative documentation made of Org files. It's very easy to contribute to it. Learn more about Worg and how to contribute.
• 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 the mailing list to find similar proposals. If you cannot find any, subscribe to the list, read it for a while, then make your proposal. Formulate it with as much detail as possible, especially with examples.

• Check the requests for help: If you want to help with one of these tasks, say so on the list.

• Check the list of confirmed bugs: Even if you just provide more information or ideas on how to fix them, this helps.

  Our Woof! instance (bug tracker) currently itself has a bug where some of the resolved bug reports remain listed. So, please check the actual bug discussion and/or subscribe to the RSS feed and reply to the new bug reports expressing your interest to fix them.

• Submit patches to the mailing list. See how to format your first patch and details on how to submit it.
  • If you have problems with patch workflow, you may also share a link to your public git repository containing changes or submit the changed files directly
• Write add-ons. The best way is to submit your code to the mailing list and discuss it with people. Many add-ons are published through GNU ELPA (for authors who signed the FSF copyright assignment) and NonGNU ELPA (for others). You'll need to sign the FSF copyright assignment FSF if you want to add your code in Org's core, because it will end up in GNU Emacs.
  • Step-by-step guide how to write and publish an add-on from scratch

• Maintain an Org file: If a file in the git repository does not have a maintainer ¹ and you want to help by maintaining it, please read more on how Org is maintained and let us know by sending an email to the mailing list.

  Maintaining a library usually requires ≈1 hour per week commitment. ≈1 hour per month for smaller libraries.

  List of Org libraries in a search for maintainers:

  ob-comint.el, ob-core.el, ob-css.el, ob-ditaa.el, ob-emacs-lisp.el, ob-eval.el, ob-exp.el, ob-forth.el, ob-fortran.el, ob-js.el, ob-latex.el, ob-lilypond.el, ob-lisp.el, ob-lob.el, ob-lua.el, ob-makefile.el, ob-matlab.el, ob-maxima.el, ob-ocaml.el, ob-octave.el, ob-org.el, ob-plantuml.el, ob-ref.el, ob-ruby.el, ob-sass.el, ob-scheme.el, ob-sed.el, ob-table.el, ob-tangle.el, ob.el, oc-basic.el, oc-biblatex.el, oc-bibtex.el, oc-natbib.el, oc.el, ol-bbdb.el, ol-bibtex.el, ol-docview.el, ol-doi.el, ol-eshell.el, ol-eww.el, ol-gnus.el, ol-info.el, ol-irc.el, ol-mhe.el, ol-rmail.el, ol-w3m.el, ol.el, org-agenda.el, org-archive.el, org-attach-git.el, org-attach.el, org-capture.el, org-clock.el, org-colview.el, org-compat.el, org-crypt.el, org-ctags.el, org-datetree.el, org-duration.el, org-feed.el, org-footnote.el, org-goto.el, org-habit.el, org-id.el, org-indent.el, org-inlinetask.el, org-lint.el, org-list.el, org-mobile.el, org-num.el, org-pcomplete.el, org-refile.el, org-src.el, org-table.el, org-tempo.el, org-timer.el, ox-ascii.el, ox-beamer.el, ox-man.el, ox-md.el, ox-odt.el, ox-org.el, ox-publish.el, ox-texinfo.el

  In the absence of dedicated maintainers taking care about these libraries, the official Org mode project maintainer has to be in charge. But there is only that much a single person can do.

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

On top of these conventions :

• When creating an option (as defcustom) or changing the default value of an existing one, use the next stable version of Org as the value of package-version. E.g. if the main branch version is 9.6-pre, use 9.6 for package-version.
• Do not create commits that only perform space replacements ⁴.

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

When sending a patch (using git diff, git format-patch or git send-email, always add a properly formatted Emacs ChangeLog entry in the commit message. See this section for details on how to create such a ChangeLog.

For every patch you send, we suggest to use git format-patch or git send-email. Here is a suggested workflow:

~$ git pull                 # make sure your repo is up to date
~$ git branch my-changes    # create a new branch from main
~$ 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 main                 # Creates two patches (.patch files)

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 (easier) 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 (again, see this section on how to format a ChangeLog entry.)

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 what 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/main):

git diff -p origin/main 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.

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.

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

  lisp/ol-man.el: Restore file
  

• Line 2 is an empty line.

• Line 3 starts the ChangeLog entry. It looks like 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.
  

  There should be an entry for every file changed in the commit. This includes, for instance, etc/ORG-NEWS and doc/org-manual.org if your change was relevant there. This is a good example of a TINYCHANGE that also touched the manual and news files.

  Please refer to GNU standards for more detailed information about the purpose and contents of the ChangeLog entries.

• After the ChangeLog entry, 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 after the ChangeLog entry.

• If the commit fixes a bug reported by someone on the list, you can add this contextual information like this:

  Reported-by: "Bruce E. Robertson" <brucer42@gmail.com>
  Link: https://list.orgmode.org/877dch89s1.fsf@kyleam.com/
  

  Only add links to the mailing list archive at https://list.orgmode.org.

  If a bug has been reported elsewhere on the web, don't reference such URLs: send an email to the list with a bug report and add a reference to your email in the commit message.

• When you look at the git log, you will see only the first line of the commit message. So, git log should be written in such a way that a person just skimming through the first lines could get an idea about what kind of changes have been done. For example, take a look at https://git.savannah.gnu.org/cgit/emacs/org-mode.git/log/ You should be able to tell, without looking into actual changes, what happened to Org mode repository recently.

  If you split similar changes into multiple commits, they will not provide useful information - you will just introduce consequent (almost) identical lines into the log.

  For the same reason, putting very different changes into a single commit message is not useful. There is only that much you can fit into the first line. If you do not describe all the changes in the first line, they may be missed while reading the log.

  An analogy of the first line of a commit message is title of a video/article/blog post. It is the first thing the reader encounters, and it should indicate whether more detailed reading is needed.

• At the second level we have the rest of the commit message. This is a kind of abstract summarizing changes. One should be able to understand what kind of changes were done and why they were done, in plain English. That's why (and for historical reasons) it follows ChangeLog format were each changed function/section should be annotated.

  Any links in the commit message should be permanent, if at all possible. Commit messages are written once and will not be changed, so any supporting link should remain accessible for as long as possible. Otherwise, future readers may not be able to understand the context in full.

• Variables and functions names are quoted like `this' (a backquote and a 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.

TINYCHANGE

If you are using 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 the diff listing. This creates entries in the ChangeLog file and you can then cut and paste these to the commit message and remove the indentation.

Further reference:

• Standard Emacs change log entry format
• Contribution guide from Emacs repo