From: Shuah Khan <skhan@linuxfoundation.org>
To: Mauro Carvalho Chehab <mchehab+samsung@kernel.org>
Cc: ksummit-discuss@lists.linuxfoundation.org
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Documentation
Date: Fri, 14 Jun 2019 15:40:26 -0600 [thread overview]
Message-ID: <b5af03d3-2286-32e9-f895-776b563df550@linuxfoundation.org> (raw)
In-Reply-To: <20190613112533.2176c5d4@coco.lan>
On 6/13/19 8:25 AM, Mauro Carvalho Chehab wrote:
> Em Wed, 12 Jun 2019 12:22:55 -0600
> Shuah Khan <skhan@linuxfoundation.org> escreveu:
>
>> On 6/12/19 8:54 AM, Jonathan Corbet wrote:
>>> What could be more fun than talking about kernel documentation? Things we
>>> could get into:
>>>
>>> - The state of the RST transition, what remains to be done, whether it's
>>> all just useless churn that makes the documentation worse, etc.
>>>
>>> - Things we'd like to improve in the documentation toolchain.
>>>
>>> - Overall organization of Documentation/ and moving docs when the need
>>> arises. It seems I end up fighting about this more than just about
>>> anything else, but I think it's important to organize our docs for the
>>> convenience of the people using them.
>>>
>>> - The ultimate vision for kernel docs (for now). RST conversion and
>>> imposing some organization are important, but they will not,
>>> themselves, give us a coherent set of documentation. What can we do to
>>> have documentation that is useful, current, and maintainable, rather
>>> than the dusty attic we have now?
>>>
>>
>> The first step is identifying the ones that are out of date and/or
>> incorrect. I think this is probably the most time consuming part
>> and the second is start updating.
>
> I would do just the opposite: convert the documentation, then
> update it.
>
Yes. That is fine. I am referring to the outdated part. Converting
and updating them would work just fine.
> The reason is that, when someone sends a patch to the documentation,
> people tend to look more closely on it, and we start receiving
> updates for it.
>
> Ok, this doesn't happen every time, but it is still worth.
>
> There's another thing to consider here: there are lots of docs
> written for "stable" subsystems, in the sense that the documented
> code doesn't change for a lot of time (except for trivial patches
> not directly related to it.
>
> While doing large chunks of code conversion, I noticed that there
> are lots of still valid documents that fit on this.
>
> There's a big issue with those "stable" subsystems: they tend
> to not have any active maintainer anymore. So, there are not
> much people that are willing to actively review patches to it.
>
> So, my advice here is to really invert things:
>
> - do the conversion;
Even this can be made into tasks. If you would like to experiment
with and see how it works, send me a list of documents that you
would like to see converted first.
> - find a good place to put the converted the book;
> - add kernel-doc markups to be sure that the symbols will always
> match upstream;
> - review the remaining content of the docs.
>
>> I am currently putting together a task list for mentorship program
>> with a goal to create tasks that would more meaningful and helpful
>> instead of whitespace patches.
>>
>> I will gladly add documentation tasks to the list to help improve
>> the documentation.
>
> I can surely mentor people interested on doing such tasks.
>
That will be great.
thanks,
-- Shuah
next prev parent reply other threads:[~2019-06-14 21:40 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-12 14:54 [Ksummit-discuss] [TECH TOPIC] Documentation Jonathan Corbet
2019-06-12 18:22 ` Shuah Khan
2019-06-12 19:12 ` Martin K. Petersen
2019-06-12 19:43 ` Shuah Khan
2019-06-13 14:25 ` Mauro Carvalho Chehab
2019-06-14 21:40 ` Shuah Khan [this message]
2019-06-15 0:05 ` Mauro Carvalho Chehab
2019-06-17 10:12 ` Mauro Carvalho Chehab
2019-06-17 17:21 ` Mauro Carvalho Chehab
2019-06-17 18:05 ` [Ksummit-discuss] [PATCH RFC] scripts: add a script to handle Documentation/features Mauro Carvalho Chehab
2019-06-17 18:11 ` Greg Kroah-Hartman
2019-06-17 19:45 ` Mauro Carvalho Chehab
2019-06-12 20:33 ` [Ksummit-discuss] [TECH TOPIC] Documentation Kate Stewart
2019-06-13 14:17 ` Mauro Carvalho Chehab
2019-06-13 14:57 ` Mauro Carvalho Chehab
2019-06-13 18:48 ` Greg KH
2019-06-13 19:01 ` Mauro Carvalho Chehab
2019-06-20 18:36 ` Kees Cook
2019-06-20 19:28 ` Jonathan Corbet
2019-07-22 14:52 ` Mauro Carvalho Chehab
2020-06-09 20:53 Jonathan Corbet
2020-06-10 8:49 ` Dan Carpenter
2020-06-11 8:21 ` Daniel Vetter
2020-06-11 14:48 ` Linus Walleij
2020-06-11 18:03 ` Shuah Khan
2020-06-11 18:28 ` Joe Perches
2020-06-11 19:44 ` Shuah Khan
2020-06-12 8:18 ` Laurent Pinchart
2020-06-12 9:19 ` Mike Rapoport
2020-06-12 10:58 ` Mark Brown
2020-06-12 15:48 ` Shuah Khan
2020-06-12 9:07 ` Mike Rapoport
2020-06-12 16:08 ` Shuah Khan
2020-06-13 16:42 ` Julia Lawall
2020-06-13 16:51 ` Joe Perches
2020-06-13 17:04 ` Julia Lawall
2020-06-14 13:23 ` Matthew Wilcox
2020-06-14 14:13 ` Mike Rapoport
2020-06-15 9:46 ` Jani Nikula
2020-06-18 9:04 ` Mike Rapoport
2020-06-18 14:40 ` Joe Perches
[not found] ` <20200709122118.0ffaea91@coco.lan>
2020-07-09 11:42 ` Joe Perches
2020-07-09 12:11 ` Mike Rapoport
2020-07-09 16:59 ` Joe Perches
2020-07-09 17:29 ` Mike Rapoport
2020-07-09 17:57 ` Andrew Lunn
[not found] ` <104986.1594328429@turing-police>
2020-07-10 0:03 ` Joe Perches
2020-06-13 17:05 ` Laurent Pinchart
2020-06-18 9:08 ` Mike Rapoport
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=b5af03d3-2286-32e9-f895-776b563df550@linuxfoundation.org \
--to=skhan@linuxfoundation.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=mchehab+samsung@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).