There is heightened sensitivity to the naming of things, the meaning behind
them and the meaning read into them. I applaud the Jenkins community work
to address these matters. I first encountered the master / slave
terminology when I first tried to configure an IDE drive on a IBM PC clone.
Then the context was "Master Controller" and "Slave Controller". Perhaps my
youthful naiveté did not associate the full qualified terms with racial
imagery to which the lone words are ascribed. When I first saw the plain
"Master / Slave" usage in Jenkins, I definitely made that negative
association. If there exists more neutral terminology, I am all for it.
The same goes for BlackList / WhiteList. Absolutely support the AllowList /
DenyList pairing in its place.
The transition to node/agent works well, and it is the executors that do
the work.
So, what for "the master" ? Some disliked Orchestrator, Controller, Host,
Server, all for legitimate reasons.
I see "the master" as having two contexts. There is the Administrative
context (configuration, plugins etc.), that determine focus, capability,
delegation. Then there's the context of those tasks that are necessary to
execute "on the master".
An elegant parallel for the first would be "Executive". That's our Org's
(or Jenkins') " Leadership" capability. That's how it works in my Org, with
an Executive (at HQ), multiple satellite offices (Nodes/Agents) and then
the workers (executors).
What about the tasks run on master? It's still executors doing the work,
but its sounds like the job for a "Concierge" to coordinate and satisfy the
needs of the clients and delegate as necessary. Our Org has a "Concierge"
that functions similar to a Concierge at a hotel that most people would be
familiar with, but in an office setting
My recommendation: refer to the "Host/Server" context as the "Executive",
replace
the "master" usage context with "Concierge".
The terms and roles are well defined, should translate reasonably well or
are understood as-is, have neutral connotations and are not used in other
tools in the CI space that I am aware of.
Ian
On Thursday, 25 June 2020 15:36:05 UTC-7, Jeff Thompson wrote:
>
> "maestro" is problematic in our context because it's too similar to the
> word we're trying to replace. Because of our usage history, that's a bigger
> issue than it might be in other contexts. In English, though they may have
> nuanced common usages, they're both basically the same word. They just got
> to modern English via different paths. They both derive from the same Latin
> root. We would be better to select something noticeably different.
>
> We should definitely keep i18n in mind in choosing a name.
>
> Jeff
> On 6/24/20 4:49 PM, Thomas de Grenier de Latour wrote:
>
> As a native French speaker too, I fear that "conductor" would be difficult
> to translate in French. With its "musical director" meaning, it would be
> "chef d'orchestre", which is so explicit that it leaves little room for a
> figurative sense (and it's also really long). The word "conducteur" exists
> in French, but not with this meaning (it's either an electrical wire, or a
> car driver; none of which being a good analogy for the work Jenkins does).
>
> To stay in the same lexical field, I would rather go with "maestro" (a
> skilled / well-known conductor), because this word would be understood
> as-is at least by Italian (obviously), English, French, and Spanish
> speakers (maybe German speakers too, maybe others). Plus, for people used
> to the historical Jenkins terminology, it gives an etymological hint that
> it is indeed the new word for "master", and not a new/different concept.
>
> Now, that being said, you can't go wrong with "controller" I think, so it
> would have my preference too. I don't think the potential confusion with
> k8s controllers is an issue (when writing about Jenkins deployment on K8S,
> use "K8S controller" / "Jenkins controller" to avoid any ambiguity). The
> word is so widely used in IT that we can assume most languages already have
> a well established translation for it. In French, it's "contrôleur" (fun
> fact: the most common meaning for "contrôleur", outside of the IT field, is
> "bus/train conductor").
>
> Anyway, I guess my point here is that picking the new terminology should
> be done with i18n in mind. Maybe double-check with active i18n contributors
> for the most spoken languages that they have no issue with the candidate
> words, or something like that.
>
> Thomas.
>
> Le 15/06/2020 à 17:03, Angélique Jard a écrit :
>
> My preference goes to "controller", "server" make me think somehow to the
> hardware physical machine. "Coordinator" is fine also (in the link
> tools.ietf in previous post) but a bit hard to pronounce.
>
> As a non english native speaker (but french), I have some issue with
> "valet" and "majordomo" which have fix gender in french and are all male. I
> know that it's not like that in english but I think it's better to tell it
> now.
>
> As a music player I also like "conductor" (as musical director) this is
> how I see my Jenkins instance when I use it, that orchestrate agents,
> Jenkinsfile could be the music sheet :) ....
> On Monday, June 15, 2020 at 4:00:27 PM UTC+2 Antonio Muñiz wrote:
>
> In spanish the term "Master" ("Maestro"), when used in isolation (no
> "slave" in the context), has no negative connotations. Its main use
> is to describe someone very skilled in some matter (often used for
> artisans).
> I might be suffering of language bias, just wanted to give some "non
> english native speaker" perspective to the conversation.
>
> El lun., 15 jun. 2020 a las 7:56, Justin Harringa
> (<[email protected]>) escribió:
>
> Personally I thank the community for having already starting
> down this path.
>
> I tend to like leader or controller from
>
> https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1
> but I could also see server working. The difficulty I would see
> with primary/active is that folks who run Jenkins would have a
> bit of a conflict of terminology there.
>
> Take care all.
>
> -- You received this message because you are subscribed to
> the
> Google Groups "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from
> it, send an email to [email protected].
>
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/jenkinsci-dev/3411fed5-7e21-454a-b285-f719f07c1b3ao%40googlegroups.com
> .
>
>
>
> -- * Antonio Manuel Muñiz
> * amunizmartin.com <http://amunizmartin.com> <http://amunizmartin.com>
> * [email protected]
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>
> <mailto:[email protected]> <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com
>
> <https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com?utm_medium=email&utm_source=footer>
>
> <https://groups.google.com/d/msgid/jenkinsci-dev/56742697-234e-4d29-b613-fcc13d072ed7n%40googlegroups.com?utm_medium=email&utm_source=footer>.
>
>
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/8a178366-de57-4375-aa48-7e706ca8ca87o%40googlegroups.com.
