On Thu, Jun 17 2021, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes: > >> - Discussing command-line options, and program functionality: >> >> Prefer succinctness and matter-of-factly describing functionality in >> the abstract. E.g. >> >> --short:: Emit output in the short-format. >> >> Avoid more verbose constructions, such as: >> >> --short:: Use this to emit output in the short-format. >> --short:: You can use this to get output in the short-format. >> --short:: A user who prefers shorter output could.... >> --short:: Should a person and/or program want shorter output, he >> she/they/it can... > > This applies the most broadly and addresses common readability > issues, which is why I like this part the most. *nod* >> - Addressing the reader: >> - Discussing Git, "the command" etc.: > > I am not sure if these are even worth saying, especially when we do > not explain why we recommend to do so. Maybe not, I tried to just grep around / search in my memory for how we talk about this, to cover that base. I.e. when we talk about "you", then other commands (this part), permissions, remote users etc... >> - Discussing other users: >> >> When referring to other users on the same system prefer talking >> about "a user" or "another user". There's usually no reason to >> invent a cast of characters with names, titles and hobbies. >> >> Your OS's users don't cleanly map onto any particular people, a user >> of git might be having a merge conflict with another person, or an >> automated commit from a cron daemon. >> >> We prefer the style typical of standard library adn system tooling >> documentation in this and most other cases, you can look at the >> documentation of chmod(2) and other commands, syscalls and libraries >> that deal with UIDs or GIDs for examples. > > I cannot exactly put my fingers on where this feeling comes from, > but this part appears to spend many lines to tell me very little. > > For example, it is unclear why the second paragraph is there at all. > Sure, some commits may be created by a non people, but how does that > fact affect how I write the documentation? Writing about such an > activity by non people, what are our recommendations? The third > paragraph does not do much better. Unless you have UNIX man pages > handy, chmod(2) may not be very easily accessible. It feels as if > it wants to encourage descriptions without human actors, without > doing a very good job at explaining to readers why the guideline > does not want to see them in our documentation. The real problem here is that a clearly overly verbose person is trying to write guidelines about how to be less verbose :) Yes, that can probably go entirely. > Unlike chmod(2) and getpwnam(3), but more like any dSCM, Git is a > tool to help inter-person communication, and at some point we will > have to talk about contributors asking their upstreams to pull their > work from their repositories. It won't be like system calls dealing > with pure numbers. We do not have to give them names like Alice and > Bob, but we do have to refer to repositories of these cast of > characters individually to clearly explain/describe how data flow > among them. I'd think that the *nix permission model in general and FS-like permission models (including pseudo-implementations thereof, such as Google Docs sharing etc.) in general are a much bigger helper of inter-persion communication than Git is. Which is what I was trying to aim for, the documentation for such systems can usually talk about the permission models and "foreign" data in matter of fact terms. E.g. we really don't need to drag up an example of another person on the system to explain core.sharedRepository to you, or more generally why you get a permission error when you "cat" something on a *nix system. But yes, could be improved etc.; does anyone have a better suggestion? I think whatever I come up with at this point is probably much better copyedited by others. >> - Discussing other systems: >> >> As with discussing other users, git might interact with other >> systems over the network. In these cases we also avoid a cast of >> characters, preferring to talk about concepts like "fetching data >> from a remote", having a conflict with "diverging histories" etc. > > Unlike the above "other users", I have littleproblem with this part. > It however feels funny to warn against use of "cast of characters", > when the first sentence talks about "with other systems", which are > clearly not people. Even when you are "fetching from a remote", you > are getting the result of work by "other people", so I would not > have separated "other users" and "other systems" in separate > sections. What I was trying to go for here is that we could say you do a fetch, get a divergent branch, and a conflict, and then proceed from there. It's just a distraction in such examples to set up a scenario where J. Doe is the author of those commits, you can't reach them at the office right now (maybe they're at lunch), but you need to resolve the conflict yourself etc... >> The references to "gendered prounouns" etc. are gone, perhaps there's a >> good reason to re-include them, but the point of "isn't that issue >> solved by recommending an orthagonal approach?" is one of the many >> things Stolee hasn't been addressing in the threads related to this >> series. >> >> To me that whole approach is somewhere between a solution in search of a >> problem and a "let's fix it and move on". Not something we need >> explicitly carry in our CodingGuidelines forever. > > This I think is the crux of the differences between you two. I'd > love to hear Derrick's response and eventually see a middle ground > reached. Covered downthread.
