Received: by 2002:a05:6358:bb9e:b0:b9:5105:a5b4 with SMTP id df30csp829560rwb; Sat, 3 Sep 2022 03:45:00 -0700 (PDT) X-Google-Smtp-Source: AA6agR79DS01pJaKjQ+FYQU2Y52Wl6magcUnMrZQEaSxoxJJp8Xayo5qGWoM1rC05bk5skVblomZ X-Received: by 2002:a65:464a:0:b0:434:883:ea21 with SMTP id k10-20020a65464a000000b004340883ea21mr2380980pgr.152.1662201900486; Sat, 03 Sep 2022 03:45:00 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1662201900; cv=none; d=google.com; s=arc-20160816; b=f24yJcFgTgfx+ShmKcfDxHQ+oWMRNF+ueztIosS1QEtjd8RZR6HFjuQfYtOoUOee4b gno8mOe1wZhFj386bAFs5ITlm6RbC93Fv5MrdLkEl1pHWlM4XGKe1VcNJuxa7iFzalOK 8zavhTtRJFZ+Fp5kMT/sx1UlmzYjRhkTccTGqLt8al2wjdMowF2B4n6yMVO+K341tZGG AkRMmB+i+XVE+l6V5ovSFHzWdvPHFsEixu/3fRDi6zSiA7nK/BxK6oeT77RvwB52dadx lEuIuGjN5K8+AxiX05ABJN8xI0ntQj8umLsjmt8RDudBCIRj0aKijRCzZ9Vt/egJ4vbM Tvmg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id; bh=ZPKqHkts6t8hjynRDf0j3IYclN/K3uOdq5vXQ1PU5Qc=; b=nyyk+b7+SbaloYAtiff5IU/I9R4PWcbkNbVktQo5lKd2ySGvpBXHaxn34HzKJro+2v Ub1nMH9hIcBAgiTWPBc72YQrQW4gHfTLE4QacT2m+JIx7yxMT1oFMFEEfPhDTXMjciE6 ugv9smMregPVovlDWR6fEWGpxSeoiyBCbovIRVlJd22/toqQSBwrBVQCGLgI5P+2Aut9 fsy5sjfep2b0KvgrkRSDPbF0+GcIQ5wtcX+t8o16B5AAV+vB77KgbpS5FC2gMPU1O5d8 CAFgAxW/I1DrUP6D/vSQAYRtw4obwjscgTNAPoZ5T9fc/UArAYA3pWmSRUEfvG5/idPY pAYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id d25-20020a656219000000b0042c70745e9asi4425058pgv.14.2022.09.03.03.44.45; Sat, 03 Sep 2022 03:45:00 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230242AbiICKDX (ORCPT + 99 others); Sat, 3 Sep 2022 06:03:23 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49704 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229506AbiICKDV (ORCPT ); Sat, 3 Sep 2022 06:03:21 -0400 Received: from wp530.webpack.hosteurope.de (wp530.webpack.hosteurope.de [IPv6:2a01:488:42:1000:50ed:8234::]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 1F19C67440; Sat, 3 Sep 2022 03:03:20 -0700 (PDT) Received: from [2a02:8108:963f:de38:eca4:7d19:f9a2:22c5]; authenticated by wp530.webpack.hosteurope.de running ExIM with esmtpsa (TLS1.3:ECDHE_RSA_AES_128_GCM_SHA256:128) id 1oUPzh-0008Fe-LK; Sat, 03 Sep 2022 12:03:17 +0200 Message-ID: <938a9905-217c-f02a-b5c2-35c1e5d7822b@leemhuis.info> Date: Sat, 3 Sep 2022 12:03:17 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.2.0 Subject: Re: [PATCH 0/4] Rewrite the top-level index.rst Content-Language: en-US, de-DE To: Jonathan Corbet , linux-doc@vger.kernel.org Cc: linux-kernel@vger.kernel.org References: <20220901231632.518583-1-corbet@lwn.net> From: Thorsten Leemhuis In-Reply-To: <20220901231632.518583-1-corbet@lwn.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-bounce-key: webpack.hosteurope.de;linux@leemhuis.info;1662199400;abdd4c00; X-HE-SMSGID: 1oUPzh-0008Fe-LK X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,NICE_REPLY_A, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02.09.22 01:16, Jonathan Corbet wrote: > The top-level index.rst file is the entry point for the kernel's > documentation, especially for readers of the HTML output. It is currently > a mess containing everything we thought to throw in there. Firefox says it > would require 26 pages of paper to print it. That is not a user-friendly > introduction. < > This series aims to improve our documentation entry point with a focus on > rewriting index.rst. The result is, IMO, simpler and more approachable. > For anybody who wants to see the rendered results without building the > docs, have a look at: > > https://static.lwn.net/kerneldoc/ > [...] Great initiative. But looking at the rendered result made me wonder: what overall structure for the docs are you aiming for in the end? I'm sure you have a picture in your head, but I failed to grasp it, as for me a few things looked a little odd: * we do all of this for the users, so shouldn't the section aimed at users be at the top? And list more things they will look for? * What is so important about "Architecture-agnostic documentation" and "Architecture-specific documentation" (both with just one entry) that they have to be listed here? Same for "Firmware-related documentation". And is the User-oriented section really the right place for the kbuild stuff, as from a quite look it seems most of those aim at developers and not at users? * Quite a few things I'd had expected on that front page aren't listed there. Sure, everybody has different expectations on what's important, but I for example hat expected "command-line parameters" or "Reporting issues" (here I'm obviously biased) to be somewhere on that page. This made me think: should that main index page maybe just have these three sections (apart from Translations) ? * User-oriented documentation * Application-developer documentation * Other documentation on the Linux kernel and its development I'd say that makes it quite clear where readers need to go from there, even if the name of the third section is a bit vague (but in contrast it becomes clear I'd say). Each section could list its five to ten most important documents before linking to a separate index file with more. And that index file for will need subcategories, too, otherwise it will become large, too. And sure, quite a few documents will be hard to categorize currently. Making things fit properly might take a decade or two (unless somebody hires a few people to bring order into this). But it would set a clear direction. It also would tell doc writers what tone and detail level to use when writing their texts, as that depends on the audience which becomes clearer this way. Ciao, Thorsten P.S.: /me wonders if Jonathan posted this patch-set as a bait and will force everyone replying to come to his LPC/kernel summit session "What kernel documentation could be" /me despite this replied, as he had planned to go anyway