I'm in favor of trying to align on neutral language within the codebase.
On branch naming, I think we should wait a little to see if a consensus
converges on a new naming convention at least within Git/Github. On a
technical level, I'm not sure if automated tooling (e.g. crawlers) outside
of the project might make assumptions about default branch names or what
is available in the github API for this type of metadata retrieval.
Thanks,
Micah
On Thu, Jun 18, 2020 at 1:48 PM Wes McKinney <wesmck...@gmail.com> wrote:
> On Thu, Jun 18, 2020 at 3:33 PM Antoine Pitrou <anto...@python.org> wrote:
> >
> >
> > Hi,
> >
> > Le 18/06/2020 à 21:56, Neal Richardson a écrit :
> > > Hi all,
> > > As you're likely aware, there's growing momentum in the developer
> community
> > > to drop terminology that some find offensive.
> >
> > Yes. Is it reasonable? Does it achieve anything? Is there any sense
> > in trying to "drop terminology that some find offensive"?
>
> We wish to create a community that is open and as inclusive and
> welcoming as possible. So yes, IMHO if there is something that some
> people might find offensive (even if it is not intended that way),
> then there is value in removing that possibility from the equation.
> We're here to build a healthy community that builds software together
> and so respecting the perspectives of others (even if we disagree with
> them) is a part of having a healthy community.
>
> > >
> > As a project that takes pride
> > > in being welcoming and inclusive, I think this is something we should
> get
> > > in front of--particularly as we're approaching a 1.0 release.
> >
> > I don't think we would get "in front of". We would just be following
> > the "growing momentum". In other words, we would do something because
> > it's popular.
>
> Repeating sentiments from my response a few minutes ago, I think it is
> better for us to avoid even the possibility of these concerns arising
> in this project. Let us spend our energy debating technical issues
> rather than social or political ones.
>
> > (I'll note that the urge to follow the "growing momentum" is how the
> > developer community standardised on irritating tools like Git)
> >
> > In the long term, and in the face of the problems that it claims to
> > address, this seems futile to me. But it makes some people feel good
> > about doing something, and it's (small) PR for the project...
> >
> > Now to the specifics:
> >
> > > Specifically, I am proposing to:
> > >
> > > 1. rename the "master" branch to something else ("main" seems to be
> > > popular; other version control systems use other words too).
> >
> > I used Mercurial before Git, and Mercurial uses "default". I used SVN
> > before Mercurial, and SVN uses "trunk". I don't remember if CVS is
> > sophisticated enough to have any name for this concept :-)
> >
> > The problem, though, is that "master" is the overwhelming convention in
> > Git land. Well-known conventions make a better user experience (you
> > clone a git repo, you get the "master" branch and you know it: done).
> >
> > If we choose a non-"master" name, we add an additional hoop to jump
> > through for users to approach Arrow. It's a small thing, but usability
> > is often about such small things.
>
> I'm not concerned about this, given that Arrow is already on the
> sophisticated end of the spectrum for open source projects.
>
> > > 2. replace "whitelist"/"blacklist" in our code with something like
> > > "allowlist"/"blocklist", or otherwise renaming.
> >
> > "allow"/"deny" sounds terser, and also seems more symmetric to me.
> > Also, be careful: "block" is very close, unsafely close, to "black"...
> >
> > Regards
> >
> > Antoine.
>
