1 #+TITLE: How to contribute to Org?
3 #+EMAIL: mdl AT imapmail DOT org
4 #+OPTIONS: H:3 num:nil toc:t \n:nil ::t |:t ^:t -:t f:t *:t tex:t d:(HIDE) tags:not-in-toc
5 #+STARTUP: align fold nodlcheck hidestars oddeven lognotestate
6 #+SEQ_TODO: TODO(t) INPROGRESS(i) WAITING(w@) | DONE(d) CANCELED(c@)
7 #+TAGS: Write(w) Update(u) Fix(f) Check(c)
12 # This file is the default header for new Org files in Worg. Feel free
13 # to tailor it to your needs.
15 [[file:index.org][{Back to Worg's index}]]
17 * Types of contributions
19 :CUSTOM_ID: types-of-contributions
22 Every contribution to Org is very welcome. Here is a list of areas
23 where your contribution will be useful:
25 - you can submit *bug reports* -- Before sending a bug report, make sure
26 you have read this section of Org's manual: [[https://orgmode.org/org.html#Feedback][Feedback]] You can also
27 read this great text: "[[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html][How to Send Bug Reports Effectively]]"
29 - you can submit *patches* -- You can submit patches to the mailing
30 list. See the [[For Org contributors: preferred way of submitting patches][Preferred way of submitting patches]] section for
31 details. You can run =make test= to check that your patch does not
34 If your patch is against a file that is part of Emacs, then your
35 total contribution (all patches you submit) should change /less than
36 15 lines/ (See the [[http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE][CONTRIBUTE file in GNU Emacs]].) If you contribute
37 more, you have to assign the copyright of your contribution to the
38 Free Software Foundation (see below).
40 - You can submit material to the *Worg* website -- This website is made
41 of Org files that you can contribute to. Learn what Worg is [[file:worg-about.org][about]]
42 and how to contribute to it [[file:worg-git.org][through git]].
44 - You can submit *feature requests* -- Org is already mature, but new
45 ideas keep popping up. If you want to request a feature, it might
46 be a good idea to have a look at the current [[https://orgmode.org/worg/org-issues.html][Issue tracking file]]
47 which captures both bug reports and feature requests. Or dig into
48 the mailing list for possible previous discussions about your idea.
49 If you cannot find back your idea, formulate it as detailed as
50 possible, if possible with examples, and send it to the mailing
53 - You can submit Org *add-ons* -- there are many Org add-ons.
54 - The best way is to submit your code to [[file:org-mailing-list.org][the mailing list]] to discuss
56 - If it is useful, you might consider contributing it to the
57 =lisp/contrib/= directory in the git repository. It will be
58 reviewed, and if it passes, it will be included. Ask help from
59 [[file:org-people.org][Eric Schulte]] for this step. The =lisp/contrib/= directory is
60 somehow relaxed: it is not distributed with Emacs, and does not
61 require a formal copyright assignment.
62 - If you decide to sign the [[*Copyright issues when contributing to Emacs Org mode][assignment contract with the FSF]], we
63 might include your contribution in the distribution, and then in
66 * Copyright issues when contributing to Emacs Org mode
68 :CUSTOM_ID: copyright-issues
71 Org is made of many files. Most of them are also distributed as part
72 of GNU Emacs. These files are called the /Org core/, and they are all
73 copyrighted by the [[http://www.fsf.org][Free Software Foundation, Inc]]. If you consider
74 contributing to these files, your first need to grant the right to
75 include your works in GNU Emacs to the FSF. For this you need to
76 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
77 you the assignment contract that both you and the FSF will sign.
78 Please let the Org mode maintainer know when this process is complete.
79 Some people consider this assignment process a hassle. I don't want
80 to discuss this in detail here - there are some good reasons for
81 getting the copyright registered, an example is discussed in this
82 [[http://twit.tv/floss117][FLOSS weekly podcast]]. Furthermore, by playing according to the Emacs
83 rules, we gain the fantastic advantage that every version of Emacs
84 ships with Org mode already fully built in. So please consider doing
85 this - it makes our work as maintainers so much easier, because we can
86 then take your patches without any additional work.
88 If you want to learn more about /why/ copyright assignments are
89 collected, read this: [[http://www.gnu.org/licenses/why-assign.html][Why the FSF gets copyright assignments from
92 By submitting patches to emacs-orgmode@gnu.org, or by pushing changes
93 to the Org mode repository, you are placing these changes under the
94 same licensing terms as those under which GNU Emacs is published.
97 ;; GNU Emacs is free software: you can redistribute it and/or modify
98 ;; it under the terms of the GNU General Public License as published by
99 ;; the Free Software Foundation, either version 3 of the License, or
100 ;; (at your option) any later version.
103 If at the time you submit or push these changes you do have active
104 copyright assignment papers with the FSF, for future changes to either
105 Org mode or to Emacs, this means that copyright to these changes is
106 automatically transferred to the FSF. The Org mode repository is seen
107 as upstream repository for Emacs, anything contained in it can
108 potentially end up in Emacs. If you do not have signed papers with
109 the FSF, only changes to files in the =contrib/= part of the repository
110 will be accepted, as well as very minor changes (so-called /tiny
111 changes/) to core files. We will ask you to sign FSF papers at the
112 moment we attempt to move a =contrib/= file into the Org core, or into
122 Please read [[https://code.orgmode.org/bzg/org-mode/src/master/README_maintainer][README_maintainer]] file within Org's repository.
124 ** Pushing your first commit
126 1. Create an account on https://code.orgmode.org
127 2. Add your public key to the account
128 3. Ask [[mailto:bzgATgnuDOTorg][Bastien]] to be added as a collaborator on the repository
129 4. Clone =org-mode.git=: =~$ git clone git@code.orgmode.org:bzg/org-mode.git=
130 5. Commit your changes against the code and the documentation.
132 7. If the tests pass, push your changes.
134 If you are undertaking big changes, please create a dedicated branch
135 and make sure you have a clean commit history before merging it into
136 the maint or master branch.
138 ** Taking care of the manual in both branches
140 - When you make a change in the master branch, update
141 doc/org-manual.org accordingly.
143 - When you make a change in the maint branch, update doc/org.texi in
144 maint and doc/org-manual.org when you merge maint into master.
146 * For Org contributors: preferred way of submitting patches
151 ** Coding conventions
153 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
154 Lisp coding conventions]] described in Emacs manual.
156 ** Sending patch with git
158 Org mode is developed using /git/ as the version control system. Git
159 provides an amazing framework to collaborate on a project. Git can be
160 used to make patches and send them via email -- this is perfectly fine
161 for major and minor changes.
163 When sending a patch (either using =git diff= or =git format-patch=)
164 please *always add a properly formatted Emacs ChangeLog entry*. See
165 [[#commit-messages][this section]] for details on how to create such a ChangeLog.
169 For every patch you send, we suggest to use =git format-patch=.
171 This is easy for small patches and more consequent ones. Sometimes,
172 you might even want to work in several steps and send each commit
173 separately. Here is the suggested workflow:
176 : ~$ git pull # make sure your repo is up to date
177 : ~$ git branch my-changes # create a new branch from master
178 : ~$ git checkout my-changes # switch to this new branch
180 ... make some changes (1) ...
182 : ~$ git commit -a -m "This is change (1)" # Commit your change
184 ... make another change (2) ...
186 : ~$ git commit -a -m "This is change (2)" # Commit your change
187 : ~$ git format-patch master # Creates two patches
189 ... Then two patches for your two commits are ready to be sent to
193 Write useful commit messages: please provide 1) a reason for it in
194 your email and 2) a ChangeLog entry in the commit message (see [[#commit-messages][this section]] on how to format a ChangeLog entry.)
196 ** Sending quick fixes for testing purpose
198 If you want to send a quick fix that needs to be further tested by
199 other people (before you submit a real patch), here is how you can do:
202 This command will make a patch between the staging area (in your
203 computer), and the file you modified:
205 : git diff -p org-whatever.el > org-whatever.el.diff
207 If you already committed your changes to your index (staging area), then
208 you should compare against a particular branch (in this example,
211 : git diff -p origin/master org-whatever.el > org-whatever.el.diff
213 You email the output to the mailing list, adding =[PATCH]= to the
214 subject, and description of what you fixed or changed.
217 Note that small patches sent like this still need to have a ChangeLog
218 entry to be applied. If your patch looks good to you, it's always
219 better to send a patch through =git format-patch=.
221 ** Sharing changes from a public branch
223 For more significant contributions, the best way to submit patches is
224 through public branches of your repository clone.
226 1. Clone our git repository at =https://code.orgmode.org/bzg/org-mode=.
227 You can clone using any of the commands below.
229 : git clone git@code.orgmode.org:bzg/org-mode.git
230 : git clone https://code.orgmode.org/bzg/org-mode.git
232 The url using the git protocol is preferred. If you are behind a
233 firewall that blocks ~git://~, you can use the https url.
235 2. Create a repository that can be publicly accessed, for example on
236 /GitHub/ or on your own server.
238 3. Push your topic branches (and optionally the master branch) to your
241 Define a remote for your public repository you push topics to.
243 : git remote add REMOTE URL-GOES-HERE
245 Push branches to the remote
247 : git push REMOTE BRANCH1 [BRANCH2 BRANCH3 ...]
251 : git remote add github ssh://.../ # Done once to define the remote 'github'
252 : git push github my-topic
254 4. Do your work on topic-specific branches, using a branch name that
255 relates to what you are working on.
261 to pull commits from all defined remote repositories.
263 6. When you have something workable, publish the git path and branch
264 name on the mailing list, so that people can test it and review
267 7. After your topic has been merged to the project master branch you
268 can delete the topic on your local and remote repositories.
270 : git branch -d NEWTOPIC
271 : git push REMOTE :NEWTOPIC
273 The instructions above are generally useful to let people test new
274 features before sending the patch series to the mailing list, but the
275 patches remain the preferred way of receiving contributions.
277 * Commit messages and ChangeLog entries
279 :CUSTOM_ID: commit-messages
282 We have decided to no longer keep a ChangeLog file to record changes
283 to individual functions.
285 A commit message should be constructed in the following way:
287 - Line 1 of the commit message should always be a short description of
288 the overall change. Line 1 does /not/ get a dot at the end and does
289 not start with a star. Generally, it starts with the filename that
290 has been changed, followed by a colon.
292 - Line 2 is an empty line.
294 - In line 3, the ChangeLog entry should start. A ChangeLog entry
295 looks like [[https://orgmode.org/cgit.cgi/org-mode.git/commit/?id%3Dd49957ef021e256f19092c907d127390d39ec1ed][this]]:
297 : * org-timer.el (org-timer-cancel-timer, org-timer-stop): Enhance
299 : (org-timer-set-timer): Use the number of minutes in the Effort
300 : property as the default timer value. Three prefix arguments will
301 : ignore the Effort value property.
303 - After the changelog, another empty line should come before any
304 additional information that the committer wishes to provide in order
305 to explain the patch.
307 - If the change is a minor change made by a committer without
308 copyright assignment to the FSF, the commit message should also
309 contain the cookie =TINYCHANGE= (anywhere in the message). When we
310 later produce the ChangeLog file for Emacs, the change will be
311 marked appropriately.
313 - Variables and functions names are quoted like `this' (backquote and
316 - Sentences should be separated by two spaces.
318 - Sentences should start with an uppercase letter.
320 - Avoid the passive form: i.e., use "change" instead of "changed".
322 Here is an example for such a message:
325 org-capture.el: Fix the case of using a template file
327 ,* lisp/org-capture.el (org-capture-set-plist): Make sure txt is a
328 string before calling `string-match'.
329 (org-capture-templates): Fix customization type.
331 ,* doc/org.texi (Capture): Document using a file for a template.
333 The problem here was that a wrong keyword was given in the
334 customization type. This let to a string-match against a list value.
336 Modified from a patch proposal by Johan Friis.
341 If you are using /magit.el/ in Emacs, the ChangeLog for such entries
342 are easily produced by pressing =C= in the diff listing.
344 Another option to produce the entries is to use `C-x 4 a' in the
345 changed function or in the diff listing. This will create entries in
346 the ChangeLog file, and you can then cut and paste these to the commit
347 message and remove the indentation.
349 - Further reference: [[http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE][Contribution guide from Emacs repo]]
351 * Copyrighted contributors to Org mode
353 :CUSTOM_ID: copyrighted-contributors
356 Here is the list of people who have contributed actual code to the Org
357 mode core. Note that the manual contains a more extensive list with
358 acknowledgments, including contributed ideas! The lists below are
359 mostly for house keeping, to help the maintainers keep track of
362 ** Current contributors
364 :CUSTOM_ID: contributors_with_fsf_papers
367 Here is the list of people who signed the papers with the Free Software
368 Foundation and can now freely submit code to Org files that are included
373 3. Abdó Roig-Maranges
382 12. Andreas Burtzlaff
385 15. Andrzej Lichnerowicz
392 22. Barry Leonard Gidden
394 24. Benjamin Andresen
398 28. Brian James Gough
407 37. Christopher League
408 38. Christopher Miles Gray
409 39. Christopher Schmidt
410 40. Christopher Suckling
411 41. Clément Pit--Claudel
414 44. Daniel M.\nbsp{}Hackney
415 45. David Arroyo Menéndez
422 52. Emmanuel Charpentier
425 55. Eric S.\nbsp{}Fraga
431 61. Francesco Pizzolante
432 62. Frederick Giasson
434 64. George Kettleborough
437 67. Grégoire Jadi (aka Daimrod)
439 69. Henning Dietmar Weiss
456 86. Jeffrey Ryan Horn
457 87. Jens Lechtenboerg
463 93. Jonathan Leech-Pepin
465 95. José L.\nbsp{}Doménech
474 104. Kevin Brubeck Unhammer
476 106. Konstantin Antipin
479 109. Lawrence Mitchell
482 112. Leonard Avery Randall
486 116. Madan Ramakrishnan
489 119. Marcin Borkowski
491 121. Mark A.\nbsp{}Hershberger
500 130. Miguel A.\nbsp{}Figueroa-Villanueva
507 137. Nicolas Berthier
508 138. Nicolas Dudebout
513 143. Noorul Islam K M
516 146. Pedro Alexandre Marcelino Costa da Silva
521 151. Pierre Téchoueyres
524 154. Puneeth Chaganti
525 155. Rafael Laboissière
527 157. Rasmus Pank Roulund
532 162. Robert Michael Irelan
533 163. Rüdiger Sonderfeld
541 171. Sebastien Vauban
545 175. Siraphob Phipathananunth
550 180. Takaaki Ishikawa
552 182. T.F.\nbsp{}Torrey
556 186. Thomas Fitzsimmons
558 188. Thomas S.\nbsp{}Dye
562 192. Titus von der Malsburg
564 194. Tokuya Kameshima
573 203. Vladimir Panteleev
576 206. Yoshinari Nomura
577 207. Yuri D.\nbsp{}Lensky
579 209. Zhuo Qingliang (Killy Draw)
583 These people have been asked to sign the papers, and they are
584 currently considering it or a request is being processed by the FSF.
586 - Brian Carlson [2016-05-24 Tue]
588 - Mats Kindahl (as of 2013-04-06) for [[http://mid.gmane.org/513BAB7D.1000603@oracle.com][this patch]]
589 - Georg Lehner (as of 2013-06-27)
590 - Kodi Arfer (as of 2013-06-29)
594 These people have submitted tiny change patches that made it into Org
595 without FSF papers. When they submit more, we need to get papers
596 eventually. The limit is a cumulative change of 20 non-repetitive
597 change lines. Details are given in [[http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant ][this document]].
599 1. Aaron L.\nbsp{}Zeng
600 2. Abhishek Chandratre
602 4. Aliaksey Artamonau
606 8. Andrew Eggenberger
618 20. Christian Schwarzgruber
621 23. Daniel Peres Gomez
622 24. Derek Feichtinger
632 34. Francesco Montanari
637 39. Greg Tucker-Kellogg
639 41. Ivan Vilata i Balaguer
649 51. Joaquín Aguirrezabalaga
659 61. Konstantin Kliakhandler
661 63. Leslie Harlley Watter
688 90. Nathaniel Nicandro
690 92. Nicolò Balzarotti
698 100. Richard Lawrence
699 101. Richard Y.\nbsp{}Kim (Kim)
701 103. Robert P.\nbsp{}Goldman
705 107. Saulius Menkevičius
706 108. Sebastien Le Maguer
707 109. Sergey Gordienko
709 111. Stefano Rodighiero
710 112. Stefan-W.\nbsp{}Hahn
712 114. Sylvain Chouleur
717 119. Thomas Alexander Gerds
720 122. Tobias Schlemmer
722 124. Vicente Vera Parra
723 125. Viktor Rosenfeld
726 128. Xavier Martinez-Hidalgo
730 132. Zane D.\nbsp{}Purvis
733 (This list may be incomplete - please help completing it.)
737 These people cannot or prefer to not sign the FSF copyright papers,
738 and we can only accept patches that do not change the core files (the
739 ones that are also in Emacs).
741 Luckily, this list is still empty.
743 #+BEGIN: timestamp :string "Last update: " :format "%Y-%m-%d @ %H:%M"