git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
To: Senol Yazici <sypsilon@googlemail.com>
Cc: Junio C Hamano <gitster@pobox.com>,
	"Randall S. Becker" <rsbecker@nexbridge.com>,
	git@vger.kernel.org, msuchanek@suse.de,
	Johannes.Schindelin@gmx.de, jpyeron@pdinc.us
Subject: Re: [RFE] Demilitarize Documentation (was RE: Delivery Status Notification (Failure))
Date: Tue, 19 Feb 2019 12:19:51 +0100	[thread overview]
Message-ID: <87o97858ko.fsf@evledraar.gmail.com> (raw)
In-Reply-To: <CAFacdQ_9=2hbC8-5+N=RdrGs=Anu2ku+TAj7x07OQNpa1b+gcg@mail.gmail.com>


On Tue, Feb 19 2019, Senol Yazici wrote:

> Thank you for the quick response and apologize my late reply (good
> morning from Europe).
>
> I understand that well "established" concepts might make it easier
> grasping concepts.
>
> My concerns towards using these particular expressions
> (dictator/lieutenant/blessed) are nevertheless motivated.
>
> 1. Dictator
> Concern: "Bad" connotation.
>
> I agree, dictator is not military, but it is not "not military at
> all", see https://www.merriam-webster.com/dictionary/dictator.
> Except of case 1 a (and 2, which is not applicable in this context),
> cases b and c are related to either "autocrat" or "fascist dictator".
> Both of these historical "figures" majorities abused their military
> power to "rule" in an oppresive way.
> Further, "googling" dictator does not give Linus as a result in (at
> least my) search (bubble).
> It gives the well known bad examples of dictators usually having
> abused or are abusing their powers in an oppressive/tyrannical way.
>
> Suggestion for substitution: Principal or principal integrator.
>
> 2. Lieutenant (somehow I manage to misspell this word most of the times)
> Concern: Strong relation to military.
>
> I also agree here, lieutenant is not military, again see
> https://www.merriam-webster.com/dictionary/principal.
> The connotation here is also not as negative as it is with dictator.
> However, googling lieutenant results in mostly military figures.
>
> Suggestion for substitution: Assistant or assistant integrator.
>
> 3. Blessed repository
> Concern: Rather exclusive than inclusive.
>
> I agree, blessed is not a bad phrasing. But if one is not
> attached/related to a religion in some way, one somehow feels left
> out.
> It is creating some troubles explaining this to the "curious young
> mind" (i.e. children) without having to mention religion at some point
> of the explanation.
> Why should one need to go there in a discussion of how "big projects"
> are dealt with?
> Of course, one could say "it is another word for approved" and neglect
> the origin of the word.
> What would then be left as a motivation to use this word at all, and
> not use approved?
>
> The more I try to understand what "blessed" in a context of a
> repository wants to tell me about it's current state, the less I am
> understanding.
>
> I think the state of the repository is something like "Approved by
> principal integrator" or "Principal integrator (PI) approved", thus...
>
> Suggestion for substitution: PI-Approved repository
>
> Words have their weight.
> In times where the entire world is accessible by the "click of a
> finger" it is becoming more and more important to be inclusive.
> Further, in a world where hundred of millions live in conditions ruled
> by dictators or military regimes _I_ care more about acceptable than
> "descriptive".
>
> I am not sure if someone in a "warlike" situation will feel "included"
> finding these expressions when it is about software development
> projects!
>
> Again thanks for your attention and participation in the discussion.

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. Specifically:

 * "blessed" is introduced in quotes and used twice. I think it would be
   clearer to use "canonical" for what it's describing.

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

  parent reply	other threads:[~2019-02-19 11:19 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-18 16:51 [RFE] Demilitarize Documentation (was RE: Delivery Status Notification (Failure)) Randall S. Becker
2019-02-18 17:26 ` Michal Suchánek
2019-02-18 18:39 ` Junio C Hamano
2019-02-19  8:02   ` Senol Yazici
2019-02-19  9:39     ` Michal Suchánek
2019-02-19 14:47       ` Johannes Schindelin
2019-02-19 16:28         ` Michal Suchánek
2019-02-19 10:01     ` SZEDER Gábor
2019-02-19 11:00       ` Senol Yazici
2019-02-19 14:58       ` Johannes Schindelin
2019-02-19 16:20         ` Michal Suchánek
2019-02-20 19:54           ` Johannes Schindelin
2019-02-19 20:16         ` Philip Oakley
2019-02-20 11:17         ` SZEDER Gábor
2019-02-19 11:19     ` Ævar Arnfjörð Bjarmason [this message]
2019-02-19 13:33       ` Michal Suchánek
2019-02-19 13:52       ` Christian Couder
2019-02-19 13:58         ` Michal Suchánek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87o97858ko.fsf@evledraar.gmail.com \
    --to=avarab@gmail.com \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=jpyeron@pdinc.us \
    --cc=msuchanek@suse.de \
    --cc=rsbecker@nexbridge.com \
    --cc=sypsilon@googlemail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).