Æ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. > - 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. > - 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. 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. > - 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. > 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.
