요약·해설과 원문, 전문 번역을 서로 분리했습니다. API 이름, symbol, source path는 원문 표기를 사용합니다.
1. 요약·해설
원문의 핵심 논리와 kernel programming 관점의 보충 설명입니다. 아래의 전문 번역과는 별도로 작성했습니다.
2. 영어 원문 전체
번역 기준이 된 Linux v6.18.37 원문입니다. 줄 번호는 이 버전의 파일 좌표입니다.
원문 전체 펼치기
1
.. SPDX-License-Identifier: GPL-2.0
3
How to help improve kernel documentation
4
========================================
6
Documentation is an important part of any software-development project.
7
Good documentation helps to bring new developers in and helps established
8
developers work more effectively. Without top-quality documentation, a lot
9
of time is wasted in reverse-engineering the code and making avoidable
10
mistakes.
12
Unfortunately, the kernel's documentation currently falls far short of what
13
it needs to be to support a project of this size and importance.
15
This guide is for contributors who would like to improve that situation.
16
Kernel documentation improvements can be made by developers at a variety of
17
skill levels; they are a relatively easy way to learn the kernel process in
18
general and find a place in the community. The bulk of what follows is the
19
documentation maintainer's list of tasks that most urgently need to be
20
done.
22
The documentation TODO list
23
---------------------------
25
There is an endless list of tasks that need to be carried out to get our
26
documentation to where it should be. This list contains a number of
27
important items, but is far from exhaustive; if you see a different way to
28
improve the documentation, please do not hold back!
30
Addressing warnings
31
~~~~~~~~~~~~~~~~~~~
33
The documentation build currently spews out an unbelievable number of
34
warnings. When you have that many, you might as well have none at all;
35
people ignore them, and they will never notice when their work adds new
36
ones. For this reason, eliminating warnings is one of the highest-priority
37
tasks on the documentation TODO list. The task itself is reasonably
38
straightforward, but it must be approached in the right way to be
39
successful.
41
Warnings issued by a compiler for C code can often be dismissed as false
42
positives, leading to patches aimed at simply shutting the compiler up.
43
Warnings from the documentation build almost always point at a real
44
problem; making those warnings go away requires understanding the problem
45
and fixing it at its source. For this reason, patches fixing documentation
46
warnings should probably not say "fix a warning" in the changelog title;
47
they should indicate the real problem that has been fixed.
49
Another important point is that documentation warnings are often created by
50
problems in kerneldoc comments in C code. While the documentation
51
maintainer appreciates being copied on fixes for these warnings, the
52
documentation tree is often not the right one to actually carry those
53
fixes; they should go to the maintainer of the subsystem in question.
55
For example, in a documentation build I grabbed a pair of warnings nearly
56
at random::
58
./drivers/devfreq/devfreq.c:1818: warning: bad line:
59
- Resource-managed devfreq_register_notifier()
60
./drivers/devfreq/devfreq.c:1854: warning: bad line:
61
- Resource-managed devfreq_unregister_notifier()
63
(The lines were split for readability).
65
A quick look at the source file named above turned up a couple of kerneldoc
66
comments that look like this::
68
/**
69
* devm_devfreq_register_notifier()
70
- Resource-managed devfreq_register_notifier()
71
* @dev: The devfreq user device. (parent of devfreq)
72
* @devfreq: The devfreq object.
73
* @nb: The notifier block to be unregistered.
74
* @list: DEVFREQ_TRANSITION_NOTIFIER.
75
*/
77
The problem is the missing "*", which confuses the build system's
78
simplistic idea of what C comment blocks look like. This problem had been
79
present since that comment was added in 2016 — a full four years. Fixing
80
it was a matter of adding the missing asterisks. A quick look at the
81
history for that file showed what the normal format for subject lines is,
82
and ``scripts/get_maintainer.pl`` told me who should receive it (pass paths to
83
your patches as arguments to scripts/get_maintainer.pl). The resulting patch
84
looked like this::
86
[PATCH] PM / devfreq: Fix two malformed kerneldoc comments
88
Two kerneldoc comments in devfreq.c fail to adhere to the required format,
89
resulting in these doc-build warnings:
91
./drivers/devfreq/devfreq.c:1818: warning: bad line:
92
- Resource-managed devfreq_register_notifier()
93
./drivers/devfreq/devfreq.c:1854: warning: bad line:
94
- Resource-managed devfreq_unregister_notifier()
96
Add a couple of missing asterisks and make kerneldoc a little happier.
98
Signed-off-by: Jonathan Corbet <[email protected]>
99
---
100
drivers/devfreq/devfreq.c | 4 ++--
101
1 file changed, 2 insertions(+), 2 deletions(-)
103
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
104
index 57f6944d65a6..00c9b80b3d33 100644
105
--- a/drivers/devfreq/devfreq.c
106
+++ b/drivers/devfreq/devfreq.c
107
@@ -1814,7 +1814,7 @@ static void devm_devfreq_notifier_release(struct device *dev, void *res)
109
/**
110
* devm_devfreq_register_notifier()
111
- - Resource-managed devfreq_register_notifier()
112
+ * - Resource-managed devfreq_register_notifier()
113
* @dev: The devfreq user device. (parent of devfreq)
114
* @devfreq: The devfreq object.
115
* @nb: The notifier block to be unregistered.
116
@@ -1850,7 +1850,7 @@ EXPORT_SYMBOL(devm_devfreq_register_notifier);
118
/**
119
* devm_devfreq_unregister_notifier()
120
- - Resource-managed devfreq_unregister_notifier()
121
+ * - Resource-managed devfreq_unregister_notifier()
122
* @dev: The devfreq user device. (parent of devfreq)
123
* @devfreq: The devfreq object.
124
* @nb: The notifier block to be unregistered.
125
--
126
2.24.1
128
The entire process only took a few minutes. Of course, I then found that
129
somebody else had fixed it in a separate tree, highlighting another lesson:
130
always check linux-next to see if a problem has been fixed before you dig
131
into it.
133
Other fixes will take longer, especially those relating to structure
134
members or function parameters that lack documentation. In such cases, it
135
is necessary to work out what the role of those members or parameters is
136
and describe them correctly. Overall, this task gets a little tedious at
137
times, but it's highly important. If we can actually eliminate warnings
138
from the documentation build, then we can start expecting developers to
139
avoid adding new ones.
141
In addition to warnings from the regular documentation build, you can also
142
run ``make refcheckdocs`` to find references to nonexistent documentation
143
files.
145
Languishing kerneldoc comments
146
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
148
Developers are encouraged to write kerneldoc comments for their code, but
149
many of those comments are never pulled into the docs build. That makes
150
this information harder to find and, for example, makes Sphinx unable to
151
generate links to that documentation. Adding ``kernel-doc`` directives to
152
the documentation to bring those comments in can help the community derive
153
the full value of the work that has gone into creating them.
155
The ``scripts/find-unused-docs.sh`` tool can be used to find these
156
overlooked comments.
158
Note that the most value comes from pulling in the documentation for
159
exported functions and data structures. Many subsystems also have
160
kerneldoc comments for internal use; those should not be pulled into the
161
documentation build unless they are placed in a document that is
162
specifically aimed at developers working within the relevant subsystem.
165
Typo fixes
166
~~~~~~~~~~
168
Fixing typographical or formatting errors in the documentation is a quick
169
way to figure out how to create and send patches, and it is a useful
170
service. I am always willing to accept such patches. That said, once you
171
have fixed a few, please consider moving on to more advanced tasks, leaving
172
some typos for the next beginner to address.
174
Please note that some things are *not* typos and should not be "fixed":
176
- Both American and British English spellings are allowed within the
177
kernel documentation. There is no need to fix one by replacing it with
178
the other.
180
- The question of whether a period should be followed by one or two spaces
181
is not to be debated in the context of kernel documentation. Other
182
areas of rational disagreement, such as the "Oxford comma", are also
183
off-topic here.
185
As with any patch to any project, please consider whether your change is
186
really making things better.
188
Ancient documentation
189
~~~~~~~~~~~~~~~~~~~~~
191
Some kernel documentation is current, maintained, and useful. Some
192
documentation is ... not. Dusty, old, and inaccurate documentation can
193
mislead readers and casts doubt on our documentation as a whole. Anything
194
that can be done to address such problems is more than welcome.
196
Whenever you are working with a document, please consider whether it is
197
current, whether it needs updating, or whether it should perhaps be removed
198
altogether. There are a number of warning signs that you can pay attention
199
to here:
201
- References to 2.x kernels
202
- Pointers to SourceForge repositories
203
- Nothing but typo fixes in the history for several years
204
- Discussion of pre-Git workflows
206
The best thing to do, of course, would be to bring the documentation
207
current, adding whatever information is needed. Such work often requires
208
the cooperation of developers familiar with the subsystem in question, of
209
course. Developers are often more than willing to cooperate with people
210
working to improve the documentation when asked nicely, and when their
211
answers are listened to and acted upon.
213
Some documentation is beyond hope; we occasionally find documents that
214
refer to code that was removed from the kernel long ago, for example.
215
There is surprising resistance to removing obsolete documentation, but we
216
should do that anyway. Extra cruft in our documentation helps nobody.
218
In cases where there is perhaps some useful information in a badly outdated
219
document, and you are unable to update it, the best thing to do may be to
220
add a warning at the beginning. The following text is recommended::
222
.. warning ::
223
This document is outdated and in need of attention. Please use
224
this information with caution, and please consider sending patches
225
to update it.
227
That way, at least our long-suffering readers have been warned that the
228
document may lead them astray.
230
Documentation coherency
231
~~~~~~~~~~~~~~~~~~~~~~~
233
The old-timers around here will remember the Linux books that showed up on
234
the shelves in the 1990s. They were simply collections of documentation
235
files scrounged from various locations on the net. The books have (mostly)
236
improved since then, but the kernel's documentation is still mostly built
237
on that model. It is thousands of files, almost each of which was written
238
in isolation from all of the others. We don't have a coherent body of
239
kernel documentation; we have thousands of individual documents.
241
We have been trying to improve the situation through the creation of
242
a set of "books" that group documentation for specific readers. These
243
include:
245
- Documentation/admin-guide/index.rst
246
- Documentation/core-api/index.rst
247
- Documentation/driver-api/index.rst
248
- Documentation/userspace-api/index.rst
250
As well as this book on documentation itself.
252
Moving documents into the appropriate books is an important task and needs
253
to continue. There are a couple of challenges associated with this work,
254
though. Moving documentation files creates short-term pain for the people
255
who work with those files; they are understandably unenthusiastic about
256
such changes. Usually the case can be made to move a document once; we
257
really don't want to keep shifting them around, though.
259
Even when all documents are in the right place, though, we have only
260
managed to turn a big pile into a group of smaller piles. The work of
261
trying to knit all of those documents together into a single whole has not
262
yet begun. If you have bright ideas on how we could proceed on that front,
263
we would be more than happy to hear them.
265
Stylesheet improvements
266
~~~~~~~~~~~~~~~~~~~~~~~
268
With the adoption of Sphinx we have much nicer-looking HTML output than we
269
once did. But it could still use a lot of improvement; Donald Knuth and
270
Edward Tufte would be unimpressed. That requires tweaking our stylesheets
271
to create more typographically sound, accessible, and readable output.
273
Be warned: if you take on this task you are heading into classic bikeshed
274
territory. Expect a lot of opinions and discussion for even relatively
275
obvious changes. That is, alas, the nature of the world we live in.
277
Non-LaTeX PDF build
278
~~~~~~~~~~~~~~~~~~~
280
This is a decidedly nontrivial task for somebody with a lot of time and
281
Python skills. The Sphinx toolchain is relatively small and well
282
contained; it is easy to add to a development system. But building PDF or
283
EPUB output requires installing LaTeX, which is anything but small or well
284
contained. That would be a nice thing to eliminate.
286
The original hope had been to use the rst2pdf tool (https://rst2pdf.org/)
287
for PDF generation, but it turned out to not be up to the task.
288
Development work on rst2pdf seems to have picked up again in recent times,
289
though, which is a hopeful sign. If a suitably motivated developer were to
290
work with that project to make rst2pdf work with the kernel documentation
291
build, the world would be eternally grateful.
293
Write more documentation
294
~~~~~~~~~~~~~~~~~~~~~~~~
296
Naturally, there are massive parts of the kernel that are severely
297
underdocumented. If you have the knowledge to document a specific kernel
298
subsystem and the desire to do so, please do not hesitate to do some
299
writing and contribute the result to the kernel. Untold numbers of kernel
300
developers and users will thank you.
3. 한국어 전문 번역
영어 원문의 문단 순서와 의미를 유지한 전체 번역입니다. 코드, 함수명, symbol과 URL은 원문 표기를 유지합니다.
커널 문서 개선에 기여하는 이유
1-21문서는 모든 소프트웨어 개발 프로젝트의 중요한 일부입니다. 좋은 문서는 새 개발자의 진입을 돕고 기존 개발자가 더 효과적으로 일하게 합니다. 품질 높은 문서가 없으면 코드를 reverse engineering하고 피할 수 있는 실수를 고치는 데 많은 시간이 낭비됩니다.
하지만 현재 커널 문서는 이 규모와 중요성을 가진 프로젝트를 지원하는 데 필요한 수준에 크게 못 미칩니다.
이 가이드는 상황을 개선하려는 기여자를 위한 것입니다. 여러 숙련도의 개발자가 커널 문서를 개선할 수 있으며, 이는 일반적인 커널 절차를 배우고 커뮤니티에서 역할을 찾는 비교적 쉬운 방법입니다. 이어지는 내용 대부분은 문서 maintainer가 가장 시급하다고 보는 작업 목록입니다.
문서 빌드 경고를 근본 원인에서 해결
22-54문서를 바람직한 상태로 만들기 위한 작업은 끝없이 많습니다. 이 목록은 중요한 항목을 담지만 완전하지 않으므로 다른 개선 방법을 발견했다면 주저하지 말고 진행해야 합니다.
현재 문서 빌드는 믿기 어려울 만큼 많은 경고를 출력합니다. 경고가 너무 많으면 모두 무시하게 되어 새 경고를 알아차리지 못하므로, 경고 제거는 문서 TODO 목록의 최우선 과제 중 하나입니다.
C compiler 경고는 false positive로 치부하고 compiler를 조용하게 만드는 패치가 나올 수 있지만, 문서 빌드 경고는 거의 언제나 실제 문제를 가리킵니다. 경고를 없애려면 문제를 이해하고 근본 원인을 고쳐야 합니다.
따라서 문서 경고 수정 패치의 changelog 제목은 단순히 `fix a warning`이라고 쓰기보다 실제로 고친 문제를 밝혀야 합니다.
문서 경고는 C 코드의 kerneldoc comment 문제에서 생기기도 합니다. 문서 maintainer를 참조에 넣는 것은 좋지만, 이런 수정은 보통 문서 tree가 아니라 해당 subsystem maintainer의 tree로 보내야 합니다.
누락된 별표가 만든 kerneldoc 경고
55-84문서 빌드에서 임의로 고른 두 경고는 다음과 같습니다.
./drivers/devfreq/devfreq.c:1818: warning: bad line:
- Resource-managed devfreq_register_notifier()
./drivers/devfreq/devfreq.c:1854: warning: bad line:
- Resource-managed devfreq_unregister_notifier()해당 source file을 살펴보면 다음과 같은 kerneldoc comment가 있습니다.
/**
* devm_devfreq_register_notifier()
- Resource-managed devfreq_register_notifier()
* @dev: The devfreq user device. (parent of devfreq)
* @devfreq: The devfreq object.
* @nb: The notifier block to be unregistered.
* @list: DEVFREQ_TRANSITION_NOTIFIER.
*/문제는 `*`가 빠져 C comment block 모양을 단순하게 판단하는 build system을 혼란시킨 것입니다. 이 문제는 comment가 추가된 2016년부터 4년 동안 남아 있었고 누락된 별표를 추가하면 해결됩니다.
파일 history에서 일반적인 subject 형식을 확인하고 `scripts/get_maintainer.pl`에 패치 경로를 인자로 넘기면 수신자를 찾을 수 있습니다.
실제 수정 패치와 추가 검사
85-144결과 패치는 `PM / devfreq: Fix two malformed kerneldoc comments`라는 제목으로 두 경고와 원인을 설명하고, 누락된 별표 두 개를 추가합니다.
[PATCH] PM / devfreq: Fix two malformed kerneldoc comments
Two kerneldoc comments in devfreq.c fail to adhere to the required format,
resulting in these doc-build warnings:
./drivers/devfreq/devfreq.c:1818: warning: bad line:
- Resource-managed devfreq_register_notifier()
./drivers/devfreq/devfreq.c:1854: warning: bad line:
- Resource-managed devfreq_unregister_notifier()
Add a couple of missing asterisks and make kerneldoc a little happier.
Signed-off-by: Jonathan Corbet <[email protected]>
---
drivers/devfreq/devfreq.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 57f6944d65a6..00c9b80b3d33 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -1814,7 +1814,7 @@ static void devm_devfreq_notifier_release(struct device *dev, void *res)
/**
* devm_devfreq_register_notifier()
- - Resource-managed devfreq_register_notifier()
+ * - Resource-managed devfreq_register_notifier()
* @dev: The devfreq user device. (parent of devfreq)
* @devfreq: The devfreq object.
* @nb: The notifier block to be unregistered.
@@ -1850,7 +1850,7 @@ EXPORT_SYMBOL(devm_devfreq_register_notifier);
/**
* devm_devfreq_unregister_notifier()
- - Resource-managed devfreq_unregister_notifier()
+ * - Resource-managed devfreq_unregister_notifier()
* @dev: The devfreq user device. (parent of devfreq)
* @devfreq: The devfreq object.
* @nb: The notifier block to be unregistered.
--
2.24.1전체 과정은 몇 분밖에 걸리지 않았지만 다른 tree에서 이미 수정되었음을 나중에 발견했습니다. 작업을 시작하기 전에 `linux-next`에서 문제가 이미 고쳐졌는지 항상 확인해야 한다는 교훈입니다.
구조체 멤버나 함수 매개변수의 문서가 없는 경우는 역할을 파악해 정확히 설명해야 하므로 더 오래 걸립니다. 때로 지루하지만 중요한 작업이며, 문서 빌드 경고를 모두 없애야 개발자에게 새 경고를 추가하지 말라고 요구할 수 있습니다.
일반 문서 빌드 경고 외에도 `make refcheckdocs`를 실행하면 존재하지 않는 문서 파일을 가리키는 참조를 찾을 수 있습니다.
빌드에 포함되지 않는 kerneldoc comment
145-164개발자는 코드에 kerneldoc comment를 쓰도록 권장받지만 많은 comment가 문서 빌드에 포함되지 않습니다. 그러면 정보를 찾기 어렵고 Sphinx도 그 문서로 가는 링크를 생성할 수 없습니다.
문서에 `kernel-doc` directive를 추가해 comment를 포함하면 이미 작성된 문서의 가치를 커뮤니티가 온전히 활용할 수 있습니다. 놓친 comment는 `scripts/find-unused-docs.sh`로 찾습니다.
가장 가치 있는 대상은 export된 함수와 data structure입니다. subsystem 내부용 kerneldoc는 해당 subsystem에서 작업하는 개발자를 명확히 대상으로 한 문서가 아니면 일반 문서 빌드에 포함하지 않아야 합니다.
오탈자 수정의 범위
165-187문서의 오탈자나 formatting 오류 수정은 패치를 만들고 보내는 법을 익히는 빠르고 유용한 방법입니다. 몇 개를 고친 뒤에는 다음 입문자를 위해 일부를 남기고 더 고급 작업으로 넘어가는 것도 고려해야 합니다.
다음은 오탈자가 아니므로 고치지 않아야 합니다.
- 커널 문서에서는 미국식과 영국식 영어 철자를 모두 허용하므로 하나를 다른 것으로 바꿀 필요가 없습니다.
- 마침표 뒤 공백을 하나 둘지 둘 둘지, Oxford comma를 쓸지 같은 합리적 논쟁은 커널 문서 패치의 범위 밖입니다.
다른 프로젝트의 패치와 마찬가지로 변경이 실제로 문서를 개선하는지 생각해야 합니다.
오래되고 부정확한 문서 처리
188-229일부 커널 문서는 최신 상태로 유지되며 유용하지만, 낡고 부정확한 문서는 독자를 오도하고 전체 문서의 신뢰를 떨어뜨립니다. 문서를 다룰 때마다 최신인지, 갱신해야 하는지, 완전히 제거해야 하는지 검토해야 합니다.
오래된 문서의 경고 신호는 다음과 같습니다.
- 2.x kernel 참조
- SourceForge repository 링크
- 수년간 history에 오탈자 수정만 존재
- Git 이전 workflow 설명
가장 좋은 방법은 필요한 정보를 추가해 문서를 최신으로 만드는 것입니다. 이는 해당 subsystem을 잘 아는 개발자의 협력이 필요할 수 있으며, 정중히 요청하고 답변을 반영하면 개발자들은 대개 기꺼이 협력합니다.
오래전에 제거된 코드를 가리키는 문서처럼 회복이 불가능한 문서는 저항이 있더라도 제거해야 합니다. 쓸모없는 잔여 문서는 누구에게도 도움이 되지 않습니다.
심하게 오래된 문서에 유용한 정보가 일부 있지만 갱신할 수 없다면 문서 시작 부분에 다음 경고를 추가하는 것이 좋습니다.
.. warning ::
This document is outdated and in need of attention. Please use
this information with caution, and please consider sending patches
to update it.최소한 독자는 문서가 잘못된 방향으로 이끌 수 있음을 미리 알게 됩니다.
개별 문서를 일관된 책으로 묶기
230-2641990년대 Linux 서적은 인터넷 여러 곳에서 모은 문서 파일 모음에 가까웠습니다. 책은 대부분 개선되었지만 커널 문서는 여전히 서로 독립적으로 작성된 수천 개 파일에 기반합니다. 일관된 하나의 커널 문서 집합보다 개별 문서 수천 개에 가깝습니다.
특정 독자별 문서를 묶는 책을 만들어 이 상황을 개선하고 있습니다. 여기에는 다음 색인이 포함됩니다.
- `Documentation/admin-guide/index.rst`
- `Documentation/core-api/index.rst`
- `Documentation/driver-api/index.rst`
- `Documentation/userspace-api/index.rst`
- 문서 작성 자체를 다루는 현재 책
문서를 적절한 책으로 옮기는 작업은 계속해야 하지만 파일 이동은 해당 파일을 다루는 사람에게 단기적인 불편을 줍니다. 문서를 한 번 옮길 근거는 마련할 수 있어도 계속 이리저리 옮겨서는 안 됩니다.
모든 문서가 올바른 위치에 있어도 큰 더미를 작은 더미 여러 개로 바꾼 것뿐입니다. 문서 전체를 하나로 엮는 작업은 아직 시작되지 않았으며 좋은 방법이 있다면 제안을 환영합니다.
stylesheet 개선
265-276Sphinx 도입으로 HTML 출력은 과거보다 훨씬 보기 좋아졌지만 여전히 개선할 부분이 많습니다. 더 나은 typography, 접근성과 가독성을 위해 stylesheet를 조정해야 합니다.
이 작업은 전형적인 bikeshed 논쟁 영역이므로 비교적 명백한 변경에도 많은 의견과 토론을 예상해야 합니다.
LaTeX 없이 PDF 빌드하기
277-292이는 시간과 Python 기술이 많이 필요한 분명히 어려운 작업입니다. Sphinx toolchain은 작고 독립적이라 개발 시스템에 쉽게 추가할 수 있지만 PDF나 EPUB 출력에는 크고 복잡한 LaTeX 설치가 필요합니다. 이 의존성을 없애면 좋습니다.
원래는 PDF 생성에 `rst2pdf` 도구인 `https://rst2pdf.org/`를 사용할 계획이었지만 당시에는 요구를 충족하지 못했습니다. 최근 개발이 다시 활발해진 듯하므로, 동기 있는 개발자가 rst2pdf 프로젝트와 협력해 커널 문서 빌드에 맞춘다면 큰 도움이 됩니다.
더 많은 문서 작성
293-300커널의 많은 부분은 여전히 문서가 심각하게 부족합니다. 특정 subsystem을 문서화할 지식과 의지가 있다면 글을 작성해 커널에 기여해야 합니다. 수많은 커널 개발자와 사용자가 그 결과의 혜택을 받습니다.
요약과 해설
contributing.rst:1-300문서 빌드 경고, 사용되지 않는 kerneldoc, 오래된 문서, 일관성·스타일·PDF와 신규 문서 기여 과제를 설명합니다. 영어 원문 전체와 한국어 전문 번역을 함께 제공하며 명령, source path, commit, patch와 RST directive 및 원문 줄 좌표를 보존합니다.