Is there any recommendation regarding white-label product? Tier 1, 2, 3 or no change?

from @rbowen "At the risk of being annoying ... who's on deck for PRs to the website repo? There's a significant backlog, and it's going to lead to conflicts in a number of these, depending on what order they get addressed."

https://inclusive-naming.slack.com/archives/C01JCKTUS6M/p1622138367044900

We should define who has access and the responsibility to merge and maintain the website

Allstar has detected that this repository’s Branch Protection security policy is out of compliance. Status:
No protection found for branch main

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

https://inclusivenaming.org/language/word-list

Allstar has detected that this repository’s Outside Collaborators security policy is out of compliance. Status:
Did not find any owners of this repository
This policy requires all repositories to have an organization member or team assigned as an administrator. Either there are no administrators, or all administrators are outside collaborators. A responsible party is required by organization policy to respond to security events and organization requests.

To add an administrator From the main page of the repository, go to Settings -> Manage Access.
(For more information, see https://docs.github.com/en/organizations/managing-access-to-your-organizations-repositories)

Alternately, if this repository does not have any maintainers, archive or delete it.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Our WS voted to change the meeting time and date to Thursdays at 10am Central. I logged into the site through my gmail and still couldn't change it.

[Bug] "Get Involved" button on home page opens "Page not found"

• Issue reported on twitter

How to recreate:

• go to https://inclusivenaming.org/ home page
• click on Get Involved button
• I am redirected to https://inclusivenaming.org/get-involved
• I can see an error "Page Not Found, Looks like you've followed a broken link or entered a URL that doesn't exist on this site."

Suggestions:

• update URL for Get Involved button
• change URL from https://inclusivenaming.org/get-involved to https://inclusivenaming.org/participate/

A section with reasoning, background, why some alternatives were rejected, etc. needs to be added to the individual markdown files for each of the terms (if it doesn't exist.)

We did not convert commentary into this content in the following files:

• man-in-the-middle.md
• cripple.md
• tribe.md

Rather than having the blog in the top nav, it should be a drop down menu for all of our marketing related things. The top tab should be "News & Media" and the drop down should list "Blog, Media mentions, Branding, and Presentations" like on the CNCF homepage

Some of the terms on our list may have special meaning in other domains, for example:

• "parent/child" has a meaning in healthcare but in finances it might be "parent/dependent". So a recommendation about the term "parent/child" shouldn't apply to the UI in those cases.

We should clarify that our terms should be considered with regards to UI, but we cannot know all the special cases, so a domain expert should be consulted when making UI language change considerations.

Monica Rush image on this page is really low quality.

I tried a google search for a better image. Didn't find one.

But I'd bet we can get one from Monica.

I had a quick conversation with @quaid today about this concern and he recommended I file an issue about it in order for your group to potentially advise on it (thank you :) ) I put together a writeup to provide the context - let me know what you think.

Podman Inclusive Naming

1. Problem statement

There has been community feedback about the name Podman potentially being problematic because it includes the word man. Part of the concern is that Podman is a part of the broader open source / technology community, which has historically been a male-centric space. The term man could be interpreted as gendered language and potentially frame the project as unwelcoming to other genders.

2. Background

The name Podman is a combination of the term pod which refers to a grouping of containers, and manager because it enables users to manage their containers and container pods. The command line command for running Podman is podman.

Podman brand recognition

The earliest release of Podman available from Podman's current Github repository is v0.3.5 released 5 April 2018; the initial commit to the Podman repository was 1 Nov 2017.

Worldwide interest in Podman as a topic, as assessed by Google Trends, has been on a steady upward trend, from 0-2 interest per week in May 2017 to a peak of 100 the week of February 6-12, 2022.

Projects with similar function or naming

One counter point to the concern raised about Podman that's been shared by a number of people is the ubiquity of "man pages," another shorthand -- this time for "manual" and not "manager." It seemed important to think about what other projects use the shorthand "man" in their names, so below find a non-exhaustive list of such projects:

Specific concerns raised about the name

Here are two conversation threads started by one community member (on behalf of another) that served to raise the concern to the Podman team:

• Can we rename podman to something less masculine? #2226
• Twitter thread

Podman branding background

Máirín Duffy in consultation with Dan Walsh and Tom Sweeney proposed a selkie mascot for Podman's branding. Máirín thought it would be a good idea to have an animal-based mascot as the Buildah mascot was a Boston Terrier and it would be nice to have continuity between the logos. Máirín and Tom researched all the animals for which a group is called a pod, and seals was among them. At the time, Máirín's children were obsessed with the movie Song of the Sea about a family of selkies (seals), a mythical Celtic creature that is a feminine creature that transforms from being a seal to being human and back. This led to the artwork below being developed, and the central one with three selkie seals in a group (a "pod") was the design the Podman team chose as it was closest in concept to the core function of the project:

Podman as a project was also featured in The Container Commandos Coloring Book released in 2018. Podman is represented by an androgynous, purple-eyed superhero in a wetsuit, wearing scuba gear with purple and yellow accents (see far left:)

3. Inclusive naming principles

In order to assess a path forward to address the concerns raised, I researched inclusive naming principles, which included evaluating the name "Podman" against the following inclusive naming recommendations:

Inclusive Naming Project

Reviewed resources provided by that project and evaluation against Podman naming:

1. Word lists ("man" does not appear on any of the lists of words to remove or consider removing.)

2. Language evaluation principles and framework:

• First-order concerns: No apparent first-order concerns.
• Second-order concerns: "The term is unnecessarily gendered" is a definite potential interpretation of the name "podman."
• Third-order concerns: No apparent third-order concerns.
• I believe (but am not sure) that second-order concerns map to tier 2 word list recommendations, which advise "strongly consider replacing."

3. Implementation Path Considerations

• Command names: [...] command names and flags for CLI tooling should accept both terms for a period of time. Ideally, serve a deprecation notice when a user uses the old command or flag.
• Assess downstream impact: Assess whether downstream projects have a specific dependency on any of the following:
• Git branch names
• Specific URLs
• Specific keywords or commands
• These are all items that would be impacted and would need to be address in the situation where the name "Podman" was changed.

IBM Inclusive IT Language Recommendations

Reviewed IBM Inclusive IT Language Recommendations. Man" is not included on the list of terms, but relatedly "Fellow" is. This group classifies "fellow"as "no change recommended:"

Fellow refers to the most senior rank or title one can achieve on a technical career in certain companies or a member of a learned or professional society, or a person who has been awarded a grant for studies, typically in the field of scientific research, or a person who has earned a fellowship. A Fellow can be male or female. This term does not promote gender bias.

LinkedIn's Leading Inclusive Teams Course

LinkedIn has a training course called Leading Inclusive Teams that includes a chapter called "Using inclusive language." Notably, the term "man" with respect to naming occupations comes up around 0:01:15 in the video:

When discussing professions, remove gender from job titles. Instead of fireman, policeman or businessman, you can use firefighter, police officer and business executive. These are gender inclusive positions that are often associated with men.

This advice doesn't quite fully apply to Podman's branding, since there is no such profession - historically gendered or not - called "podman," nor is "podman" a term that existed previous to the naming of this software project. It is a novel portmanteau of two words - "pod" and "manager" - that are considered neutral with respect to gender. (The etymology of the word "manager" is traced - via horse trainers - to the Latin "manus," meaning hand.)

Máirín's Assessment

My assessment, which is ongoing and may evolve further:

Based on this review of inclusive naming project documents and guidelines, the use of "man" in the name of the Podman project is not an egregious issue with respect to inclusive language.

Significantly, however, it has been brought up as a concern both internally and externally. This merits both acknowledgement and examining ways we might adjust the project's branding and supporting artifacts (such as the website and other marketing materials) to help the project's outward face reflect more accurately the project's inclusive attitude and nature.

Proposal

There are multiple places where a potentially masculine perception of Podman could be tempered, and multiple options per location that can be considered. These will be outlined below.

Podman's mascot

As mentioned earlier, multiple mascots were drawn up during the process of the current logo's creation, all based on the feminine creatures called selkies in Celtic mythology:

The currently-used illustration, depicting three selkie seals in a pod (center, above,), was determined to be the strongest image conceptually due to its showing multiple selkies. To build on that concept, some ideas:

• Modify the illustration to emphasize the feminine nature of the creatures. For example, change out one or two of the selkies to be feminine and wearing a seal skin, such as in the "podman-selkie-girl" illustration above. This was a common visual theme in the inspirational work Song of the Sea as shown below:

(Note these images are copyright Cartoon Saloon and have been cropped down to only the parts relevant to the discussion in the spirit of fair use)

• Modify the illustration to visualize 'management' concept: For example, as can even be gleaned from the Song of the Sea image to the right and above based on the relative positioning of the characters - could the selkie girl be depicted as "managing" a pod of seals, thus not only making clear the feminine nature of the mascot, but also demonstrating this feminine character in a management role to better symbolize the name's meaning? One proposed potential such treatment is mocked up below:

Sketches of other potential treatments to mock up are below:

Podman's tagline

Podman's website (both current and the current version of the proposed redesign) has a tagline under the project name towards the main logo area of the page header. On the current podman.io (as of 26 May 2022) this tagline is:

Manage pods, containers, and container images.

The most recent version of the proposed new website design has the following tagline:

The daemonless container engine.

A proposal to improve this to re-emphasize the "manager" component of Podman, would be to explicitly use the term "manager" or "manage" in the tagline. A few proposed taglines to replace these:

• The daemonless container manager.
• Pod, container, and container image manager.
• Manage, develop, and run containers.
• Manage pods, containers, and container images. (the original tagline)

Podman's full logo lockup

I suggest the development and usage of a new form of the full Podman logo that includes the tagline in the lockup, and that this version of the logo (which we'll call the "full logo lockup") be used in instances where the context of Podman being a manager might be called into question. For example, the title slide of a slide deck presentation, or the front page of the project website.

Here is an example of what this might look like using one of the replacement tagline ideas above, with a draft of a different logo graphic:

Podman's website

I suggest an audit of the website content for both the existing podman.io website and the proposed redesign with an eye for reinforcing the project's core function as a manager, and replacing / re-ordering / re-phrasing language in order to emphasize this. This is the top of the current Podman website at podman.io as an example, with some specific highlights:

• "Engine" is highlighted - this word could potentially be replaced with "manager" or re-phrased / re-positioned to better emphasize the management aspect of the tool first.
• "Developing" comes first in the series of words in this sentence and "managing" comes second. I suggest emphasizing "managing" more by listing it first.

Small content tweaks like this might seem minor but have an overall effect on how the project is perceived and can be very helpful in reinforcing the meaning of "Podman." This work could be conducted relatively quickly with little effort and submitted as a PR to the website repository.

https://www.dictionary.com/browse/biweekly

You should get rid of the SDDI logo. The project doesn't exist. It was "created" and had a listserv for a few months (https://groups.linuxfoundation.org/g/sddi-formation) but is not longer active. @celestehorgan

Overview

The "Changing the git branch name" section of the Implementation page is out of date.

Details

From the page:

Their recommendation is to wait until later in the year (2020) to change branch names. However, if you want to start work, we recommend the following [...]

There have been some changes since this was last updated:

1. GitHub now has an option for renaming branches.
2. GitLab also has extensive support for changing default branch names.
3. New GitLab and GitHub projects have a default branch of main.
4. New git configuration allows you to change the default branch name on your local machine

Source

• https://inclusivenaming.org/language/implementation-path/#changing-the-git-branch-name
• https://github.com/inclusivenaming/website/blob/main/content/language/implementation-path.md#changing-the-git-branch-name

AFAICT all the pages have the same <title>.

This causes various issues such as multiple page tabs having the same text.

Black Box Testing: commonly means testing a system without access to the source code.
Suggested replacement: ?

White Box Testing: commonly means testing a system with access to the source code.
Suggested replacement: Clear Box Testing

Current situation

The main visible word list page doesn't link to the word lists directly, only from the menu.

The URL path to /word-lists/ does not have an index file, so gives a 404 error.

All of the terms are in two locations:

• /word-lists/tier-N/ -- all terms are in the single tier file
• /language/word-list/ -- one file for each term

Relevant URLs

• https://inclusivenaming.org/word-lists/overview/
• https://inclusivenaming.org/word-lists/
• https://inclusivenaming.org/word-lists/tier-1/
• https://inclusivenaming.org/word-lists/tier-2/
• https://inclusivenaming.org/word-lists/tier-3/
• https://inclusivenaming.org/language/word-list/
• https://inclusivenaming.org/language/word-list/master/ etc.

Recommended fixes

1. Create a file in the repo /website/content/word-lists/index.md that contains or links to the overview and tiered list.
2. Remove the /word-lists/tier-N/ files as too cumbersome to keep a growing list of words in a single file. Create redirects from there to index.md.
3. Rename /website/content/word-lists/overview.md to index.md, then have the Tier 1, 2, 3 subsections in the file contain a list of the terms, which are themselves links to the actual term.md file.
4. Have a single file for all terms, located in /website/content/language/word-list/.
5. Create a file /website/content/language/word-list/index.md that duplicates /website/content/word-lists/index.md.
   • Alternately, merge all together into a single relative path e.g. inclusivenaming.org/word-list/{index.md,term.md}

https://inclusivenaming.org/related-projects/ could link to https://www.plainlanguage.gov/guidelines/ as a related project (albeit US-specific)

Like a template.md that can be copied and filled with content from the tier pages or a new term.

All,

I get a 404 when trying to access the word list from the website.

Allstar has detected that this repository’s SECURITY.md security policy is out of compliance. Status:
SECURITY.md not found.
A SECURITY.md file can give users information about what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible. Examples of secure reporting methods include using an issue tracker with private issue support, or encrypted email with a published key.

To fix this, add a SECURITY.md file that explains how to handle vulnerabilities found in your repository. Go to https://github.com/inclusivenaming/website/security/policy to enable.

For more information, see https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

• Add a page to website for workstreams
• Add/link? public calendar from website
• Add link to Slack inviter
• Document workstream mailing lists somehow

I'm sure there's things I'm missing cc: @justaugustus, @edwarnicke  – any other thoughts?

Please provide workstream leads with permission to invite others to read/write/edit in the INI google drive. Currently we are able to create folders but not able to invite members of our various workstreams to upload documents or edit the contents.

Displaying project members' pronouns is a good way to signal trans-friendliness/ trans-inclusivity and improves accurate conversation about and within the project.

You are being overly harsh on people you call sea lions. Today's "sea lion" can be tomorrow's friend. In most cases they are trying to help. You can close this issue now. I just got upset when reading the "us" vs "them" mentality on the page.

With some irony,

Lawrence

What's the name of the site/media that mentioned Inclusive Naming Initiative?

Not a media mention -- but I'm not sure how to report a site issue, so:

Notice from Netlify

After November 15, 2022, builds for this site will fail unless you update the build image.

As reported via deploy logs:

DEPRECATION NOTICE: Builds using the Xenial build image will fail after November 15th, 2022.

The build image for this site uses Ubuntu 16.04 Xenial Xerus, which is no longer supported.
All Netlify builds using the Xenial build image will begin failing in the week of November 15th, 2022.

To avoid service disruption, please select a newer build image at the following link:
https://app.netlify.com/sites/etcd/settings/deploys#build-image-selection

For more details, visit the build image migration guide:
https://answers.netlify.com/t/please-read-end-of-support-for-xenial-build-image-everything-you-need-to-know/68239

What is the URL to the article that mentioned/featured INI?

n/a

We have a lot of work backed up in the Language WS that is website related: terms to add or evolve, improvements to the website, and improvements to the word lists. And love and respect for the owners of the inclusivenaming org, but y'all don't have the time to come get the understanding for each PR that the Language WS has about these changes and be willing/able to approve them, change them, etc.

So .... let's deligaaaaaaaaaaate!

Would @edwarnicke get approved and/or do the changes to the inclusivenaming GitHub org and/or to just the website repo to allow some of us in the Language WS to approve PRs?

We discussed this in our meeting today and here is the list of people we'd like to add:

@LarryKunz
@quaid
@lex-joy
@markcmiller86 < Mark wasn't in the meeting but I recall his interest in helping with GitHub, so I am boldly adding him

All the above folks have long-standing/since-the-beginning relationships to Inclusive Naming as contributors to the Language WS. If the Language WS had it's own repo (hint, hint), these would be some of the maintainers.

If there isn't granularity to give merge permissions to these folks for just the website repo, then can we either fix that or just keep skipping that and let these folks have permissions? This stuck-state has been unchanged for most of a year for the Language WS.

If there is a governance issue blocking these folks being made maintainers of the website repo, do we fix the governance or does the governance tell us what to do when existing maintainers aren't merging and active contributors want to? (And does the governance tell us why and how people get merge rights, in particular, people who are active in the project compared to inactive or new people?) Asking because the governance I find is https://github.com/inclusivenaming/org/tree/main/governance.

During discussions in the meeting today I realized that @abuango is actually a maintainer and could do merges, but ironically one of the key PRs we want to merge is the PR he opened! If he's not supposed to merge his own PR ...

Surely such lists can include entries other than nouns?

It would be handy to have a regular expression that one could use to run a quick scan on content to ensure that words in a particular set of tiers do not appear. I maintain, for example, some documentation in AsciiDoc that really lends itself well to this sort of search.

I cobbled this expression together based on the contents of the "term" field in each wordlist file:

$ grep -Pi "\b(?:black[\-\s]?box|Blackout|disable|fellow|master\s?mind|white\s?box|white[\-\s]?label|test1|cripple|master|slave|master|abort|blackhat|whitehat|Tribe|white[\-\s]?list|sanity(?:\-|\s)check|hallucinate|man\-in\-the\-middle|Segregate)\b" -R .

You'll also notice in my expression that I accounted for some variations ("sanity check" and "santity-check"; "black box", "black-box", and "blackbox"; ...), and broke apart some of the combinations ("whitehat-blackhat" became "whitehat" and "blackhat"). I didn't get them all, and there may be some errors (I haven't paid any attention to tiers, for example).

In typical fashion, I'm probably overthinking this... Since the lists are dynamic and I expect will change over time, I'm thinking that the expression should be generated automatically based on the wordlist files in /content/word-lists. It should be relatively straightforward to leverage Hugo to build an expression from this data, or from the content in the JSON word-list.

Having some consistency in the way that terms are captured would make this a lot more useful. The "master-slave" and "whitehat-blackhat" entries don't lend themselves well to the automation (I understand why combining them makes sense). Perhaps adding some version of a variations field could provide a simple solution.