Discussed in 2023-08-30 meeting in #meeting:fedoraproject.org. No logs due to lack of Meetbot infrastructure, see Fedora-Council/tickets#463.

The consensus was to take more time to read, review, and add comments here. We would review this PR in the next meeting, and then also kick off the Policy Change Policy for a public comment period after the next Council meeting.

One point brought up by @bookwar was on the challenge of defining "Fedora leadership groups." A definition for that is hard, and might be out of scope for this policy. We might not want to do that here, right now. Her proposed edit is to remove mention of "Fedora leadership groups" altogether, and instead simply list the four groups that would be impacted, i.e. Council, FESCo, Mindshare, DEI.

See this commit with a proposed edit: s/Fedora leadership groups/Specific Fedora Committees and Teams

I do not like this edit though. I think it dilutes our message and I feel like we are avoiding calling any group or team a "leadership group", when I think we actually need that firmness… does anyone else have thoughts on this?

It is unclear to me how we define "active presence". The way the document presents it, the interpretation is left to the reader and given the subjective nature of active presence, we could find ourselves in a communications problem.

As a member of Fedora leadership, I would like a more clear definition of what we mean by active presence. Surely we don't mean 24/7, 365 days a year.

My preference would be that we lean more in to discussion.fedoraproject.org as the official mechanism for communications by leadership groups to the project. I would like to see chat.fedoraproject.org clarified as both synchronous but also ephemeral. If leadership groups use chat.fedoraproject.org more heavily than discussion.fedoraproject.org, then we begin to exclude certain groups in Fedora purely based on time zones and when people are awake and "Fedora'ing".

As for active presence, I feel the expectation should be that leaders are expected to review discussion.fedoraproject.org daily or as frequently as possible. Leadership groups can come up with their own schedules if they want to. Leaders should focus on keeping up to date with topics and posts in their discussion.fedoraproject.org sections as a first priority and then the entirety of the project as a secondary.

For chat.fedoraproject.org, I would prefer that we ask leadership groups to publish available hours for chat depending on the makeup of the group. And refer community members to discussion.fedoraproject.org as a primary mechanism.

Clever use of a docs macro, but I don't love how the practical result is to repeat "Fedora leadership teams" three times in the first paragraph. It feels a little too much like generated text. This is a minor complaint for a policy document, but still, I'd love for it to feel a bit more human.

The rendered version you showed has this a "Fedora Leadership teams". Is this a change, or is that defined somewhere else? In any case, I think we should spell out exactly what is meant by the term near the beginning of this document somewhere -- I know it's not a long doc but it feels kind of inverted to learn the definition later.

MInor wording quibble "benefits for ... to" is awkward phrasing. I suggest changing this line to
"When leadership teams use our common platform, this:"
and then changing "Set" to "Sets" in the lines below, to match grammatically.

This expands to "Therefore Fedora leadership groups should be leaders", which is a tautology. Suggest just striking this line.

s/models/a model/

Perhaps add "Other Fedora teams are also encouraged to follow this policy, but are not required to."

"heavier weight in terms of outages" and "degree of uptime reliability guaranteed" are the same thing, aren't they?

I think we should also add that they use open source software under our direct control, rather than third-party and proprietary apps or websites.

s/person(s)/people/ -- too legalese otherwise.

I feel like this is a "that escalated quickly!" line. I wasn't expecting antagonism. Do we need to say this at all?

Likewise, do we need this? It feels hostile.

The Fedora Mailing Lists are still official. Please do not omit it.

The Fedora Council reviewed this Pull Request as well as the wider context around the issue at the Council 2024 Hackfest. Before adopting any kind of formal policy or official documentation, we agreed to focus on building more mindshare in the community for Matrix.

@dcantrell and @rwright were going to team up to write an article about Matrix clients available in Fedora for the Fedora Magazine.

I took an action to improve the Communications doc page using old wiki pages that document best practices that are still relevant in a Matrix world.

@amoloney and I will work on a Community Blog post to start a discussion about the IRC/Matrix situation, where we are at, and what we are doing to improve the current situation.

Per the arduous arc of this policy PR, this was too heavy-handed of an approach for how we handle communications. And with the upcoming git forge migration, this provides an opportunity to rethink how we onboard people into the Fedora community. Instead of mandating this in policy, I hope we can aspire to unify our contribution places behind fewer tools so that people do not have to wonder so much how they get a maintainer or developer to check in.