User of jenkins for 2 years now. Our company uses it very extensively and it servers our purposes very well.
      However, I can't help but cringe every time someone refers to a node as a slave. I understand the computer science nature of these terms but I deeply desire to see this kind of language removed from our field of work.

      (screens attached)

      Thank you for all your hard work to make this great product, how about we make sure it's more acceptable to a wider audience!

          [JENKINS-27268] "dumb" slave?

          luke pao created issue -

          Daniel Beck added a comment -

          I wondered last year when someone would notice the terminology in Jenkins. It took longer than I expected.

          Daniel Beck added a comment - I wondered last year when someone would notice the terminology in Jenkins. It took longer than I expected.
          Daniel Beck made changes -
          Component/s New: core [ 15593 ]
          Component/s Original: slave-setup-plugin [ 15929 ]
          Assignee Original: Kohsuke Kawaguchi [ kohsuke ]

          luke pao added a comment -

          Excellent reference! Would be great to see that kind of change here.

          luke pao added a comment - Excellent reference! Would be great to see that kind of change here.

          Daniel Beck added a comment -

          Due to Jenkins' extensive plugin API and the desire to keep backwards compatibility, we'd need to keep existing internal class names, and those use Master/Slave. If anything were done here it would be UI only.

          AbstractCloudSlave
          ClassLoaderStatisticsSlaveInfo
          CloudSlaveRetentionStrategy
          DefaultJnlpSlaveReceiver
          DumbSlave
          DumbSlave.DescriptorImpl
          EncryptedSlaveAgentJnlpFile
          EnvVarsSlaveInfo
          Hudson.MasterComputer
          Jenkins.MasterComputer
          Jenkins.MasterRestartNotifyier
          JnlpSlaveAgentProtocol
          JnlpSlaveAgentProtocol.Handler
          JnlpSlaveAgentProtocol2
          JnlpSlaveAgentProtocol2.Handler2
          JnlpSlaveHandshake
          JnlpSlaveRestarterInstaller
          MasterBuildConfiguration
          MasterKillSwitchConfiguration
          MasterKillSwitchWarning
          MasterToSlaveCallable
          MasterToSlaveFileCallable
          OnMaster
          PretendSlave
          PretendSlave.DescriptorImpl
          Slave
          Slave.JnlpJar
          Slave.SlaveDescriptor
          SlaveComputer
          SlaveRestarter
          SlaveSystemInfo
          SlaveToMasterCallable
          SlaveToMasterFileCallable
          SystemPropertySlaveInfo
          TcpSlaveAgentListener
          TcpSlaveAgentListener.ConnectionFromCurrentPeer
          ThreadDumpSlaveInfo
          UnixSlaveRestarter
          WinswSlaveRestarter

          This also means that any changes to terminology are less likely due to the additional confusion caused for the hundreds of developers of plugins when e.g. "Worker Nodes" on the UI don't use the same name internally.

          Daniel Beck added a comment - Due to Jenkins' extensive plugin API and the desire to keep backwards compatibility, we'd need to keep existing internal class names, and those use Master/Slave. If anything were done here it would be UI only. AbstractCloudSlave ClassLoaderStatisticsSlaveInfo CloudSlaveRetentionStrategy DefaultJnlpSlaveReceiver DumbSlave DumbSlave.DescriptorImpl EncryptedSlaveAgentJnlpFile EnvVarsSlaveInfo Hudson.MasterComputer Jenkins.MasterComputer Jenkins.MasterRestartNotifyier JnlpSlaveAgentProtocol JnlpSlaveAgentProtocol.Handler JnlpSlaveAgentProtocol2 JnlpSlaveAgentProtocol2.Handler2 JnlpSlaveHandshake JnlpSlaveRestarterInstaller MasterBuildConfiguration MasterKillSwitchConfiguration MasterKillSwitchWarning MasterToSlaveCallable MasterToSlaveFileCallable OnMaster PretendSlave PretendSlave.DescriptorImpl Slave Slave.JnlpJar Slave.SlaveDescriptor SlaveComputer SlaveRestarter SlaveSystemInfo SlaveToMasterCallable SlaveToMasterFileCallable SystemPropertySlaveInfo TcpSlaveAgentListener TcpSlaveAgentListener.ConnectionFromCurrentPeer ThreadDumpSlaveInfo UnixSlaveRestarter WinswSlaveRestarter This also means that any changes to terminology are less likely due to the additional confusion caused for the hundreds of developers of plugins when e.g. "Worker Nodes" on the UI don't use the same name internally.

          luke pao added a comment - - edited

          Indeed, internal classes are altogether another story, but even just changing occurrences of "dumb slave" would make for a great start.

          luke pao added a comment - - edited Indeed, internal classes are altogether another story, but even just changing occurrences of "dumb slave" would make for a great start.

          Daniel Beck added a comment -

          Yeah, I know from the linked thread.

          I put this issue on the agenda of the governance meeting next week:

          https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda#GovernanceMeetingAgenda-Mar18meeting

          Daniel Beck added a comment - Yeah, I know from the linked thread. I put this issue on the agenda of the governance meeting next week: https://wiki.jenkins-ci.org/display/JENKINS/Governance+Meeting+Agenda#GovernanceMeetingAgenda-Mar18meeting

          Daniel Beck added a comment -

          kohsuke didn't show up to the meeting, so this got postponed to April 1.

          Daniel Beck added a comment - kohsuke didn't show up to the meeting, so this got postponed to April 1.

          Daniel Beck added a comment -

          We discussed this issue in the governance meeting yesterday.

          http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-04-01-18.02.log.html starting at around 18:29 until 18:55.

          Daniel Beck added a comment - We discussed this issue in the governance meeting yesterday. http://meetings.jenkins-ci.org/jenkins/2015/jenkins.2015-04-01-18.02.log.html starting at around 18:29 until 18:55.

          luke pao added a comment -

          VERY much appreciate the transparency of process here.

          It sounds like some of you genuinely care that this language is highly offensive outside of this tech bubble we're in, but the sad reality is redit/hn flame-throwing tends to be the biggest motivation for making these kind of changes and saving face.

          As for next steps, what I've gathered from the meeting is SUBJ terminology will likely be addressed. That's good, but satisfactory would be a change in terminology similar to Django. However, the idea of making that kind of change sounded unfavorable in the meeting logs, so can you clarify exactly what changes will and will not be made regarding this issue?

          Thanks!

          luke pao added a comment - VERY much appreciate the transparency of process here. It sounds like some of you genuinely care that this language is highly offensive outside of this tech bubble we're in, but the sad reality is redit/hn flame-throwing tends to be the biggest motivation for making these kind of changes and saving face. As for next steps, what I've gathered from the meeting is SUBJ terminology will likely be addressed. That's good, but satisfactory would be a change in terminology similar to Django. However, the idea of making that kind of change sounded unfavorable in the meeting logs, so can you clarify exactly what changes will and will not be made regarding this issue? Thanks!

            amuniz Antonio Muñiz
            strongs26 luke pao
            Votes:
            0 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:
              Resolved: