Adding "inclusion" tag to CommOps Pagure?

Hey all, I wanted to suggest adding a new type - inclusion tag to the CommOps Pagure.

Recently, Emma Irwin over at Mozilla / CHAOSS project published this blog post about inclusion bugs. It includes resources such as a checklist for governance needs and a way to make tasks that help inclusion more visible.

In CommOps, the type - inclusion tag could be tasks that helps people to contribute to Fedora. This can mean many things, like lowering barriers of entry (e.g. our on-boarding tickets) or other things that make the contributor community more accessible. It seemed like it could fit in with some of our existing work.

Anyone mind if we try using this out as a new tag? I thought it would be a good idea.

1 Like

Seems reasonable to me.

1 Like

In response to the Medium article, considering there is actually no diversity
or “inclusion” issue in FLOSS, I don’t see how this would be necessary. As far
as the Mozilla diversity thing goes, I don’t see how a code of censorship,
avoiding “jargon” (technical terms as well, I suppose?) or “non-inclusive
language” would help anyone. It is trivial to look up almost any term, and
very few people have issues with people asking them to explain jargon or
technical terms.

Really, I don’t see the point in something like this if we have to sacrifice
one person’s time or an entire team’s time just to bring on a single new
contributor. If “inclusion” can be done without sacrificing time (automated
translations, with a note that they’re automatic and probably wrong, for
example) and simplified tooling that would actually help many people, great.
But introducing censorship, trying to find “underrepresented” people, and
random pronouns (I don’t see how the gender identity of a contributor matters
in the least) is just going to make it harder for both existing contributors
and for new contributors.

Diversity and inclusion are important to the Fedora Project. “Friendship” is one of our foundations.

1 Like

I don’t believe you read what I said. Diversity or “inclusion” should
definitely not be some goal, nobody cares about quotas of people from a given
background. There’s no benefit to having specifically more people of a given
background. If you want to foster the ability for people of a certain
background to contribute, great! But to waste time trying to find people and
getting them to contribute, trying to go out of your way to make it easier for
people of a given background to contribute than even current contributors, and
to undermine the learning curve that current contributors went through, is
complete nonsense.

To ask current contributors to “dumb down” things just for the possibility of
somebody from an “underrepresented” group to be able to contribute is
absolutely useless. In fact, it’s counterproductive.

Friendship doesn’t mean “Waste time finding out who’s the most oppressed”.

To better represent my own views here, I’m going to restate this in a way
which sounds less hostile:

I don’t think there’s really a need for an “inclusion” tag, as any action
which makes it easier for any member of the community to contribute is
inherently an “inclusion” related action. We don’t need to use such
politically charged words as “diversity” and “inclusion”, and we certainly
don’t need to censor current contributors in order to attract more
contributors, or, and this is what I fear, lose contributors in order to bring
in fewer contributors than we’ve lost.

We walk a thin line between alienating current contributors with politics and
the possibility of bringing in more contributors.

I personally don’t see how the background of contributors would affect the
project, and we can certainly be welcoming of other cultures without applying
a censorship model to the project. As for the gender identity and sexual
preferences thing that these links touch on, I really don’t see how any of
that matters in a software project.

Hi John. I definitely read what you said, and I appreciate the second less-hostile restatement.

Many issues important to free and open source software are inherently political — privacy, digital freedom, copyright and patent law. I know you care about right to repair, which is definitely a political issue. Diversity and inclusion may indeed be political issues in this same way, but I hope we are not at a point in the world where they are partisan politics. They just mean what they say: we value and respect differences in opinion, background, and approach, and we want all people to feel welcome.

I read Justin’s proposal here, and the links he provides. I hear you expressing a lot of fear about “censorship”, about building unfair paths for some people, and “wasting time”. I don’t see that in Justin’s simple suggestion, nor do I find it in the background material. I really encourage you to read all of this with positive intent and to extend some trust to the people in the project tasked with and interested in working on this. I think you are absolutely right that the things we do to increase inclusion should (and will!) benefit everyone.


I think that like all things community, try it, let the community itself decide if they like it or want it. I know that in my field of work, there are innumerable acronyms, the conversations are laced throughout with technical terms that cause most peoples eyes to glaze over upon hearing the words, so any effort to try engage those unfamiliar with it is most often worth it. To get more documentation contributors, or contributors on all levels of need in this community, if this helps, I say try it!

1 Like

I added the tag to our Pagure repository today. As part of my work in fedora-commops#181, I will work on documenting this in our workflow before the end of the Fedora 30 release cycle.

In that case, make sure to set it as a default tag, such that it is applied to all CommOps tickets.