19:00:40 <jillr> #startmeeting Ansible D&I WG Agenda: https://github.com/ansible/community/issues/577
19:00:40 <zodbot> Meeting started Thu Feb  4 19:00:40 2021 UTC.
19:00:40 <zodbot> This meeting is logged and archived in a public location.
19:00:40 <zodbot> The chair is jillr. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:40 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:00:40 <zodbot> The meeting name has been set to 'ansible_d&i_wg_agenda:_https://github.com/ansible/community/issues/577'
19:02:42 <samccann> o/
19:02:49 <jillr> o/
19:03:00 <jillr> #chair samccann
19:03:00 <zodbot> Current chairs: jillr samccann
19:03:37 <felixfontein> hi!
19:03:43 <jillr> #chair felixfontein
19:03:43 <zodbot> Current chairs: felixfontein jillr samccann
19:04:03 <felixfontein> (only partially here though)
19:04:25 <tadeboro> Hi all!
19:04:27 <jillr> we have a lot on the agenda so let's kick off and people can join as they arrive
19:04:31 <jillr> #chair tadeboro
19:04:31 <zodbot> Current chairs: felixfontein jillr samccann tadeboro
19:04:35 <jillr> #topic Announcement: New AWX logo
19:04:45 <jillr> The AWX community realized recently that the original AWX logo (the "AWX with wings") bore a resemblance to symbols used by certain hate groups.
19:04:48 <jillr> A new logo was designed and has been adopted by the project.
19:04:54 <jillr> The annoucement is here:
19:04:59 <jillr> #link https://groups.google.com/g/awx-project/c/4gCe1NSVuu4/m/-yYbQkpkAgAJ
19:05:04 <jillr> And the new logo can be seen here:
19:05:07 <jillr> #link https://github.com/ansible/awx/pull/9203
19:05:49 <samccann> woot
19:07:01 <jillr> #topic ways we can encourage communities/collections to audit/change problematic language
19:07:38 <cybette> sorry I'm unable to join today, but yay new logo!
19:07:41 <jillr> Red Hat generally has an initiaitve to audit and change problematic language in our own tools and in the communities we participate in
19:07:42 <samccann> on this one, I'm wondering a few things.
19:07:45 <jillr> #link https://www.redhat.com/en/blog/making-open-source-more-inclusive-eradicating-problematic-language
19:08:06 <samccann> like if there is a list internally that RH is focusing on, should we/could we share that through this group?
19:08:46 <jillr> like a word list? (which I think we do have internally)
19:08:56 <samccann> yeah that would be a great start
19:09:29 <samccann> especially as some of those words are also code  like black/white lists and replacing them with deny/allow etc
19:09:42 <jillr> I would assume so, I would guess we were also sharing those resources with the inclusive naming initiative
19:09:47 <jillr> #link https://inclusivenaming.org/
19:09:53 <samccann> And we also have what Ansible core has already done.. we could pull out the kinds of things they changed as examples etc
19:09:57 <jillr> they have a public word replacement list
19:10:36 <jillr> there's also an IETF working group with word lists
19:10:38 <jillr> #link https://tools.ietf.org/id/draft-knodel-terminology-00.html
19:10:43 <samccann> oh nice! yeah.  So what I'm hoping is that Ansible can act as an amplifier for all this.
19:10:56 <jillr> Do we just need to get these kinds of resources into the Ansible contributor/community docs?
19:11:00 <samccann> So maybe collection creators can also keep a focus on this
19:11:27 <jillr> or is this something we would want to make part of the inclusion criteria for the community ansible package?
19:11:28 <samccann> i think yes we should, but let's not stop at   just putting it in the docs.
19:11:52 <tadeboro> Just having a wiki page with such links would help people like me (collection maintainer/code reviewer).
19:11:54 <samccann> We could add it to the agenda for other IRC meetings for example... to extend awareness that this is out there
19:12:07 <jillr> maybe felixfontein can comment on that when he has availability
19:12:27 <samccann> yeah that's my thought - there are content creators who would use the info if  they had it or even knew it was available.
19:12:44 <jillr> we can get those links on the Diversity wiki easily, though for discoverability I think they should also go in docs (people might not think to look for the D&I wiki)
19:13:05 <samccann> And maybe we can sporadically mention it in the Bullhorn. Not every newsletter, but say once a quarter to remind folks etc
19:13:20 <tadeboro> Docs would be an ideal place. And I would not mind having a link to those docs in collection requirements.
19:13:38 <samccann> jillr: maybe we start documenting things on the wiki and we can add one link to there from the docs style guide for now
19:13:48 <samccann> then if it all settles down, we can move it into docs directly?
19:14:04 <jillr> Sounds good to me
19:14:30 <samccann> that way we can also link to it from the collection requirements etc
19:15:27 <jillr> I'm think the wiki can be edited by anyone (at least I'm not seeing a permissions setting), does something want to take that action?
19:15:30 <jillr> #link https://github.com/ansible/community/wiki/Diversity
19:15:36 <jillr> *someone
19:16:48 <samccann> I can take that on and get a link into the docs style guide that points to it. I'll need help on what to add in the wiki
19:17:06 <jillr> I can work with you on that, thanks
19:17:13 <jillr> #action samccann and jillr to add an inclusive language section to the Diversity wiki with links to resources
19:17:56 <jillr> #topic Ansible media and assistive technologies
19:17:57 <tadeboro> I would help, but unfortunatelly I will probably stay on the consumer side of things until things become a bit more ingrained in my day-to-day activities.
19:18:59 <jillr> This is an open question looking for ways to make our online presence more accessible, in things like Github issues templates and the like
19:19:25 <jillr> cybette found a repo with some tips on accessible design:
19:19:27 <jillr> #link https://github.com/UKHomeOffice/posters
19:20:30 <samccann> looks to be a very helpful site
19:22:58 <jillr> I guess a question would be, if this is something we want to work towards do we have anyone in the community with experience building accessible sites or services that can help?
19:23:17 <jillr> or is that a call for assistance that we want to put into the Bullhorn?
19:23:29 <samccann> There was a github issue? I think somewhere talking about problems with the issue template itself and screenreaders
19:23:51 <jillr> yeah I thought it might have been linked in the agenda issue but I'm not sure where that was now
19:24:15 <jillr> I guess step 1 would be finding someone to help us evaluate what we're even missing today
19:24:16 <samccann> maybe we should list out areas where accessibility comes into play?
19:24:42 <jillr> which IMO should include users of accessibility tech
19:24:49 <samccann> There is an internal (RH) checklist on accessibility for docs. that's something we can convert and put 'somewhere useful'
19:25:53 <jillr> I know there's a few a11y (accessibility) initiatives internally, not sure if any of them have already produced public content we could use
19:25:55 <samccann> +1 for asking for help in the bullhorn and asking folks to drop in here
19:26:34 <jillr> #action jill to add a call for participation in the bullhorn
19:27:35 <samccann> what is a11y stand for?
19:27:49 <jillr> accessibility - it's "A", 11 letters, and "Y"
19:28:02 <samccann> HAH clever!
19:28:04 <jillr> it's kind of like using k8s for kubernetes
19:28:15 <jillr> or o11y for observability
19:28:31 <jillr> so you can cram more words into a tweet  ;)
19:28:54 <tadeboro> I think locallisation also has one of those (at least I think GTK+ project did have it - waaaay before twitter ;))
19:29:09 <jillr> oh right - il8n
19:29:20 <tadeboro> Right, that one.
19:29:30 <samccann> heh
19:29:31 <jillr> for internationalization (however than works out)
19:29:47 <jillr> I think, anyway
19:30:34 <jillr> so we'll ping the bullhorn and see if the community can help us with this topic, and see if there's any internal RH resources we can use
19:31:13 <tadeboro> I think bullhorn goes out today? So maybe we should ping cybette directly?
19:31:24 <tadeboro> Or wait until next issue.
19:32:03 <jillr> looks like the draft is already put together and it's late where she is, it's ok IMO to wait for the next issue instead of making her scramble with changes
19:32:42 <samccann> yeah next issue is cool
19:32:46 <jillr> #topic Contributor covenant CoC 2.0 for collections
19:32:56 <cybette> (thanks :))
19:33:13 <jillr> did everyone get a chance to review this CoC?
19:33:55 <felixfontein> sorry, have been afk until now
19:34:08 <jillr> no worries, you're just in time for the big topic  :)
19:34:30 <samccann> read it... not that familiar with other CoCs so might just be lurk and learn mode for me
19:35:35 <jillr> I read it and I have really mixed feelings, I'll let other people have the floor first though
19:36:04 <tadeboro> I did go through it and got a bit uncomfortable when I hit the enforcement guidelines. Compared to other CoCs, it felt wrong, but I cannot explain why exactly.
19:36:35 <jillr> oh, I should have linked it:
19:36:39 <jillr> #link https://www.contributor-covenant.org/version/2/0/code_of_conduct/
19:37:26 <samccann> this line worries me `Focusing on what is best not just for us as individuals, but for the overall community`
19:38:17 <samccann> that ^^ feels like an excuse to keep the unpleasant person in the community because they produce a lot of code, and say the individual who is upset by said person has to suck it up for the sake of the community
19:38:25 <samccann> but could just be the way I'm reading it
19:39:55 <jillr> I also have issues with the Enforcement section and wrote a small novel's worth of notes about it  :)
19:40:32 <tadeboro> I also read that part as "take one for the team", but I did not think much about it because I am a naive and still think people are good by default.
19:40:34 <jillr> I'll try not to just info dump, but since folks were feeling similarly,
19:40:39 <samccann> heh just finished reading the Enforcement again.
19:40:51 <jillr> It dictates a sequence of harms someone can cause while still remaining part of a community, there's not a lot of room for a safety team to first-strike eject someone for really severe wrongs.
19:41:33 <jillr> Forced apologies that are not sincere aren't really apologies, an apology ought to be part of an acknowledgement of harm and part of a reconciliation (IMO)
19:42:19 <jillr> It opens the door for a community to say a safety team is in violation of their own CoC if they escalate faster than this prescribes
19:42:20 <samccann> yeah I'd rather see something like 'the community leaders will take action that can vary from a warning/private discussion to banning from the ocmmunity based on the severity of the incident(s) and impact on the health of the community.' or something like that
19:42:49 <jillr> If this was the CoC for a specific community who had decided these enforcement guidelines were right for their community and wanted to enshrine them in their CoC that would be different - but this is a generic, reusable CoC that thousands of diverse communities use for different types of communities.
19:43:06 <jillr> Folks who adopt this may not have really given it any thought and may be unprepared to actual deal with violations
19:43:24 <jillr> exceptionally minimal input - the overwhelming vast majority of the text appears to be the work of one person.  I can see lots of ways the enforcement section can go wrong in a multitude of communities and scenarios and am sure I'm missing many.
19:43:40 <jillr> oops, bad copy-paste -
19:44:00 <jillr> I'm concerned that from the git history this appears to have been written with exceptionally minimal input - the overwhelming vast majority of the text appears to be the work of one person.  I can see lots of ways the enforcement section can go wrong in a multitude of communities and scenarios and am sure I'm missing many.
19:44:12 <jillr> and sorry - I did info dump after all :)  I'll pause to discuss
19:46:09 <samccann> so I agree the enforcement section is not something I'd want in Ansible's CoC for example. It's too specific when dealing with problems needs the ability to act/react  based on what's happening, not what is enshrined in the CoC enforcement.
19:46:46 <samccann> But I missed the last meeting - is this because a collection is using this CoC? that we want to recommend it to others (or wanted to before the current version came about?)
19:47:14 <tadeboro> I guess my main problem with that CoC is that it reads as a law.
19:47:41 <jillr> samccann: the Contributer Covenant CoCs are provided for the purpose of anyone being able to adopt without having to write their own,
19:48:07 <tadeboro> samccann: No collection is using this CoC, but since we reviewed one of the previous versions, we though we might as well approve/reject this one too.
19:48:09 <jillr> we had a collection show up using v1.4 already. So we thought to review and pre-approve (maybe) v2.0 to expedite the process for the future
19:49:04 <jillr> various versions of the CoC are reportedly used by thousands of projects/communities, so it seemed like a good idea
19:49:04 <samccann> jillr: so while i'm not in favor of adopting the CoC (v2), I'm not sure I'd tell a collection owner to not use it either.
19:49:25 <jillr> but would we accept into the community ansible package a collection that was using this CoC?
19:49:38 <samccann> maybe I'd mention "are you sure? that Enforcement section is very prescriptive'
19:50:37 <jillr> that was my lingering question, "how do my concerns about this CoC balance against the effect of Ansible blanket rejecting any of the very many communities who adopt this CoC from being in our extended community?"
19:51:39 <samccann> yeah my gut feeling is if it is at least as good as our own CoC, we shouldn't reject it. The enforcement is on them, not Ansible, right? or is it by default also on us because it's part of the Ansible package?
19:54:06 <jillr> I'm trying to find which community meeting we decided we wanted to do CoC reviews in, so I can get those logs..
19:54:46 <tadeboro> The list of adopters is quite large: https://www.contributor-covenant.org/adopters/
19:55:00 <jillr> I think it was here:  https://meetbot.fedoraproject.org/ansible-community/2021-01-13/ansible_community_meeting.2021-01-13-19.00.log.html
19:56:30 <tadeboro> I have a feeling it was earlier. The sensu.sensu_go collection I help maintain was one of the reasons, and I have a feeling we discussed this right after 2021 started.
19:56:40 <jillr> we also discussed in this channel in https://meetbot.fedoraproject.org/ansible-diversity/2021-01-07/ansible_d&i_wg_agenda:_https:github.comansiblecommunityissues577.2021-01-07-19.01.log.html
19:56:55 <jillr> yeah there's been several discussions in a few places
19:57:26 <jillr> and github is truncating the community meeting agenda issue so ctrl+f'ing is only doing so much  :)
19:58:46 <jillr> but, at some point we discussed and generally agreed that we cared that collections in the community ansible package had a CoC, and that the contents of that CoC was to our standards
19:59:17 <tadeboro> https://meetbot.fedoraproject.org/ansible-community/2020-12-16/ansible_community_meeting.2020-12-16-19.01.log.html is the one I think where things started.
19:59:28 <jillr> We're assuming that at some point, a collection will likely show up using this CoC and we had mixed feelings about it last meeting when we started to discuss it
19:59:32 <jillr> thanks tadeboro
19:59:51 <tadeboro> 19:48:40 is where the CoC discussion started.
19:59:57 <samccann> have to drop for another meeting. I'll review the logs later. thanks!
20:00:33 <jillr> I feel like right now, specifically regarding the contributor covenant CoC v2.0 we're undecided,
20:01:16 <jillr> should we wait until a collection shows up and asks to be included that uses it (which might not ever even happen) or continue to evaluate it now?
20:01:30 <tadeboro> Maybe we can leave it unapproved for now and deal with it once we have a candidate that uses it?
20:01:53 <jillr> I agree with that - we could spend many many hours on this and never have it be needed
20:02:11 <tadeboro> +1
20:02:15 <samccann> +1
20:02:18 <jillr> I still like the idea of pre-approving common CoCs IF it's a simple task to do, but this doesn't seem to be the case here
20:02:21 <samccann> (meeting hasn't started yet :-)
20:02:45 <jillr> #agreed - we will leave the Contributor Covenant CoC 2.0 unapproved, and will revisit as needed
20:02:47 <samccann> yeah we can list some 'common CoCs we like' somewhere
20:02:55 <jillr> I think that^ was the goal
20:03:34 <jillr> Fedora has a list but we wanted to do some reviews ourselves instead for our community of just adopting someone else's list
20:03:46 <jillr> #topic open floor
20:04:26 <jillr> I think it's just me and tadeboro now, but in case anyone has anything for this meeting  :)
20:04:53 <tadeboro> While I was comparing the Contributor Covenant, I also stubled upon https://meta.wikimedia.org/wiki/Universal_Code_of_Conduct/Draft_review
20:05:08 <jillr> oh interesting
20:05:15 <tadeboro> No action required, I just though it may be interesting for the public here.
20:07:00 <jillr> thanks - wikipedia has some really interesting things to address that free software doesn't so much, it'll be interesting to see how that evolves for them
20:07:26 <jillr> I think that covers everything today then.
20:07:33 <jillr> thanks everyone for attending!
20:07:42 <jillr> #endmeeting