Re: on the irresponsibility of pursuing C language reform

--52lanksjzzli43hd
Content-Type: text/plain; protected-headers=v1; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Subject: Re: on the irresponsibility of pursuing C language reform
MIME-Version: 1.0

Hi Alex,

At 2026-08-01T19:09:36+0200, Alejandro Colomar wrote:
> Well, Keith Bostic wouldn't have suggested that I do this change, and
> Branden wouldn't be defending that it might make sense to make this
> change.

I'm flattered to be mentioned in the same breath as Keith Bostic!

> A vocal majority is not consensus.  Consensus would be if there were
> no significantly different or strongly opposed opinions to those of
> the majority.  Even my strong and sustained opposition against your
> opinion already means there's no consensus against.

"Consensus" is a word that gets abused a lot, because it has multiple
definitions.  To some people it means "unanimity".  To others, it means
a majority vote with potentially many abstentions but no (or
proportionally very few) negative votes.  From reading WG14 minutes, I'm
vaguely aware that it has a rubric for reading the straw polls they take
when voting on N-papers and related motions.[1]  I invite a member to
cite a resource laying out their actual procedures.

I don't think I'm voicing a controversial view when I venture that
Michael Kerrisk administered the Linux man-pages with a more settled
view of the APIs it documents.  By that, I mean that he tended to update
its content with a retrospective view of matters that were no longer in
contention.  If some controversy brewed, he tended to omit it from
"coverage" in the documentary corpus until the contention resolved.

Your approach is a little different: you're more ready to give the
reader a view of live controversies and unsettled matters troubling the
C community where these intersect with the topics man-pages(7) covers.

Neither approach is better.  They're just different.  I think Sam is
right that people had many years to get used to Michael's approach.
=46rom there it's a short--but logically unsound--step to associate
"familiar" with "better".

But, if you're going to document unresolved controversies, how do you
avoid putting a thumb on the scale?

One way is to solicit review of that coverage for even-handedness--I
do not say "neutrality".  List pros and cons of competing interfaces or
code idioms.  If you do that job correctly, _reasonable_ partisans of
the various contesting positions will find no cause to criticize.
(There will sometimes be fanboys who object to the "opposition" getting
any coverage at all.)

Further, with such lists you do a service to the engineer who must
select a means of solving the problem confronting them.  The engineer
often knows that problem better than anyone else does.

Next comes a trickier bit: what if you yourself get involved, even while
"wearing a different hat", in one of these live controversies?

Your first line of defense is your own ethical conscience.

Another, as I suggested earlier, is to solicit one or more volunteers to
serve as "deputy maintainers".  Prepare a list of man pages or sections
thereof upon which you are "conflicted out", and ask the deputies to
field all Linux man-pages business regarding those pages/sections while
you have business regarding those interfaces before a vendor libc and/or
the WG14 committee.  It will likely be obvious to you what vehicle can
communicate these areas of deputy maintenance--a man page!

I intuit that Michael had a hard time finding anyone to take the mantle
of Linux man-pages maintainership.  It's a huge job and demanded someone
of your unusual resources and energy.  By opening deputy positions that
are limited both in scope and in time, nobody need worry that they'll be
expected to eat the whole elephant.  If you find such volunteers, then
you'll also be spreading expertise and socializing personal investment
in the success of this project.  That's good management!

Finally, to return to the question of consensus: a potential point of
development in Linux man-pages project governance is to _document how
you measure consensus_.

We'd be unwise to determine consensus by measuring who writes the most
words (hi, folks), or with the angriest tone, or who has the most
impressive job title at the biggest company, or who can shut down a
discussion most coldly or derail it most effectively.

So tell the members of this community how _you_ measure it.  Put the
burden on the critical and the concerned to find flaws in your method.

Regards,
Branden

[1]  I'm not sure WG14 uses the term "motions", and I haven't seen much
     evidence that they use Robert's Rules of Order, with which
     Commonwealth people are likely not familiar, let alone
     non-Anglophones.

--52lanksjzzli43hd
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEEh3PWHWjjDgcrENwa0Z6cfXEmbc4FAmpuZlUACgkQ0Z6cfXEm
bc4K3w//Tj3bJlwxaH8XPPDskyQzipFgUPqhdbWBI3aN2LXHXGhEfwV2J5rXB6Eo
oeOQrBvtf9mKrrfrUzyNShUCUsm4Q4VoU2/7w2cZjWcekv09A9iT44GOw1ornWiD
IKeFuUxXmFblT//nnwS0cLdvo1bq+VKShLNk8LHMSTKOqKWGk9NDtQDY7bVmY9gc
ZkK6LfDObs4xHvqH5wn7rVRjRJfMJLzJVR0OgwcOjHvxlxyZfsyV4WVAhBUlrT9B
1o+c6xqYT59qWbaL62mDmnvQzVwSyWPJxfXlTXuskCcEKW8JrIZCMIdlEMp6GkSJ
scWgL+yHUAge2U6oo+yhjNmKM/Ry7xWUSs3HSCw8qsRdkqxyECZNqBDJMgKoVu5d
1JDFMjrR617E0kCpR5wiCXSgzyvmmH0jwW9ZoZjh+IVTbQ129kz0N722UuKxZcZc
EyhAGKvSayixwZwea9GS/qBtoA0CF6C5OiSQCk1z41lStQybVOIRIxWnwiR13Qnt
vOALZrSScykHjUVMOftM0qQ+PpLSyc2jZx5kq2PtsCOiTmc8fMXZj2QnHCsf4k93
I47w4fwloNpd/OFWlsSksPbTA4TjhswCY6KFVP5a92FkA354pkF8TbJwaK4lWeFu
lPLHnS2sHSPmnMQ9OpvDFfrvTEBIpMGmpCugQ+265sI72WujiBc=
=4cu0
-----END PGP SIGNATURE-----

--52lanksjzzli43hd--