From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by finch.gentoo.org (Postfix) with ESMTPS id 267E51581D8 for ; Wed, 4 Dec 2024 02:20:15 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id CCDEEE086F; Wed, 4 Dec 2024 02:20:07 +0000 (UTC) Received: from smarthost01a.ixn.mail.zen.net.uk (smarthost01a.ixn.mail.zen.net.uk [212.23.1.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (prime256v1) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 713FDE0827 for ; Wed, 4 Dec 2024 02:20:06 +0000 (UTC) Received: from [82.69.80.10] (helo=cube.localnet) by smarthost01a.ixn.mail.zen.net.uk with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.95) (envelope-from ) id 1tIezh-00BlNd-RK for gentoo-user@lists.gentoo.org; Wed, 04 Dec 2024 02:20:04 +0000 From: Peter Humphrey To: gentoo-user@lists.gentoo.org Subject: Re: [gentoo-user] NFS mounting - SOLVED Date: Wed, 04 Dec 2024 02:20:04 +0000 Message-ID: <23760181.6Emhk5qWAg@cube> In-Reply-To: <10600509.nUPlyArG6x@cube> References: <1910258.tdWV9SEqCh@cube> <2C7EA66F-D443-4235-AEC1-79FB71498069@gentoo.org> <10600509.nUPlyArG6x@cube> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org X-Auto-Response-Suppress: DR, RN, NRN, OOF, AutoReply MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" X-Originating-smarthost01a-IP: [82.69.80.10] Feedback-ID: 82.69.80.10 X-Archives-Salt: 56f1f6f6-a2b7-4659-9e4f-207531c4b082 X-Archives-Hash: ef32399a3b4fb25e9fbbf56e6e738a92 On Tuesday 3 December 2024 13:28:44 Greenwich Mean Time I wrote: > On Tuesday 3 December 2024 13:08:51 Greenwich Mean Time Matt Jolly wrote: > > Hi Peter, > >=20 > > On 27 November 2024 2:13:01=E2=80=AFam AEST, Peter Humphrey > > > wrote: > > >Someone needs to have a look at the nfs-utils wiki page. I'd do someth= ing > > >myself, but how? I raised a bug against a document once, only to be > > >rebuked. > >=20 > > You can raise issues on the "Talk" page for a given article, e.g. > > https://wiki.gentoo.org/wiki/Talk:Nfs-utils > >=20 > > Ideally, since it's a wiki, if you know how to fix it you can edit the > > page > > directly. Don't be afraid, other editors will help polish your > > contribution > > if it's a little rough around the edges as long as it's complete. > >=20 > > Trying this from Thunderbird mobile. Hopefully it doesn't mangle the > > reply! >=20 > That's a real help; thank you Matt. I've made a suggestion about the nfs-utils page, but I've also been thinkin= g=20 about Gentoo wiki documents generally, because I find them unsatisfactory: = not=20 their content, but the style of presentation. I was documentation manager o= n a=20 200-man-year software project years ago (supplier side), so I think I know= =20 what I'm talking about [1]. One problem is the apparent absence of structure in the body of the documen= t.=20 A table of contents appears at the top, complete with numbered sections and= =20 subsections in a clear hierarchy, but those numbers appear nowhere else. Th= e=20 complexity of most of these documents is such that, once deep into the text= ,=20 the relationship with the rest of it is invisible. This sounds academic, bu= t=20 it's real; reliance on font sizes to distinguish headings is not enough on = its=20 own. An immediate improvement would result from including the numbers from = the=20 contents list. I imagine it would be comparatively easy to do, as well. Secondly, the big advantage of viewing on a screen has largely been discard= ed=20 =2D colour. There are pale coloured backgrounds in some highlights, but I w= onder=20 whether more could be achieved. I dimly remember the adoption of the presen= t=20 style (when was that?), following a 'paper' scheme. (I think that name's=20 right.) A consistent style is essential, of course, but why go backwards to= an=20 earlier technology? Thirdly, showing terminal commands on a huge black background is much too=20 disruptive, visually. They're so overpowering that things like headings=20 disappear. I find, especially now my vision is deteriorating, that the=20 interleaving of main and secondary topics is often baffling: for instance, = the=20 choice between openrc and systemd with other alternative streams. Not enough thought has been given to the combined effect, which is to make = the=20 documents hard to read and understand. What does the team think can be done about it? 1. The fact that the project was cancelled when it became clear that the f= irst=20 50% of the work had taken the first 80% of the time, and the second 50% wou= ld=20 take the other 80% of the time, had nothing to do with the documents. :_) =2D-=20 Regards, Peter.