* Re: Someone to help merging orgmode.org/contribute.html and orgmode.org/worg/org-contribute.html ?
2021-10-07 13:11 ` Bastien
2021-10-07 14:05 ` Ihor Radchenko
@ 2021-10-08 12:14 ` Greg Minshall
2021-10-08 13:40 ` Bastien
2023-08-16 12:18 ` Ihor Radchenko
2 siblings, 1 reply; 14+ messages in thread
From: Greg Minshall @ 2021-10-08 12:14 UTC (permalink / raw)
To: Bastien; +Cc: emacs-orgmode
[-- Attachment #1: Type: text/plain, Size: 844 bytes --]
Bastien,
> thanks a lot for volunteering, but I did the merge a few days ago.
great!
> Perhaps you can still carefully proofread
> https://orgmode.org/worg/org-contribute.html and enhance it?
sure. some comments and a patch (and, without the nice css, the .html
file it generates, just for ease of reviewing).
i was thinking of (more or less) sorting the "ways to contribute" in
terms of difficulty/level of expertise required. the below patch tries
to do this (ysomv -- your sort order may vary).
other than that, i did a bit of editing, added a few links and
footnotes, etc.
nit: i don't know how widespread this is, or whether it matters when someone
is looking on worg about how to contribute, but my setup (arch linux,
qutebrowser) doesn't include
: "C-x 8 RET 1f984" or "C-x 8 RET UNICORN FACE"
hope it's of use.
cheers, Greg
[-- Attachment #2: 0002-org-contribute.org-Edit-and-re-organize-slightly.patch --]
[-- Type: text/x-diff, Size: 10373 bytes --]
From 8cf98908c94c2f8bbc0abcfc5cf948dc0a0820e3 Mon Sep 17 00:00:00 2001
From: Greg Minshall <minshall@umich.edu>
Date: Fri, 8 Oct 2021 15:08:17 +0300
Subject: [PATCH 2/2] org-contribute.org: Edit and re-organize slightly
---
org-contribute.org | 90 ++++++++++++++++++++++++----------------------
1 file changed, 48 insertions(+), 42 deletions(-)
diff --git a/org-contribute.org b/org-contribute.org
index a21c5223..d684ccdb 100644
--- a/org-contribute.org
+++ b/org-contribute.org
@@ -19,48 +19,54 @@
The Org codebase is large, and contributing can be daunting at first,
but don't hesitate to call for directions on [[file:org-mailing-list.org][the mailing list]]. If you
-are willing to help, there is plenty of low-hanging fruits for you and
+are willing to help, there is plenty of low-hanging fruit for you, and
the community will welcome your contribution.
-: When contributing, always beware of the maintenance burden:
-: are you alleviating it or are you adding to it?
+: When contributing, always keep the maintenance burden in mind:
+: are you alleviating it, or are you adding to it?
* Ways to contribute 🦄
:PROPERTIES:
:CUSTOM_ID: types-of-contributions
:END:
-- *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 [[file:org-maintenance.org][how Org is maintained]] and let us know by sending an email to
- [[file:org-mailing-list.org][the mailing list]].
+** Ways that do not involve programming
-- *Check the [[https://updates.orgmode.org/#help][requests for help]]*: If you want to help with one of these
- tasks, say so on the list.
-
-- *Check the [[https://updates.orgmode.org/#bugs][list of confirmed bugs]]*: Even if you just provide more
- information or ideas on how to fix them, this helps.
+- *Send bug reports*. Before sending a bug report, make sure you read
+ the section of the manual on how to provide useful [[https://orgmode.org/org.html#Feedback][feedback]] or this
+ other great text: [[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html][How to Send Bug Reports Effectively]].
- *Try to reproduce bugs*: That's always very helpful. Do subscribe to
[[https://lists.gnu.org/mailman/listinfo/emacs-orgmode][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 =X-Woof-Bug: confirmed= to your mail headers, and the
+ poster and add [[https://github.com/bzg/woof][=X-Woof-Bug: confirmed=]] to your mail headers, and the
bug will then be shown on [[https://updates.orgmode.org/#bugs][updates.orgmode.org]].
- *Help other users by replying to their questions* [[file:org-mailing-list.org][on the mailing list]]
or on [[file:org-web-social.org][other web places]].
-- *Send bug reports*. Before sending a bug report, make sure you read
- the section of the manual on how to provide useful [[https://orgmode.org/org.html#Feedback][feedback]] or this
- other great text: [[http://www.chiark.greenend.org.uk/~sgtatham/bugs.html][How to Send Bug Reports Effectively]].
-
-- *Submit patches* to the mailing list. See how to format [[#first-patch][your first
- patch]] and [[#patches][details on how to submit it]].
-
- *Contribute to Worg*. Worg is collaborative documentation made of Org
files. It's very easy to contribute to it. Learn more [[file:worg-about.org][about Worg]]
and [[file:worg-about.org::*How to use git for Worg][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 [[file:org-mailing-list.org][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.
+
+** Ways that involve programming
+
+- *Check the [[https://updates.orgmode.org/#help][requests for help]]*: If you want to help with one of these
+ tasks, say so on the list.
+
+- *Check the [[https://updates.orgmode.org/#bugs][list of confirmed bugs]]*: Even if you just provide more
+ information or ideas on how to fix them, this helps.
+
+- *Submit patches* to the mailing list. See how to format [[#first-patch][your first
+ patch]] and [[#patches][details on how to submit it]].
+
- *Write add-ons*. The best way is to submit your code to [[file:org-mailing-list.org][the mailing
list]] and discuss it with people. Many add-ons are published through
[[https://elpa.gnu.org/][GNU ELPA]] (for authors who signed the FSF copyright assignment) and
@@ -68,17 +74,16 @@ the community will welcome your contribution.
assignment FSF if you want to add your code in Org's core, because
it will end up in GNU Emacs.
-- *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 [[file:org-mailing-list.org][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.
+- *Maintain an Org file*: If a file in the git repository does not
+ have a maintainer [fn:: =grep -lv "^;; Maintainer:" `find ./lisp
+ -name "*.el"` | less=] and you want to help by maintaining it,
+ please read more on [[file:org-maintenance.org][how Org is maintained]] and let us know by sending
+ an email to [[file:org-mailing-list.org][the mailing list]].
* What does NOT help
- Submitting feature requests without proper justification.
-- Submitting "It does not work" bug reports.
+- Submitting [[https://www.chiark.greenend.org.uk/~sgtatham/bugs.html]["It does not work"]] bug reports.
- Submitting ill-formatted patches.
- Sending too many emails.
- Arguing.
@@ -97,8 +102,8 @@ Contributions are discussed on the [[https://orgmode.org/worg/org-mailing-list.h
reproducing the bug. Please make it easier by providing a minimal
reproducible recipe. Check the manual on how to provide [[https://orgmode.org/manual/Feedback.html][feedback]].
If no one replies, don't take it personally: it either means that
- nobody was able to reproduce the bug or that the bug is not that
- critical for someone else to confirm it.
+ nobody was able to reproduce the bug or that the bug does not seem
+ that critical for someone else to confirm it.
- When you contribute with a patch :: Your patch will be listed on
[[https://updates.orgmode.org][updates.orgmode.org]]. If this is your first patch, don't expect the
@@ -119,8 +124,9 @@ In general, if you want to raise awareness on an email you sent,
please wait at least for *one month* before bumping a thread. See [[file:org-mailing-list.org::#i-didnt-receive-an-answer][What
to do if you don't receive an answer]].
-The Org mailing list has *contributor stewards* who will try their best
-to make sure your contributions get all the attention they deserve.
+The Org mailing list has volunteer *contributor stewards* who will try
+their best to make sure your contributions get all the attention they
+deserve.
* Your first patch as an occasional contributor
:PROPERTIES:
@@ -139,13 +145,11 @@ go through before submitting a patch:
6. If relevant, don't forget to update =doc/org-manual.org=
7. Take extra care of the commit message (see [[#commit-messages][Commit messages and ChangeLog entries]])
8. If your change is small enough and you didn't sign the FSF
- copyright assignment, include =TINYCHANGE= at the bottom of the
- commit message.
-
-Your total contribution (all patches you submit) should change /less
-than 15 lines/. See the [[http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE][CONTRIBUTE file in GNU Emacs]]. If you contribute
-more, you have to assign the [[#copyright][copyright]] of your contribution to the
-Free Software Foundation.
+ copyright assignment,[fn:: Your total contribution (all patches you
+ submit) should change /less than 15 lines/. See the [[http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE][CONTRIBUTE file
+ in GNU Emacs]]. If you contribute more, you have to assign the
+ [[#copyright][copyright]] of your contribution to the Free Software Foundation.]
+ include =TINYCHANGE= at the bottom of the commit message.
* Details on how to submit patches
:PROPERTIES:
@@ -160,7 +164,7 @@ Lisp coding conventions]] described in Emacs manual.
** Sending patches with Git
Please use Git to make patches and send them via email -- this is
-perfectly fine for major and minor changes.
+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
@@ -193,13 +197,14 @@ To finally send the patches, you can either add them as attachments to
your email or use [[https://git-scm.com/docs/git-send-email][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 (see [[#commit-messages][this
-section]] on how to format a ChangeLog entry.)
+your email and (2) a ChangeLog entry in the commit message (again, see
+[[#commit-messages][this section]] on how to format a ChangeLog entry.)
** Sending quick fixes for testing purpose
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 how you can do:
+other people (before you submit a real patch), here is what you can
+do:
#+begin_quote
This command will make a patch between the staging area (in your
@@ -268,6 +273,7 @@ A commit message should be constructed in the following way:
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.
--
2.32.0
[-- Attachment #3: org-contribute.html --]
[-- Type: text/xml, Size: 30445 bytes --]
<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en">
<head>
<!-- 2021-10-08 Fri 15:12 -->
<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1" />
<title>Contributing to Org</title>
<meta name="author" content="Worg people" />
<meta name="generator" content="Org Mode" />
<style>
#content { max-width: 60em; margin: auto; }
.title { text-align: center;
margin-bottom: .2em; }
.subtitle { text-align: center;
font-size: medium;
font-weight: bold;
margin-top:0; }
.todo { font-family: monospace; color: red; }
.done { font-family: monospace; color: green; }
.priority { font-family: monospace; color: orange; }
.tag { background-color: #eee; font-family: monospace;
padding: 2px; font-size: 80%; font-weight: normal; }
.timestamp { color: #bebebe; }
.timestamp-kwd { color: #5f9ea0; }
.org-right { margin-left: auto; margin-right: 0px; text-align: right; }
.org-left { margin-left: 0px; margin-right: auto; text-align: left; }
.org-center { margin-left: auto; margin-right: auto; text-align: center; }
.underline { text-decoration: underline; }
#postamble p, #preamble p { font-size: 90%; margin: .2em; }
p.verse { margin-left: 3%; }
pre {
border: 1px solid #e6e6e6;
border-radius: 3px;
background-color: #f2f2f2;
padding: 8pt;
font-family: monospace;
overflow: auto;
margin: 1.2em;
}
pre.src {
position: relative;
overflow: auto;
}
pre.src:before {
display: none;
position: absolute;
top: -8px;
right: 12px;
padding: 3px;
color: #555;
background-color: #f2f2f299;
}
pre.src:hover:before { display: inline; margin-top: 14px;}
/* Languages per Org manual */
pre.src-asymptote:before { content: 'Asymptote'; }
pre.src-awk:before { content: 'Awk'; }
pre.src-authinfo::before { content: 'Authinfo'; }
pre.src-C:before { content: 'C'; }
/* pre.src-C++ doesn't work in CSS */
pre.src-clojure:before { content: 'Clojure'; }
pre.src-css:before { content: 'CSS'; }
pre.src-D:before { content: 'D'; }
pre.src-ditaa:before { content: 'ditaa'; }
pre.src-dot:before { content: 'Graphviz'; }
pre.src-calc:before { content: 'Emacs Calc'; }
pre.src-emacs-lisp:before { content: 'Emacs Lisp'; }
pre.src-fortran:before { content: 'Fortran'; }
pre.src-gnuplot:before { content: 'gnuplot'; }
pre.src-haskell:before { content: 'Haskell'; }
pre.src-hledger:before { content: 'hledger'; }
pre.src-java:before { content: 'Java'; }
pre.src-js:before { content: 'Javascript'; }
pre.src-latex:before { content: 'LaTeX'; }
pre.src-ledger:before { content: 'Ledger'; }
pre.src-lisp:before { content: 'Lisp'; }
pre.src-lilypond:before { content: 'Lilypond'; }
pre.src-lua:before { content: 'Lua'; }
pre.src-matlab:before { content: 'MATLAB'; }
pre.src-mscgen:before { content: 'Mscgen'; }
pre.src-ocaml:before { content: 'Objective Caml'; }
pre.src-octave:before { content: 'Octave'; }
pre.src-org:before { content: 'Org mode'; }
pre.src-oz:before { content: 'OZ'; }
pre.src-plantuml:before { content: 'Plantuml'; }
pre.src-processing:before { content: 'Processing.js'; }
pre.src-python:before { content: 'Python'; }
pre.src-R:before { content: 'R'; }
pre.src-ruby:before { content: 'Ruby'; }
pre.src-sass:before { content: 'Sass'; }
pre.src-scheme:before { content: 'Scheme'; }
pre.src-screen:before { content: 'Gnu Screen'; }
pre.src-sed:before { content: 'Sed'; }
pre.src-sh:before { content: 'shell'; }
pre.src-sql:before { content: 'SQL'; }
pre.src-sqlite:before { content: 'SQLite'; }
/* additional languages in org.el's org-babel-load-languages alist */
pre.src-forth:before { content: 'Forth'; }
pre.src-io:before { content: 'IO'; }
pre.src-J:before { content: 'J'; }
pre.src-makefile:before { content: 'Makefile'; }
pre.src-maxima:before { content: 'Maxima'; }
pre.src-perl:before { content: 'Perl'; }
pre.src-picolisp:before { content: 'Pico Lisp'; }
pre.src-scala:before { content: 'Scala'; }
pre.src-shell:before { content: 'Shell Script'; }
pre.src-ebnf2ps:before { content: 'ebfn2ps'; }
/* additional language identifiers per "defun org-babel-execute"
in ob-*.el */
pre.src-cpp:before { content: 'C++'; }
pre.src-abc:before { content: 'ABC'; }
pre.src-coq:before { content: 'Coq'; }
pre.src-groovy:before { content: 'Groovy'; }
/* additional language identifiers from org-babel-shell-names in
ob-shell.el: ob-shell is the only babel language using a lambda to put
the execution function name together. */
pre.src-bash:before { content: 'bash'; }
pre.src-csh:before { content: 'csh'; }
pre.src-ash:before { content: 'ash'; }
pre.src-dash:before { content: 'dash'; }
pre.src-ksh:before { content: 'ksh'; }
pre.src-mksh:before { content: 'mksh'; }
pre.src-posh:before { content: 'posh'; }
/* Additional Emacs modes also supported by the LaTeX listings package */
pre.src-ada:before { content: 'Ada'; }
pre.src-asm:before { content: 'Assembler'; }
pre.src-caml:before { content: 'Caml'; }
pre.src-delphi:before { content: 'Delphi'; }
pre.src-html:before { content: 'HTML'; }
pre.src-idl:before { content: 'IDL'; }
pre.src-mercury:before { content: 'Mercury'; }
pre.src-metapost:before { content: 'MetaPost'; }
pre.src-modula-2:before { content: 'Modula-2'; }
pre.src-pascal:before { content: 'Pascal'; }
pre.src-ps:before { content: 'PostScript'; }
pre.src-prolog:before { content: 'Prolog'; }
pre.src-simula:before { content: 'Simula'; }
pre.src-tcl:before { content: 'tcl'; }
pre.src-tex:before { content: 'TeX'; }
pre.src-plain-tex:before { content: 'Plain TeX'; }
pre.src-verilog:before { content: 'Verilog'; }
pre.src-vhdl:before { content: 'VHDL'; }
pre.src-xml:before { content: 'XML'; }
pre.src-nxml:before { content: 'XML'; }
/* add a generic configuration mode; LaTeX export needs an additional
(add-to-list 'org-latex-listings-langs '(conf " ")) in .emacs */
pre.src-conf:before { content: 'Configuration File'; }
table { border-collapse:collapse; }
caption.t-above { caption-side: top; }
caption.t-bottom { caption-side: bottom; }
td, th { vertical-align:top; }
th.org-right { text-align: center; }
th.org-left { text-align: center; }
th.org-center { text-align: center; }
td.org-right { text-align: right; }
td.org-left { text-align: left; }
td.org-center { text-align: center; }
dt { font-weight: bold; }
.footpara { display: inline; }
.footdef { margin-bottom: 1em; }
.figure { padding: 1em; }
.figure p { text-align: center; }
.equation-container {
display: table;
text-align: center;
width: 100%;
}
.equation {
vertical-align: middle;
}
.equation-label {
display: table-cell;
text-align: right;
vertical-align: middle;
}
.inlinetask {
padding: 10px;
border: 2px solid gray;
margin: 10px;
background: #ffffcc;
}
#org-div-home-and-up
{ text-align: right; font-size: 70%; white-space: nowrap; }
textarea { overflow-x: auto; }
.linenr { font-size: smaller }
.code-highlighted { background-color: #ffff00; }
.org-info-js_info-navigation { border-style: none; }
#org-info-js_console-label
{ font-size: 10px; font-weight: bold; white-space: nowrap; }
.org-info-js_search-highlight
{ background-color: #ffff00; color: #000000; font-weight: bold; }
.org-svg { width: 90%; }
</style>
</head>
<body>
<div id="org-div-home-and-up">
<a accesskey="h" href="index.html"> UP </a>
|
<a accesskey="H" href="https://orgmode.org/worg/"> HOME </a>
</div><div id="content" class="content">
<h1 class="title">Contributing to Org</h1>
<div id="table-of-contents" role="doc-toc">
<h2>Table of Contents</h2>
<div id="text-table-of-contents" role="doc-toc">
<ul>
<li><a href="#types-of-contributions">Ways to contribute 🦄</a>
<ul>
<li><a href="#org1323992">Ways that do not involve programming</a></li>
<li><a href="#org088f93b">Ways that involve programming</a></li>
</ul>
</li>
<li><a href="#orgc3467a1">What does NOT help</a></li>
<li><a href="#what-can-I-expect">As a contributor, what can I expect?</a></li>
<li><a href="#first-patch">Your first patch as an occasional contributor</a></li>
<li><a href="#patches">Details on how to submit patches</a>
<ul>
<li><a href="#org601463f">Coding conventions</a></li>
<li><a href="#org7397a36">Sending patches with Git</a></li>
<li><a href="#orgb8a6ece">Sending commits</a></li>
<li><a href="#org9834694">Sending quick fixes for testing purpose</a></li>
<li><a href="#orga49e377">Sharing changes from a public branch</a></li>
</ul>
</li>
<li><a href="#devs">Your first commit as an Org maintainer</a></li>
<li><a href="#commit-messages">Commit messages and ChangeLog entries</a></li>
<li><a href="#copyright">Dealing with copyright when contributing to Org mode</a></li>
<li><a href="#contributors">Current contributors</a></li>
</ul>
</div>
</div>
<p>
The Org codebase is large, and contributing can be daunting at first,
but don't hesitate to call for directions on <a href="org-mailing-list.html">the mailing list</a>. If you
are willing to help, there is plenty of low-hanging fruit for you, and
the community will welcome your contribution.
</p>
<pre class="example">
When contributing, always keep the maintenance burden in mind:
are you alleviating it, or are you adding to it?
</pre>
<div id="outline-container-types-of-contributions" class="outline-2">
<h2 id="types-of-contributions">Ways to contribute 🦄</h2>
<div class="outline-text-2" id="text-types-of-contributions">
</div>
<div id="outline-container-org1323992" class="outline-3">
<h3 id="org1323992">Ways that do not involve programming</h3>
<div class="outline-text-3" id="text-org1323992">
<ul class="org-ul">
<li><b>Send bug reports</b>. Before sending a bug report, make sure you read
the section of the manual on how to provide useful <a href="https://orgmode.org/org.html#Feedback">feedback</a> or this
other great text: <a href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">How to Send Bug Reports Effectively</a>.</li>
<li><b>Try to reproduce bugs</b>: That's always very helpful. Do subscribe to
<a href="https://lists.gnu.org/mailman/listinfo/emacs-orgmode">Org's mailing list</a> and monitor new unreferenced bugs. Try to
reproduce them. If you can reproduce a bug, reply to the original
poster and add <a href="https://github.com/bzg/woof"><code>X-Woof-Bug: confirmed</code></a> to your mail headers, and the
bug will then be shown on <a href="https://updates.orgmode.org/#bugs">updates.orgmode.org</a>.</li>
<li><b>Help other users by replying to their questions</b> <a href="org-mailing-list.html">on the mailing list</a>
or on <a href="org-web-social.html">other web places</a>.</li>
<li><b>Contribute to Worg</b>. Worg is collaborative documentation made of Org
files. It's very easy to contribute to it. Learn more <a href="worg-about.html">about Worg</a>
and <a href="worg-about.html#MissingReference">how to contribute</a>.</li>
<li><b>Share ideas and feature requests</b>. Org is already mature, but new
ideas keep popping up. If you want to request a feature, first dig
into <a href="org-mailing-list.html">the mailing list</a> 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.</li>
</ul>
</div>
</div>
<div id="outline-container-org088f93b" class="outline-3">
<h3 id="org088f93b">Ways that involve programming</h3>
<div class="outline-text-3" id="text-org088f93b">
<ul class="org-ul">
<li><b>Check the <a href="https://updates.orgmode.org/#help">requests for help</a></b>: If you want to help with one of these
tasks, say so on the list.</li>
<li><b>Check the <a href="https://updates.orgmode.org/#bugs">list of confirmed bugs</a></b>: Even if you just provide more
information or ideas on how to fix them, this helps.</li>
<li><b>Submit patches</b> to the mailing list. See how to format <a href="#first-patch">your first
patch</a> and <a href="#patches">details on how to submit it</a>.</li>
<li><b>Write add-ons</b>. The best way is to submit your code to <a href="org-mailing-list.html">the mailing
list</a> and discuss it with people. Many add-ons are published through
<a href="https://elpa.gnu.org/">GNU ELPA</a> (for authors who signed the FSF copyright assignment) and
<a href="https://elpa.nongnu.org/">NonGNU ELPA</a> (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.</li>
<li><b>Maintain an Org file</b>: If a file in the git repository does not
have a maintainer <sup><a id="fnr.1" class="footref" href="#fn.1" role="doc-backlink">1</a></sup> and you want to help by maintaining it,
please read more on <a href="org-maintenance.html">how Org is maintained</a> and let us know by sending
an email to <a href="org-mailing-list.html">the mailing list</a>.</li>
</ul>
</div>
</div>
</div>
<div id="outline-container-orgc3467a1" class="outline-2">
<h2 id="orgc3467a1">What does NOT help</h2>
<div class="outline-text-2" id="text-orgc3467a1">
<ul class="org-ul">
<li>Submitting feature requests without proper justification.</li>
<li>Submitting <a href="https://www.chiark.greenend.org.uk/~sgtatham/bugs.html">"It does not work"</a> bug reports.</li>
<li>Submitting ill-formatted patches.</li>
<li>Sending too many emails.</li>
<li>Arguing.</li>
</ul>
<p>
We follow the <a href="https://www.gnu.org/philosophy/kind-communication.html">GNU Kind Communications Guidelines</a> and ask you to follow
them too.
</p>
</div>
</div>
<div id="outline-container-what-can-I-expect" class="outline-2">
<h2 id="what-can-I-expect">As a contributor, what can I expect?</h2>
<div class="outline-text-2" id="text-what-can-I-expect">
<p>
Contributions are discussed on the <a href="https://orgmode.org/worg/org-mailing-list.html">Org mailing list</a>.
</p>
<dl class="org-dl">
<dt>When you contribute with a bug report</dt><dd>Expect someone to try
reproducing the bug. Please make it easier by providing a minimal
reproducible recipe. Check the manual on how to provide <a href="https://orgmode.org/manual/Feedback.html">feedback</a>.
If no one replies, don't take it personally: it either means that
nobody was able to reproduce the bug or that the bug does not seem
that critical for someone else to confirm it.</dd>
<dt>When you contribute with a patch</dt><dd>Your patch will be listed on
<a href="https://updates.orgmode.org">updates.orgmode.org</a>. If this is your first patch, don't expect the
patch to be applied immediately. You can expect someone to review
it and to suggest changes, either on the technical or formal aspects
of the patch. If nobody seems to care enough to reply, don't take
it personally: it means that maintainers are busy and/or that the
patch does not seem critical enough.</dd>
<dt>When you contribute with an idea or a feature request</dt><dd>The best
way to convince maintainers that your idea is worth considering is
by detailing your use-case and by proposing a patch for it. Expect
people to discuss the idea on the list, but please remember Org is
very old now, used by many people with various needs. If nobody
replies, don't take it personally.</dd>
</dl>
<p>
In general, if you want to raise awareness on an email you sent,
please wait at least for <b>one month</b> before bumping a thread. See <a href="org-mailing-list.html#i-didnt-receive-an-answer">What
to do if you don't receive an answer</a>.
</p>
<p>
The Org mailing list has volunteer <b>contributor stewards</b> who will try
their best to make sure your contributions get all the attention they
deserve.
</p>
</div>
</div>
<div id="outline-container-first-patch" class="outline-2">
<h2 id="first-patch">Your first patch as an occasional contributor</h2>
<div class="outline-text-2" id="text-first-patch">
<p>
You don't need write access to the repository to contribute with
patches, just send them to <a href="org-mailing-list.html">the mailing list</a>. Here is a checklist to
go through before submitting a patch:
</p>
<ol class="org-ol">
<li>Make your patch against the latest <code>bugfix</code> or <code>main</code> branch</li>
<li>Run <code>~$ make test</code> to catch broken tests</li>
<li>Check compilation warnings with <code>~$ make compile</code></li>
<li>If relevant, include or update tests</li>
<li>If your patch is adding a feature, please update <code>etc/ORG-NEWS</code></li>
<li>If relevant, don't forget to update <code>doc/org-manual.org</code></li>
<li>Take extra care of the commit message (see <a href="#commit-messages">Commit messages and ChangeLog entries</a>)</li>
<li>If your change is small enough and you didn't sign the FSF
copyright assignment,<sup><a id="fnr.2" class="footref" href="#fn.2" role="doc-backlink">2</a></sup>
include <code>TINYCHANGE</code> at the bottom of the commit message.</li>
</ol>
</div>
</div>
<div id="outline-container-patches" class="outline-2">
<h2 id="patches">Details on how to submit patches</h2>
<div class="outline-text-2" id="text-patches">
</div>
<div id="outline-container-org601463f" class="outline-3">
<h3 id="org601463f">Coding conventions</h3>
<div class="outline-text-3" id="text-org601463f">
<p>
Org is part of Emacs, so any contribution should follow the <a href="http://www.gnu.org/software/emacs/manual/html_node/elisp/Coding-Conventions.html">GNU Emacs
Lisp coding conventions</a> described in Emacs manual.
</p>
</div>
</div>
<div id="outline-container-org7397a36" class="outline-3">
<h3 id="org7397a36">Sending patches with Git</h3>
<div class="outline-text-3" id="text-org7397a36">
<p>
Please use Git to make patches and send them via email – this is
perfectly fine for both major and minor changes.
</p>
<p>
When sending a patch (using <code>git diff</code>, <code>git format-patch</code> or <code>git
send-email</code>, <b>always add a properly formatted Emacs ChangeLog entry</b> in
the commit message. See <a href="#commit-messages">this section</a> for details on how to create
such a ChangeLog.
</p>
</div>
</div>
<div id="outline-container-orgb8a6ece" class="outline-3">
<h3 id="orgb8a6ece">Sending commits</h3>
<div class="outline-text-3" id="text-orgb8a6ece">
<p>
For every patch you send, we suggest to use <code>git format-patch</code> or <code>git
send-email</code>. Here is a suggested workflow:
</p>
<blockquote>
<pre class="example">
~$ 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
</pre>
<p>
… make some changes (1) …
</p>
<pre class="example">
~$ git commit -a -m "This is change (1)" # Commit your change
</pre>
<p>
… make another change (2) …
</p>
<pre class="example">
~$ git commit -a -m "This is change (2)" # Commit your change
~$ git format-patch main # Creates two patches
</pre>
<p>
Then two patches for your two commits are ready to be sent to the list.
</p>
</blockquote>
<p>
To finally send the patches, you can either add them as attachments to
your email or use <a href="https://git-scm.com/docs/git-send-email">git send-email</a>, if it's properly configured.
</p>
<p>
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
<a href="#commit-messages">this section</a> on how to format a ChangeLog entry.)
</p>
</div>
</div>
<div id="outline-container-org9834694" class="outline-3">
<h3 id="org9834694">Sending quick fixes for testing purpose</h3>
<div class="outline-text-3" id="text-org9834694">
<p>
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:
</p>
<blockquote>
<p>
This command will make a patch between the staging area (in your
computer), and the file you modified:
</p>
<pre class="example">
git diff -p org-whatever.el > org-whatever.el.diff
</pre>
<p>
If you already committed your changes to your index (staging area), then
you should compare against a particular branch (in this example,
<code>origin/main</code>):
</p>
<pre class="example">
git diff -p origin/main org-whatever.el > org-whatever.el.diff
</pre>
<p>
You email the output to the mailing list, adding <code>[PATCH]</code> to the
subject, and description of what you fixed or changed.
</p>
</blockquote>
<p>
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 <code>git format-patch</code>.
</p>
</div>
</div>
<div id="outline-container-orga49e377" class="outline-3">
<h3 id="orga49e377">Sharing changes from a public branch</h3>
<div class="outline-text-3" id="text-orga49e377">
<p>
When discussing important changes, it is sometimes not so useful to
send long and/or numerous patches.
</p>
<p>
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.
</p>
<p>
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.
</p>
</div>
</div>
</div>
<div id="outline-container-devs" class="outline-2">
<h2 id="devs">Your first commit as an Org maintainer</h2>
<div class="outline-text-2" id="text-devs">
<p>
Org regular contributors and maintainers have write access to the <a href="https://git.savannah.gnu.org/cgit/emacs/org-mode.git/">Git
repository</a>.
</p>
<ol class="org-ol">
<li>Fill in <a href="https://orgmode.org/request-assign-future.txt">this form</a> and wait for the FSF feedback</li>
<li>Create an account on <a href="https://savannah.gnu.org">savannah.gnu.org</a></li>
<li>Request to join the <a href="https://savannah.gnu.org/projects/emacs/">Savannah Emacs group</a></li>
</ol>
<p>
Once you are granted access to the Emacs group:
</p>
<ol class="org-ol">
<li>Apply your changes against the code and the documentation</li>
<li>Run <code>make test</code></li>
<li>If the tests pass, commit and push your changes</li>
</ol>
<p>
If you are undertaking big changes, please create a dedicated branch
locally and make sure you have a clean commit history before merging
it into the <code>bugfix</code> or <code>main</code> branch.
</p>
<p>
To check our Git workflow, please read <a href="https://orgmode.org/worg/org-maintenance.html">Org maintenance</a>.
</p>
</div>
</div>
<div id="outline-container-commit-messages" class="outline-2">
<h2 id="commit-messages">Commit messages and ChangeLog entries</h2>
<div class="outline-text-2" id="text-commit-messages">
<p>
A commit message should be constructed in the following way:
</p>
<ul class="org-ul">
<li><p>
Line 1 of the commit message should always be a short description of
the overall change. Line 1 does <i>not</i> 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:
</p>
<pre class="example">
lisp/ol-man.el: Restore file
</pre></li>
<li>Line 2 is an empty line.</li>
<li><p>
Line 3 starts the ChangeLog entry. It looks like <a href="https://git.savannah.gnu.org/cgit/emacs/org-mode.git/commit/?id=d49957ef021e256f19092c907d127390d39ec1ed">this</a>:
</p>
<pre class="example">
* 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.
</pre></li>
<li>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.</li>
<li>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 <code>TINYCHANGE</code> after the ChangeLog entry.</li>
<li>Variables and functions names are quoted like <code>`this'</code> (a backquote
and a single quote).</li>
<li>Sentences should be separated by two spaces.</li>
<li>Sentences should start with an uppercase letter.</li>
<li>Avoid the passive form: i.e., use "change" instead of "changed".</li>
</ul>
<p>
Here is an example for such a message:
</p>
<pre class="example" id="org7d7a387">
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
</pre>
<p>
If you are using <a href="https://magit.vc/">magit</a> in Emacs, the ChangeLog for such entries can be
produced by pressing <code>C</code> (for <code>magit-commit-add-log</code>) on the diff chunks
of a staged file. (If you prefer storing your ChangeLog entries in a
file, you can also use <code>C-x 4 a</code>
(<code>magit-add-change-log-entry-other-window</code>) from within magit display of
diff chunks.)
</p>
<p>
Another option to produce the entries is to use <code>C-x 4 a</code> 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.
</p>
<p>
Further reference:
</p>
<ul class="org-ul">
<li><a href="https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html#Style-of-Change-Logs">Standard Emacs change log entry format</a></li>
<li><a href="http://git.savannah.gnu.org/cgit/emacs.git/plain/CONTRIBUTE">Contribution guide from Emacs repo</a></li>
</ul>
</div>
</div>
<div id="outline-container-copyright" class="outline-2">
<h2 id="copyright">Dealing with copyright when contributing to Org mode</h2>
<div class="outline-text-2" id="text-copyright">
<p>
All Elisp Org files are also distributed as part of GNU Emacs, they
are all copyrighted by the <a href="http://www.fsf.org">Free Software Foundation, Inc</a>.
</p>
<p>
If you consider contributing to these files, your need to grant the
right to include your works in GNU Emacs to the FSF. For this, you
need to complete <a href="https://orgmode.org/request-assign-future.txt">this form</a>, and to send it to <a href="mailto:assign@gnu.org">assign@gnu.org</a>.
</p>
<p>
The FSF will send you the assignment contract that both you and the
FSF will sign. Please let the Org mode maintainer know when this
process is complete.
</p>
<p>
If you want to learn more about <i>why</i> copyright assignments are
collected, read this: <a href="http://www.gnu.org/licenses/why-assign.html">Why the FSF gets copyright assignments from
contributors?</a>
</p>
<p>
By submitting patches to <code>emacs-orgmode@gnu.org</code> or by pushing changes
to Org's core files, you are placing these changes under the same
licensing terms as those under which GNU Emacs is published.
</p>
<pre class="example" id="orge2c9fe6">
;; GNU Emacs is free software: you can redistribute it and/or modify
;; it under the terms of the GNU General Public License as published by
;; the Free Software Foundation, either version 3 of the License, or
;; (at your option) any later version.
</pre>
<p>
If at the time you submit or push these changes you do have active
copyright assignment papers with the FSF, for future changes to either
Org mode or to Emacs, this means that copyright to these changes is
automatically transferred to the FSF.
</p>
<p>
The Org mode repository is seen as upstream repository for Emacs,
anything contained in it can potentially end up in Emacs.
</p>
</div>
</div>
<div id="outline-container-contributors" class="outline-2">
<h2 id="contributors">Current contributors</h2>
<div class="outline-text-2" id="text-contributors">
<p>
You can check current contributors on <a href="contributors.html">this page</a>.
</p>
</div>
</div>
<div id="footnotes">
<h2 class="footnotes">Footnotes: </h2>
<div id="text-footnotes">
<div class="footdef"><sup><a id="fn.1" class="footnum" href="#fnr.1" role="doc-backlink">1</a></sup> <div class="footpara" role="doc-footnote"><p class="footpara"><code>grep -lv "^;; Maintainer:" `find ./lisp
-name "*.el"` | less</code></p></div></div>
<div class="footdef"><sup><a id="fn.2" class="footnum" href="#fnr.2" role="doc-backlink">2</a></sup> <div class="footpara" role="doc-footnote"><p class="footpara">Your total contribution (all patches you
submit) should change <i>less than 15 lines</i>. See the <a href="http://git.savannah.gnu.org/cgit/emacs.git/tree/CONTRIBUTE">CONTRIBUTE file
in GNU Emacs</a>. If you contribute more, you have to assign the
<a href="#copyright">copyright</a> of your contribution to the Free Software Foundation.</p></div></div>
</div>
</div></div>
<div id="postamble" class="status">
<p class="author">Author: Worg people</p>
<p class="date">Created: 2021-10-08 Fri 15:12</p>
<p class="validation"><a href="https://validator.w3.org/check?uri=referer">Validate</a></p>
</div>
</body>
</html>
^ permalink raw reply related [flat|nested] 14+ messages in thread