Reducing Maintainer Burden

[AngelOnFira]

So I just want to open this to discuss potential ways to streamline the process of editing the newsletter, and maybe analyze things that can be done better on the WG side as well.

1. Try to automate more
   • Discussed in AI automation for newsletter #1384
2. Try to find more maintainers
   • This takes time, and finding people to contribute for longer periods often starts best by getting people to just be active periodically.
3. Try to incentivize people who want contributions to start helping
   • I could probably find students at my university that would be interested in doing this. It's "lower hanging fruit" in terms of working on open source, but it's a great way to learn about Git flow.

Templated Sections

For items like the Game Dev Meetup and Veloren, I will always just copy content from the previous month and start from there. Maybe setting up a base template for each month that GitHub actions creates could speed things up a bit here? Sections could just be removed that don't have content for that month.

Related discussions

• This is stemming a bit from discussion in Rust Zulip about the new #launch-pad team led by @thejpster (discussion can be found here).

[17cupsofcoffee]

I think a lot of these discussions have focused on 'how do we make the current process work' - I think it might be also be useful to think about 'what could we change', unpalatable as some of these changes may be 😅

Reduce the level of detail (and/or standardize section content)

Compared with This Week In Rust (and other similar newsletters I've seen like Haskell Weekly), the individual sections in our newsletter are very long, and don't really have a standard format - or at least not one people stick to. Those other newsletters actually look a lot more like our 'extra news' section, now that I think about it.

While I don't think we should go quite as terse as TWIR (for one, we can't really avoid having images given that games are a visual medium!), I think we could potentially simplify contributing and reduce the amount of review comments if we were a bit more strict about the format.

(I would be much more in favour of this than relying on an LLM to 'pad out' sections, tbh - I feel that introducing any kind of AI tech to the process is going to make things worse, not better)

Be more strict about the cutoff dates (and don't do people's work for them)

A lot of the time people leave submitting their sections until the last minute, which leads to one of two scenarios:

• The newsletter gets delayed, putting us even further behind next month.
• One of the editors ends up writing the section instead, which is extra work for them.

IMO, we should just leave the section out if that happens, or move it to 'extra news'. It'll keep the schedule from slipping, and it gives people more incentive to actually submit their sections on time.

[cybersoulK]

is there a way we can monetize the newsletter?

i am not sure how much it can draw with donations alone. Or work with some institution to spread the newsletter more?
Then we can pay the top contributors for their efforts, and there is more incentive to keep up. It's hard to replace them with a random guy at the university, because they are not into the rust ecosystem.

For example, the only reason i published Cybergate to this newsletter was because ozkriff researched, found me and invited me. AI or a random guy cannot replace this. And also if someone tries to submit a PR unrelated to games, or in another programming language, there must be someone with domain knowledge / community awareness that presses all the links and checks them out.

This is to keep the newsletter reputation at the highest level possible, so both readers and writers feel motivated to follow it.
And also keeping it on time is extremely important. Skip a month if need be, but the issue to contribute should open at 25th of each month and be published for readers by 1st.

[Vrixyz]

I think a stricter release train is the way to go:

timeline
    title This Month in Rust Gamedev News
    1st : Release previous news entry!
        : (Release) social media posts, 
        : (Release) links to discussions
        : Add a draft of next month's newsletter
    2nd-27th : Contributor creates an issue
        : Community/editors review
        : Merge into source
    28th : PR freeze<br> Expect any pending PRs to be reported.
         : Last touches<br>global review pass

Any pending PRs after 28th should be treated as either:

• reported to next month (default expectation)
• An added section for "future news" might be interesting, linking to the pending PRs for aditionnal visibility to this repository
  • "Your news" as a call to action

If we want a less "strict" release train:

• "Easy" PR might be merged and edited if need be
• Complex PRs should not be expected to be merged, but might be with heavy edits/removals to make it simpler/fit the editor's whims

[ElhamAryanpur]

Oh I love this timeline, especially the future news section!

A strict timeline as proposed gives a lot of time for the entry authors too, along with people who want to start contributing.

[janhohenheim]

@Vrixyz great outline. I'd like to adhere as much as possible to this moving forward.

[janhohenheim]

Right now, the call for actions + reduced lints is working really well. We're getting quite a few contributions from interested people without pinging them first, and most passed the CI on the first try or only required trivial edits by me that took about 20 seconds, which is completely fine for me.
The schedule outlined by @Vrixyz is now in place, so I won't accept any contributions after the 28th. They're part of the next month.
I'll see how high the burden is once the editing period starts, but it seems to me like this issue can be closed in favor of only leaving #1384 :)
I'll come back after the April newsletter has shipped and we started the May call for submissions.