Proposal: contributor-announce mailing list

Earlier this week, Matthew and I were discussing the idea of a “contributor-announce” mailing list that would seem to fill a gap in the existing communication tools. You can think of it as a parallel to devel-announce, but for topics that are more broadly-applicable. It would be for “internal” announcements that don’t necessarily apply to the user community served by the announce mailing list.

Some announcements that would fit on this list:

  • “Major” Council policy proposals (like the recent content license and Code of Conduct proposals)
  • Upcoming contributor events (Flock/Nest, etc)
  • Creation of new teams
  • Service outage notifications

Like announce and devel-announce, it would be moderated and use for broadcast-only. Messages should include a pointer to the appropriate place for further discussion. The idea is to not replace existing mailing lists, this forum, or the Community Blog. It’s a way to augment those for people who don’t normally follow them.

The main challenge I see is how to initialize the recipients. We don’t have a single place to announce this list (which is why it should exist), so we can blast it to as many existing places as we can think of. Alternatively, we can get a list of every email address with an FPCA and bulk add them with an intro message that clearly states the purpose and provides instructions for opting out. The latter is more effective, but feels icky. The former I fear will mean nobody signs up for it and the list will be useless.

In either case, we should try to make sure we encourage new people to join the list (perhaps in the account creation UI). I don’t think it’s necessary to prohibit (by policy or by practice) unsubscribing from the list, but we should set the expectation that if it was announced on the list, you’re not allowed to say you weren’t informed.

I’m adding this to the agenda for tomorrow’s Council meeting, but I wanted to get the conversation started here.


I think we should initialize the list with the subscribers to devel-announce, because in the past, we have used devel-announce for many of these kinds of announcements. In many ways — I argue, in the ones that count — this is a split of that list more than a whole new one.

That’s a reasonable middle ground. It wouldn’t cover the non-development audience (which is a topic in Mindshare 197), and I worry that we’d still end up missing a lot of those contributors if we require them to take action to subscribe. In other words, we’d just end up with a second devel-announce. One approach could be to watch the relative subscription numbers and repeatedly remind the non-devel mailing lists if contributor-announce is not significantly higher than devel-announce?

1 Like

Wouldn’t it be simpler to automatically forward mails from contributor-announce to devel-announce ?

So devel-announce would be (in content) a superset of contributor-announce? I think that’s more confusing and more work long-term (“If you subscribe to devel-announce, make sure to unsubscribe from contributor-annoucne, or else you’ll get duplicate messages.”)

I think the list is a good idea. :slight_smile:
That said, people LOATHE being subscribed to things they didn’t subscribe to, so IMHO we should just let it populate organically and try and advertise it well and periodically.
Some guidance of what service outages should go where might be welcome from the infra side. I guess most of the ones we send to announce now could go to this new list (since we try and not affect user type things ever, ie, mirrorlists and such are never down if we can help it).



I foresee all of the announcements going to contributor-announce except mirrorlists, websites, and maybe Pagure. If we move forward with this list, I’ll make sure we come to agreement with the Infra team about how to route outage notifications.

 /                                                 \                                                                                    
| Indeed, people do not like automated subscription |
               \\              .-'` `}
                \\    _./)   /       }
                    .'o   \\ |       }
                    '.___.'`.\\    {`
                    /`\\_/  , `.    }
                    \\=' .-'   _`\\  {
                     `'`;/      `,  }
                        _\\       ;  }
              jgs      /__`;-...'--'

I kinda think this would be a perfect topic for a small survey, cause I am not sure all people would like more mails. Of course, the survey would need to be announced, and so would benefit from having a communication channel first.

1 Like

FWIW, the contributor-announce list sounds reasonable to me. I didn’t know that the devel-announce or announce mails lists existed. Even now though, I probably won’t sign up for the devel-announce list because I’m not a Fedora developer nor the announce list because I don’t know what all it will send me. If the announce list is just going to send a bunch of notices about releases and test days, that isn’t all that useful to me. It sounds like the contributor-announce list might be for information about the tools that I use that won’t be available anywhere else. So, since it is potentially useful to me, I’ll sign up to the contributor-announce list. :slightly_smiling_face: Just my opinion.

1 Like

devel-announce has moderately high traffic for an “announce” list — roughly a message a day on average — and covers things like potential new Fedora Linux features via the Change process. So, yeah, I see that as being a lot for many Fedora contributors mostly active in other areas.

1 Like

I am 100% behind communicating these things in more places where our contributors will see these messages, regardless of platform preference or tool.

Why not use the announce list for this purpose? I have always believed this list is sorely underused, and its purpose was never clearly defined. Should we start this conversation again in a new decade, I would like to hear why the announce list is not sufficient for this purpose, as the only general-purpose mailing list in the project.

Perhaps I am also exhausted by the idea of subscribing to more mailing lists in 2021. To give a concrete personal reason, my email provider caps the number of active email filters I can use at once, and I have already hit the maximum (thanks to Fedora :slightly_smiling_face:). I will not subscribe to new lists because it will come into my personal inbox, unfiltered and untagged, and it’s not really how my email habits and workflow works. So, it ends up irritating my OCD.

This is a deeply personal reason, but it’s the truth for me. I want to use announce for these topics.

So that was my original suggestion. Matthew felt we should have a distinction. announce is generally for outward-facing announcements, whereas this list would be for contributor-specific information. Think of it as the same CommBlog and Magazine distinction. Although contributor-announce wouldn’t be high-traffic, it would be higher traffic than announce, which might drive away people who just want to know about releases and other user-facing announcements. So I think the audience distinction does make sense, although there’s definitely a case that it’s not a problem worth solving.

I’m not sure I agree that announce is underused, but it is certainly under-specified. I think defining the scope of that list is a useful side effect of this discussion.


I am stubbornly of the opinion that these topics should be outward-facing announcements. :slightly_smiling_face:

We formalized the name of our deliverable, Fedora Linux, to be clear that we produce more things than just a distro. The Fedora Community does many useful things, the most well-known and recognized of which is a Linux distribution.

We should use our existing list to be better about externally communicating the message that we are more than just a Linux distro. If that pushes some people away… maybe they weren’t really interested in what we do after all? :man_shrugging:

In 2021, I thought using mailing list alone cannot reach all contributors anymore.

Arrangements like, auto-forward between the mailing list and a Category in Discussion.fp.o, should be able to reach more contributors.

Some contributors will always use email. That is not a bad thing. It is not shameful. We have used email since Day 1 of the Fedora Project. We will continue to use it, at least for a very long time.

It is not ideal, but I think this is best done manually by a program or community manager. It is time-consuming, I know (I used to do it in CommOps back in 2015-2017). I believe it is better to have someone know the places where contributors are watching, and go to different places to make sure the message gets out depending on the preferences of different types of Fedora contributors and where they “hang out” in the Fedora-verse.

Fedora is huge. :grinning:

1 Like

I am not saying to stop using mailing list - as I said using mailing list alone cannot reach all contributors. Mailing list is still important until a viable replacement is available (which it might never happen).

1 Like

You mean this would be the perfect topic for a small survey ?

Where/how should we announce contributor-focused news as described below?

  • On a new contributor-announce mailing list
  • On the existing announce mailing list
  • Some other way (reply with your feedback!)

0 voters

I understand where you’re coming from, but remember there are thousands of times more Fedora Linux users than Fedora contributors. I’d love to increase the ratio, but I don’t think the announcement list is a tool to do it.

As a user or customer of other things, I appreciate when I’m able to sign up for granular announcements … I want notices of the things that affect me, but don’t have time for everything that’s going on. Our user community should have that option too. We can try to tempt them in (perhaps by advertising the contributors-list in the footer of every announce-list message?), but I don’t think we should significantly increase the volume of announce-list traffic. The threshold there should be more like the threshold for a press release. (And not a press-release from a desperate company that sends out a PR every time someone sneezes.)