Re: [RFE] Demilitarize Documentation (was RE: Delivery Status Notification (Failure))

>
> Two things:
>
>  1) Whatever anyone's abstract position on the wording of our
>     documentation, either the one stored in git.git or at
>     https://github.com/git/git-scm.com there's only so much a
>     theoretical discussion like this can get us.
>
>     If you're willing to pursue this further I think it's best if that's
>     done in the form of patches to either repositories, either sent here
>     on-list (see Documentation/SubmittingPatches) or as a PR to
>     https://github.com/git/git-scm.com

>  2) Any piece of software or technical tool is going to unavoidably need
>     to use some amount of jargon, or words that are lifted from a more
>     general vocabulary and intended to be understood in context.
>
>     Thus, when we talk about e.g. "trees" in git, it's understood that
>     we're talking about something in the context of this software
>     project, trying to go by the first Google result of "tree" isn't
>     going to get you anywhere.
>
> I for one thing those git-scm docs could be changed to eliminate those
> words for reasons entirely unrelated to them somehow being religious or
> militaristic.

>  * The docs already use "integration manager" and then introduce
>    "dictator" as a synonym in the context of explaining the workflow of
>    the kernel.
>
>    They could instead use "main integrator" or something, since the
>    point of the example is to explain how git can be used to manage
>    distributed repositories that are integrated in a hierarchical
>    manner.

>    Making assumptions about how much power the "main integrator" has to
>    approve/reject changes is irrelevant to that explanation.
>
>    E.g. the kernel could also decide to make the "main integrator" some
>    purely automated process that always approves changes from
>    lieutenants and the hierarchical example would be just as true.