This Week/Month in Fedora: Could we do it?

Project Discussion
, ,
1

One thing we’ve been discussing for a while now and that we have as one of our targets for this release cycle in the Marketing Team is “better talking points”. Pretty much: we need better ways to know what the team’s been working on doing the release cycle so we can talk about whenever the release finally comes, so that even the less “eventful” (or even boring, in the words of some reviews) releases (like F39) can be hyped up. So here’s an idea which I’d love to know if it’d be possible, and would love even more feedback on how we’d do it:

A regular blogpost (weekly? monthly? who knows!)

A lot of FOSS projects do this already:

You get the point. It’s a really nice way for contributors and non-contributors to get to know better what’s been going on in the project during a certain timeframe. We already have something akin to it in our Community Blog, but the posting frequency is all over the place, since those are separate efforts:

Weekly

Monthly

Quarterly (Every 3 Months)

We also have updates from a couple of contributors in their personal Mastodon accounts, with @adamwill being the main example that comes to mind (I really like those).

That said, most of the project’s teams don’t have such a thing.

It’d be nice to have those merged in a combined blogpost[1], which could be contributed by any team inside the project, so it’d be less intimidating for a single contributor to share that “they’ve been working with a small part of the project this week”, for example.

If we do it in a similar fashion to GNOME[2], it could be as simple for a contributor as going in a Matrix room and sharing what they been working with in a simple chat message and sharing a couple of screenshots of their work. This could have the potential to make the work of contributors that work in less visible areas of the project more easily discoverable and more valued.

The potential challenges

  • Setting up the infrastructure necessary to gather these reports;
  • Gathering enough engagement from the contributors[3];
  • Moderation[4]
  • Curation[5];

Okay, but what’s the end goal with all of this?

Simple, making release notes easier. In the end of a release cycle we could simply look back into those posts and select what we believe to be more relevant to share. This way, both us from the marketing team and whoever reviews any release of Fedora (bloggers, youtubers, news journalists, etc.) have a better insight on what is new in any particular release beyond “new *insert favorite desktop environment here* version”, whenever a release isn’t full of flashy changes like DNF5 or the Anaconda redesign.

It’s also a great potential point of entry into the project as a contributor, as knowing more about the work different teams are doing makes it easier for someone to know in what areas they can contribute with, as well as that making the act of sharing the work you’ve done less rigid makes it easier for newcomers to feel like they can contribute too.

Totally not relevant part of text that you should **NOT** look into

The real reason behind all of this is because I’m salty that I frequently end up finding a lot of what’s going on in the project through Phoronix articles instead of directly through the project’s channels, even though I’m an active contributor.

  1. Which could even continue being in CommBlog instead of a separate website, like most of what the afforementioned projects do. ↩︎

  2. GNOME is a great example of how to do this correctly, as they have really well defined rules and an FAQ for what constitutes a “valid” contribution and a nice bot that integrates with a Matrix room. It’s the one I follow the closest, at least :sweat_smile: ↩︎

  3. Which is why I’m unsure on what would be the best posting frequency, since, if we go with weekly posts and those posts don’t have a lot of reports, it’d be best to go with bi-weekly or monthly, it’d depend on how well the teams in the project would engage with it. ↩︎

  4. Since, if we limit who can report something for the blogpost, we risk making it inaccessible for beginners, but if we don’t, we risk dealing with spam. ↩︎

  5. Making sure everything is formatted correctly, dealing with spelling errors, screenshots, etc. ↩︎

2 Likes
2

This is a great idea and I agree that it’s cool!

In my opinion, I think we should work with @amoloney’s effort to bring back the Fedora Friday Facts blog posts. We can beef that up, whether with structure or content, so that it matches what you’re envisioning for This Week in Fedora. She’s already doing the work and is committing to putting out something each week. We can help her by building on top of that and make it something that’s interesting for contributors and users.

How does that work?

Tangent on what news outlets publish
I think many times the main thing they publish that we don’t is change proposals. I agree that if anyone one should be a source for news on Fedora development, it should be us. Furthermore, I consider news articles that post our news before us as though they’re eating our lunch, and I feel super competitive about it because we should absolutely be beating them to the punch.

That being said, the news outlets post our stuff too early, in my opinion. Rather, they post about proposals while they’re still being discussed and as though they’re done deals. For some proposals, like the telemetry one and the KDE Wayland one, it can lead to more attention and feedback than is helpful and can get in the way of productive conversations. It can also lead to higher expectations of delivering something sooner than may actually be the case. For those reasons I’ve always waited until a change is approved before I start posting about it, while directing people to engage in the change proposal process more broadly.

But once a change is approved I want to be the first to post about it, lol.

3 Likes
3

Yeah, that’s pretty much what I have in mind. Instead of different teams having separate efforts in order to share what they’ve been working on we’d have a single place where everyone could do it.

Yeah, the Asahi Remix one was especially egregious, considering how much a ton of sources started parroting each other. Depending on how “rigid” (for a lack of a better term) we make this process, it could be a nice way for contributors to better explain the process behind a change proposal or their work in general.

4

In my experience, weekly is too ambitious, it will take too much work and it’s going to burnt out the one who is doing it.

1 Like
5

I agree, Bi-Weekly would also give more content potentially, and when not enough is out there it’s still a viable read.

1 Like
6

FWIW, I’ve found this is kind of an interesting dynamic. I’ve found my daily posts on Mastodon easier to maintain than a less frequent posting frequency. I never did a regular posting schedule for my blog, but I do have to write weekly status reports internally (at RH). When I wasn’t doing the daily Mastodon posts this was kind of a chore: I’d have to try and remember what the heck I did all week, generally by looking through Pagure and Github and Bugzilla activity reports and stuff. I’d usually forget things.

Now I just produce those weekly reports by summarizing the last week’s daily posts from Mastodon, which makes it way easier. I can usually write the daily posts from memory as I don’t often forget what I was doing at 8am by 4pm. :smiley:

So, I don’t think posting less often is always necessarily easier. It can actually mean you have to spend more time putting material together and dragging stuff out of memory banks.

It might be good to ask @bcotton how he found the experience of doing the Friday posts, if he has the time and doesn’t mind…

2 Likes
7

I would argue that most sites, and content creators do a good service to get a wider reach for the project, and that MORE should be advanced to partner creators to help get the word out. Fedora had a Blog of sorts on Destination Linux/Tux Digital a year or two ago. It’s a good avenue if done properly. With the right creators of course.

1 Like
8

The good thing is that we are also working on that front to some extent, this is an idea that isn’t 100% directly related but can make things easier for creators to understand what’s going on in the project without having to lurk in a thousand Pagure/GitLab issues, mailing lists and Matrix rooms.

9

I’m not sure I agree with this. Is the audience the same for all of those posts? If not (which I suspect but cannot prove is the case), then a combined post may end up being a big long thing that no one ends up reading.

If the end goal is making release notes easier, most of the examples you gave don’t serve that goal. In fact, I’d argue that none of do. So if this is your goal, perhaps yet-another-post is what’s needed. But how would that information be collected and presented in a way that’s different from what we do now?

10

I didn’t find them much at all, because I learned this lesson in a previous job. By keeping a running doc in git, I was able to make most of the updates as part of doing something else. Processing changes? Update the doc! Sending blocker status summary? Update the doc! See an email about a conference CfP opening? Update the doc!

Like Adam’s daily Mastodon posts, it was easy because it was constant (in fact, it was more constant, because I wasn’t doing it at the end of the day)

1 Like
11

It’s kind of like, Don’t wait till the last minute to do things, because then they become a chore. Make it a continual part of the process, and implement tools and strategy to simplify this as you go.

And voila ! A simplified process, that if used to direct layman’s towards would allow for more consumption and awareness ! :tada:

This is precisely why you let a Writer, craft the blogpost and not a Developer. The Blogpost should read like a story and not like Release Notes for the latest release of Fedora 50.
Example :
I’m an Analyst by trade (BA/DA), my weekly reports had to be to the point, precise and presented with graphs and tons of analytics. When I contracted as a Business Analyst, those reports ( or collection of reports ) read more like the story of the week, A couple well placed slides, and the story. Keep engagement up, keep heads nodding :white_check_mark: .

1 Like
12

The thing is, this doesn’t need to necessarily replace the longer, more detailed blogposts the teams usually create. It would serve as a place for contributors to share their work in a quick and small fashion (akin to what @adamwill does). So, if a team wants to write a big blogpost on what they’ve been doing, they could do it and use This Week in Fedora to share it with more people instead of doing the big report inside of it. It would be work related to Fedora, and it would be useful for people that want to follow the work done in Fedora (which would be the target audience for this).

We’d need to have well-defined rules for what counts as a Fedora-related contribution (for example, would work done by a Fedora contributor in an upstream project count?[1]), but I do believe it could work.

I’m using GNOME as an example a lot in this, but it is precisely because this format has worked so well for them. The work done is This Week in GNOME seems to help:

  1. developers to more frequently work with writing about the things that they’ve worked on;
  2. users follow small bites of progress done in the ecosystem;
  3. content creators more easily follow and share what’s been going on with the project[2]
  4. in the end of a release cycle, it becomes useful as a way to remember what exactly was done during this release cycle without having to scour through commits of the projects one works on

I’ve been following TWiG ever since it started, and although not every week is full of content, and not all reports in each week will be interesting to everyone, the format is done in a way that it really helps the community see the work being done in close to real time in a way that’s really healthy, so even if a report isn’t interesting you can just easily ignore it and read the next one.

We could use it to complement the way release notes are created or to use it as part of its base, where the writers would later go on and add detail to them.

  1. I think it should, and I believe it would help so much to show just how much work our contributors put into making upstream better ↩︎

  2. For example, The Linux Experiment usually go over some of the reports in each week’s TWiG on his weekly open source news videos ↩︎

13

I’ve started putting my time where my mouth is and started doing weekly updates on the work I’m doing as part of the project on my Ko-fi. Hopefully the format I have in mind can be better understood by reading it.

I’d love to at least expand that to something official from the marketing team and at best expand it to something from most if not all teams that wish to take part in it.