[Brainstorm] Workstream deliverables and collateral aggregating

[celestehorgan]

1. What collateral (documentation, guidelines, tooling) do we want to produce? These don't need to be specific to a workstream
2. Does your company/organization have resource(s) they would like to make public or share or collate with this group?
3. Any other work this group should do?

[markcmiller86]

I wanted to suggest an idea for a routine agenda item we include in our regular meetings. So, this is less an idea about what deliverables we produce and more an idea about how we go about them.

Here is my idea...I would like to suggest we include near the beginning of every meeting an Inclusive Minute exercise. It only needs to take a minute or two. Someone in the group leads the exercise and introduces some resource, event, factoid or experience and spends just a little time describing it. We could opt to limit scope of the exercise to items dealing specifically with language. The exercise is aimed at simply raising awareness of the breadth and depth of inclusion as it relates to our industry. We can rotate the leadership of this short exercise amoung ourselves or take volunteers.

I've done this in other (software specific contexts) and it seems to be well received and because it is intended to be short, is easily added to existing agendas. I've attached more detailed slides about it here for anyone interested.

framing_inclusive_minute_opt.pdf

[tomschr]

Hi,

as I'm not so familiar with the group (yet), I would like to answer point 3. 🙂

Would it be useful to collect all important links that we share on Google Groups etc. here at GitHub? Not all people will look into a mailinglist and will probably miss something. It feels a bit disconnected for me to be honest.

So my idea would be to create a text file, a Wiki article etc. were we can add links or other important resources so it's collected, stored, and versioned. I think, it could be very helpful for new contributors (speaking about myself as a newbie. 😉 )

What do you think? 🙂

[hellasteph]

I'm definitely for this idea. I'm brand new here but I was able to navigate around pretty well since the tooling is similar to what my own company uses.

It also sounds like we need some sort of knowledgebase or knowledge hub. I'm familiar with using Notion or Coda which has a tiny bit more non-techincal user interface.

[markcmiller86]

I dunno if I am thinking to far ahead here but I am thinking that we (not just this group but the community as a whole) should be able to reach a point of tooling for inclusive language that is manageable at a level similar to how spelling and grammar checking tools are currently employed.

So, I think we can use knowledge of how those technologies work in context of either turnkey tools (like a word processor) as well as continuous integration (CI) pipelines and hooks in git repos, etc., post-processing tools, to help shape our goals. Something that will be somewhat similar to grammar checking tools...

1. Flagging instances of non-inclusive language
2. Suggesting replacement language
3. Providing link to or descriptive text for rationale
4. Taxonoimzation of flagged language (kinda like parts of speech in grammar checking)
5. Defining a process and community participation for how inclusive language terms evolves with time

Many grammar checking tools I think have various categories (or a taxonomy) of vaiours kinds of things they check and flag. I suspect inclusive language will have a similar kind of thing. For example, the Intel team yesterday indicated that because they are so multi-national, there is need to have maybe some regional-specific inclusive language settings. Continuing with the metaphor of grammar checking, thats a little like dialects in a country (e.g. in certain parts of US, aint is a well accepted).

My thinking is that the ultimate deliverable to the community is the routine publication of a database of flagged words or phrases data, suggested replacements, associated rationales perhaps in the form of json, yaml or xml files, as well as baseline command-line text processing tools (similar to aspell or other js.node or npm tools) as well as establishing the processes for routine maintenance of that database.

[tomschr]

I think that's a fantastic idea! 👍

If we could create some tooling around which could be used either locally or as a CI (GitHub Action etc.) that would be really helpful. That could flag problematic terms and help contributors. We should be aware that not everyone speaks English fluently. 😉

[markcmiller86]

A very basic search on GitHub for example, reveals a ton of instances of the master/slave terminology as we might expect.

Do we wanna help define how software (e.g. code) is processed apart from its existence as a highly structured form of text? I mean a first question is, do we see our role as including the ability to help identify inclusivel language issues in software/code? A second question is can we devise approaches that are better than just processing code as text? My first thought is that GCC (GNU Compiler Collection) probably already has hooks into it for adding such functionality if that is desired.

Addressing inclusive language in software (either symbol names or literal strings), may be a harder problem than in ordinary speech. Its worth asking how this problem is different and what we might be able to bring to bear on it.

[samuelknuth]

At Red Hat, we're starting work on creating an enablement guide to help open source contributors successful champion this work. Our goal is to make this public. If folks are interested in collaborating on a public document, happy to discuss

[lmaffeo]

@samuelknuth happy to help out. I volunteer as a community correspondent for OpenSource.com and have several friends at Red Hat. Let me know how I can get involved!