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 ^:nil -: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}]]
19 :CUSTOM_ID: types-of-contributions
22 Every contribution to Org is very welcome.
24 - You can [[file:donate.org][make a donation]].
26 - You can check the community's *requests for help* on
27 [[https://updates.orgmode.org/][updates.orgmode.org]] and subscribe to [[https://updates.orgmode.org/feed/help][this RSS feed]] to track them.
29 - You can *fix bugs* referenced on [[https://updates.orgmode.org/][updates.orgmode.org]] and subscribe to
30 [[https://updates.orgmode.org/feed/bugs][this RSS feed]].
32 - You can try to *reproduce bugs*: subscribe to [[https://lists.gnu.org/mailman/listinfo/emacs-orgmode][Org's mailing list]] and
33 monitor new unreferenced bugs. Try to reproduce them. If you can
34 reproduce a bug, reply to the OP and add =X-Woof-Bug: confirmed= to
35 your mail headers, the bug will then pop up on [[https://updates.orgmode.org/][updates.orgmode.org]].
37 - You can *help other users by replying to their questions* [[file:org-mailing-list.org][on the
38 mailing list]] or on [[file:org-web-social.org][other web places]].
40 - You can *send bug reports*. Before sending a bug report, make sure
41 you have read the [[https://orgmode.org/org.html#Feedback][Feedback]] section of Org's manual or this other
42 great text: [[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html][How to Send Bug Reports Effectively]]
44 - You can *submit patches* to the mailing list. See the [[For Org
45 contributors: preferred way of submitting patches][Preferred way of submitting patches]] section for details. You can run
46 =make test= to check that your patch does not introduce new bugs.
48 If your patch is against an Org file that is part of Emacs, then
49 your total contribution (all patches you submit) should change /less
50 than 15 lines/ (See the [[http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE][CONTRIBUTE file in GNU Emacs]].) If you
51 contribute more, you have to assign the copyright of your
52 contribution to the Free Software Foundation (see below).
54 - You can *contribute to Worg*. Learn what Worg is [[file:worg-about.org][about]] and how to
55 contribute to it [[file:worg-git.org][through git]].
57 - You can *write add-ons*. The best way is to submit your code to [[file:org-mailing-list.org][the
58 mailing list]] to discuss it with people. If you decide to sign the [[*Copyright issues when contributing to Emacs Org
59 mode][assignment contract with the FSF]], we might include your contribution
60 in the distribution, and then in GNU Emacs.
62 - You can *share ideas and feature requests*. Org is already mature,
63 but new ideas keep popping up. If you want to request a feature,
64 first dig into [[file:org-mailing-list.org][the mailing list]] to find similar proposals. If you
65 cannot find any, subscribe to [[file:org-mailing-list.org][the mailing list]], read it for a while,
66 then make your proposal. Formulate it as detailed as possible, if
67 possible with examples.
74 Org developers are those who have write access to the repository.
78 Please read Worg's page on [[https://orgmode.org/worg/org-maintainance.html][Org maintainance]].
80 ** Pushing your first commit
82 1. Send [[mailto:bzgATgnuDOTorg][Bastien]] the username you want for https://code.orgmode.org
83 2. Add your public key to your account, once its creation is confirmed
84 3. Clone =org-mode.git=: =~$ git clone git@code.orgmode.org:bzg/org-mode.git=
85 4. Commit your changes against the code and the documentation
87 6. If the tests pass, push your changes
89 If you are undertaking big changes, please create a dedicated branch
90 locally and make sure you have a clean commit history before merging
91 it into the maint or master branch.
93 * Preferred way of submitting patches
100 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
101 Lisp coding conventions]] described in Emacs manual.
103 ** Sending patch with git
105 Please use Git to make patches and send them via email -- this is
106 perfectly fine for major and minor changes.
108 When sending a patch (either using =git diff= or =git format-patch=)
109 please *always add a properly formatted Emacs ChangeLog entry*. See
110 [[#commit-messages][this section]] for details on how to create such a ChangeLog.
114 For every patch you send, we suggest to use =git format-patch=.
116 This is easy for small patches and more consequent ones. Sometimes,
117 you might even want to work in several steps and send each commit
118 separately. Here is the suggested workflow:
121 : ~$ git pull # make sure your repo is up to date
122 : ~$ git branch my-changes # create a new branch from master
123 : ~$ git checkout my-changes # switch to this new branch
125 ... make some changes (1) ...
127 : ~$ git commit -a -m "This is change (1)" # Commit your change
129 ... make another change (2) ...
131 : ~$ git commit -a -m "This is change (2)" # Commit your change
132 : ~$ git format-patch master # Creates two patches
134 ... Then two patches for your two commits are ready to be sent to
138 To finally send the patches, you can either add them as attachments to
139 your email, or use [[https://git-scm.com/docs/git-send-email][git send-email]], if it's properly configured.
141 Write useful commit messages: please provide 1) a reason for it in
142 your email and 2) a ChangeLog entry in the commit message (see [[#commit-messages][this
143 section]] on how to format a ChangeLog entry.)
145 ** Sending quick fixes for testing purpose
147 If you want to send a quick fix that needs to be further tested by
148 other people (before you submit a real patch), here is how you can do:
151 This command will make a patch between the staging area (in your
152 computer), and the file you modified:
154 : git diff -p org-whatever.el > org-whatever.el.diff
156 If you already committed your changes to your index (staging area), then
157 you should compare against a particular branch (in this example,
160 : git diff -p origin/master org-whatever.el > org-whatever.el.diff
162 You email the output to the mailing list, adding =[PATCH]= to the
163 subject, and description of what you fixed or changed.
166 Note that small patches sent like this still need to have a ChangeLog
167 entry to be applied. If your patch looks good to you, it's always
168 better to send a patch through =git format-patch=.
170 ** Sharing changes from a public branch
172 When discussing important changes, it is sometimes not so useful to
173 send long and/or numerous patches.
175 In this case, you can maintain your changes on a public branch of a
176 public clone of Org and send a link to the diff between your changes
177 and the latest Org commit that sits in your clone.
179 If the discussion settles and your change is accepted, you can now
180 send it as (a list of) patch(es) to the latest Org version.
182 * Commit messages and ChangeLog entries
184 :CUSTOM_ID: commit-messages
187 We have decided to no longer keep a ChangeLog file to record changes
188 to individual functions.
190 A commit message should be constructed in the following way:
192 - Line 1 of the commit message should always be a short description of
193 the overall change. Line 1 does /not/ get a dot at the end and does
194 not start with a star. Generally, it starts with the filename that
195 has been changed, followed by a colon.
197 - Line 2 is an empty line.
199 - In line 3, the ChangeLog entry should start. A ChangeLog entry
200 looks like [[https://orgmode.org/cgit.cgi/org-mode.git/commit/?id%3Dd49957ef021e256f19092c907d127390d39ec1ed][this]]:
202 : * org-timer.el (org-timer-cancel-timer, org-timer-stop): Enhance
204 : (org-timer-set-timer): Use the number of minutes in the Effort
205 : property as the default timer value. Three prefix arguments will
206 : ignore the Effort value property.
208 - After the changelog, another empty line should come before any
209 additional information that the committer wishes to provide in order
210 to explain the patch.
212 - If the change is a minor change made by a committer without
213 copyright assignment to the FSF, the commit message should also
214 contain the cookie =TINYCHANGE= (anywhere in the message). When we
215 later produce the ChangeLog file for Emacs, the change will be
216 marked appropriately.
218 - Variables and functions names are quoted like `this' (backquote and
221 - Sentences should be separated by two spaces.
223 - Sentences should start with an uppercase letter.
225 - Avoid the passive form: i.e., use "change" instead of "changed".
227 Here is an example for such a message:
230 org-capture.el: Fix the case of using a template file
232 ,* lisp/org-capture.el (org-capture-set-plist): Make sure txt is a
233 string before calling `string-match'.
234 (org-capture-templates): Fix customization type.
236 ,* doc/org.texi (Capture): Document using a file for a template.
238 The problem here was that a wrong keyword was given in the
239 customization type. This let to a string-match against a list value.
241 Modified from a patch proposal by Johan Friis.
246 If you are using /magit.el/ in Emacs, the ChangeLog for such entries are
247 easily produced by pressing =C= in the diff listing.
249 Another option to produce the entries is to use `C-x 4 a' in the
250 changed function or in the diff listing. This will create entries in
251 the ChangeLog file, and you can then cut and paste these to the commit
252 message and remove the indentation.
254 - Further reference: [[http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE][Contribution guide from Emacs repo]]
256 * Copyright issues when contributing to Emacs Org mode
258 :CUSTOM_ID: copyright-issues
261 Org is made of many files. Most of them are also distributed as part
262 of GNU Emacs. These files are called the /Org core/, and they are all
263 copyrighted by the [[http://www.fsf.org][Free Software Foundation, Inc]].
265 If you consider contributing to these files, your first need to grant
266 the right to include your works in GNU Emacs to the FSF. For this you
267 need to complete [[https://orgmode.org/request-assign-future.txt][this form]], and send it to [[mailto:assign@gnu.org][assign@gnu.org]].
269 The FSF will send you the assignment contract that both you and the
270 FSF will sign. Please let the Org mode maintainer know when this
273 If you want to learn more about /why/ copyright assignments are
274 collected, read this: [[http://www.gnu.org/licenses/why-assign.html][Why the FSF gets copyright assignments from
277 By submitting patches to =emacs-orgmode@gnu.org= or by pushing changes
278 to Org's core files, you are placing these changes under the same
279 licensing terms as those under which GNU Emacs is published.
282 ;; GNU Emacs is free software: you can redistribute it and/or modify
283 ;; it under the terms of the GNU General Public License as published by
284 ;; the Free Software Foundation, either version 3 of the License, or
285 ;; (at your option) any later version.
288 If at the time you submit or push these changes you do have active
289 copyright assignment papers with the FSF, for future changes to either
290 Org mode or to Emacs, this means that copyright to these changes is
291 automatically transferred to the FSF.
293 The Org mode repository is seen as upstream repository for Emacs,
294 anything contained in it can potentially end up in Emacs. If you do
295 not have signed papers with the FSF, only changes to files in the
296 =contrib/= part of the repository will be accepted, as well as very
297 minor changes (so-called /tiny changes/) to core files. We will ask you
298 to sign FSF papers at the moment we attempt to move a =contrib/= file
299 into the Org core, or into Emacs.
301 * Copyrighted contributors to Org mode
303 :CUSTOM_ID: copyrighted-contributors
306 Here is the list of people who have contributed actual code to the Org
307 mode core. Note that the manual contains a more extensive list with
308 acknowledgments, including contributed ideas! The lists below are
309 mostly for house keeping, to help the maintainers keep track of
312 ** Current contributors
314 :CUSTOM_ID: contributors_with_fsf_papers
317 Here is the list of people who signed the papers with the Free Software
318 Foundation and can now freely submit code to Org files that are included
335 - Andrzej Lichnerowicz
342 - Barry Leonard Gidden
358 - Christopher Miles Gray
359 - Christopher Schmidt
360 - Christopher Suckling
361 - Clément Pit--Claudel
364 - Daniel M.\nbsp{}Hackney
365 - David Arroyo Menéndez
372 - Emmanuel Charpentier
375 - Eric S.\nbsp{}Fraga
381 - Francesco Pizzolante
384 - George Kettleborough
388 - Grégoire Jadi (aka Daimrod)
390 - Henning Dietmar Weiss
414 - Jonathan Leech-Pepin
416 - José L.\nbsp{}Doménech
426 - Kevin Brubeck Unhammer
435 - Leonard Avery Randall
446 - Mark A.\nbsp{}Hershberger
455 - Miguel A.\nbsp{}Figueroa-Villanueva
469 - No Wayman (Nicholas Vollmer)
472 - Pedro Alexandre Marcelino Costa da Silva
483 - Rasmus Pank Roulund
488 - Robert Michael Irelan
502 - Siraphob Phipathananunth
517 - Thomas S.\nbsp{}Dye
521 - Timothy E Chapman (TEC)
522 - Titus von der Malsburg
537 - Yuri D.\nbsp{}Lensky
539 - Zhuo Qingliang (Killy Draw)
543 These people have been asked to sign the papers, and they are
544 currently considering it or a request is being processed by the FSF.
546 - Felipe Lema [2020-02-25 mar.]
547 - Brian Carlson [2016-05-24 Tue]
548 - Mats Kindahl (as of 2013-04-06) for [[http://mid.gmane.org/513BAB7D.1000603@oracle.com][this patch]]
553 These people have submitted tiny change patches that made it into Org
554 without FSF papers. When they submit more, we need to get papers
555 eventually. The limit is a cumulative change of 20 non-repetitive
556 change lines. Details are given in [[http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant ][this document]].
558 - Aaron L.\nbsp{}Zeng
559 - Abhishek Chandratre
563 - Alexandru-Sergiu Marton
573 - Arne Babenhauserheide
584 - Christian Schwarzgruber
601 - Francesco Montanari
606 - Greg Tucker-Kellogg
609 - Ivan Vilata i Balaguer
619 - Joaquín Aguirrezabalaga
628 - Konstantin Kliakhandler
630 - Leslie Harlley Watter
667 - Richard Y.\nbsp{}Kim (Kim)
670 - Robert P.\nbsp{}Goldman
674 - Saulius Menkevičius
675 - Sebastien Le Maguer
682 - Stefan-W.\nbsp{}Hahn
689 - Thomas Alexander Gerds
699 - Xavier Martinez-Hidalgo
704 - Zane D.\nbsp{}Purvis
707 (This list may be incomplete - please help completing it.)
711 These people cannot or prefer to not sign the FSF copyright papers,
712 and we can only accept patches that do not change the core files (the
713 ones that are also in Emacs).
715 Luckily, this list is still empty.
717 #+BEGIN: timestamp :string "Last update: " :format "%Y-%m-%d @ %H:%M"