Re: inclusive language
Richard Purdie
Thanks for bringing this up and writing a summary. The OE and YP TSCs
are aware of this and are starting to have discussions about it. I have also been looking at what other projects and the Linux Foundation are doing. As yet there aren't any real conclusions, I've been kind of waiting for git itself to make a decision as that could significantly influence what we do for practical reasons. On Wed, 2020-07-15 at 01:31 -0400, Trevor Woerner wrote: As most are aware, there are efforts in many open-source/free-softwareThe challenge with this topic is that anyone arguing against it potentially ends up being branded as unsupportive of certain groups at best and racist and worse at worst. That is not a good position to have to make decisions from, it does feel like there is no choice in the matter and we'll have to do something or perhaps anything and everything. 2. Scope Creep. From the dawn of the OE project, there have been "discussions"Shouldn't that be RECIPENAME? ;-) I think my reply (which was my first thought) proves your point! :) There is a valid argument that some variable names are problematic and we don't change them simply due to the pain involved. If we are changing them, we should aim to get them right? As one of the maintainers, I actually get really depressed when people say "what kind of a person picked a name like this". Naming is much harder than people think. I've been responsible for some of it and don't like some of the end results we've had, equally, I struggle to come up with better ideas for some areas. 3. Deprecation Plan. Given the layered nature of the ecosystem, inevitablyThe good news is that there is a way for layers to mark what they're compatible with and they have to opt in with each new release. As such I suspect we could move fairly quickly and in most cases just error out if/where old names were used? 4. What will be affected? Branch names, variable names, function names,We are not responsible for other other upstreams, we will just follow their lead. As such for example I don't think we should take patches changing terminology in upstream software. I think all the things you mention are things we will have to look at. Some aren't a big issues and easy to change, the branch and variable names are probably the most problematic. 5. Backports. How far back do we make changes?This is where it gets potentially most worrying. For example, does the project promote racism if it doesn't take the changes back into the LTS? Does having the LTS and master diverge make things more or less difficult to maintain. We might make a decision now but what will 'peer' pressure look like 1 or 2 years into the LTS? 6. Terminology. The Linux kernel project has put out some recommendations:I don't see that anyone can realistically argue against 1 for the reasons I mention above, regardless of what they might think. My personal position (not a project one) is that I do see the issues in the terminology and I appreciate the community's desire to want to do something about it, I want to support that. I do however worry that its going to cause weeks of work in dealing with the fallout from changes and a lot of that will end up falling to me personally as few people step up to do that kind of thing beyond the first patch. The kind of thing I'm referring to isn't writing the patches to change something, or coming up with a plan for that. Its writing replies like this to discussion on the mailing list or explaining to a user on irc that they're using docs for "pre-change" and they need the "post- change" docs, updating the docs themselves (we don't have a docs maintainer right now, I'm kind of doing it) or attending the bug triage call and figuring out how to deal with issues (who takes these bugs?). Is this a good way to spend the time? Would that time be better spent helping some new users and getting new active maintainers involved with the project? Difficult to say. Assuming the answer is yes, we need to do something (I really can't see any other way forward), some logical next steps and places to start are: a) Find a list of patches that need renaming and send patches to rename them. This shouldn't be an issue. b) Create a list of function names that need renaming. Patches to handle those also shouldn't be too invasive. c) Create a list of problematic variable names so we can understand the scope of that problem. We can then formulate plans around them on a case by case basis. For branch naming there is potential impact on the infrastructure and demands on Michael's time as well as mine, depending on what we might do there. There are large chunks of code like the autobuilder codebase which have limited numbers of contributors yet are key to the project's health. I think its going to be the most invasive area to change, how invasive will depend on exactly what we do, assuming we do it. Cheers, Richard |
|