Skip to content

Proposal: Bevy Guest Lectures #1903

Open
@Trashtalk217

Description

@Trashtalk217

Currently, every 3 to 4 months the news section of the website lights up: A new Bevy release! This includes a massive blogpost with everything that changed between versions.

I love this blogpost, and I don't want to change it. There are however a couple of negatives to doing it this way.

  • Smaller features can get buried in the largeness of the release notes.
  • Efforts that span multiple releases get split up, making it hard to get a complete picture of them.

Given that the News feed is quite empty for the months between releases I'm proposing the following:

Bevy Guest Lectures

In Bevy Guest Lectures (BGL, name subject to bikeshedding), contributors can highlight some efforts they've been working on and go into more depth. These posts can have the following benefits:

  • Good PR. I've noticed that the Rust community (or at least the way I engage with it) likes blog posts and this can bring more attention to the engine.
  • Informing / Education: Learning is always a good thing, but these posts could also direct users to parts of the engine they didn't even know they could use.
  • Attracting contributors: By putting a spotlight on a specific effort we can direct attention and hopefully contributors to it.

Guidelines for BGLs

Everything is up for discussion, but these are some possible guidelines to keep to.

  • Don't shy away from technical details, but assume a general (programming) audience. Very few people know what GPU bindings are, or archetype moves for that matter. It's fine to talk about these things, as long they are explained first.
  • Don't make too many promises. The 'What's Next' section of the release notes has always been more of a suggestion than a roadmap and the anarchist development style of Bevy doesn't lend itself to strong commitments.
  • There shouldn't be more than one blog post each month. This is to keep them relatively special and not spam people with them. There may be less of them (I highly doubt that this will attract so much attention that we have to maintain a backlog), but this also serves to keep the workload low on the maintainers that have to review these posts. I am assuming that @cart or @alice-i-cecile will want to have final say about what's put on the website.
  • Common sense things like: don't use hurtful language / be inclusive / see also the code of conduct.

What BGLs shouldn't be.

Guest lectures shouldn't be used as documentation. If that is the case, this signifies that we're lacking in documentation.

One More Thing

I've been talking about BGLs as 'Guest' lectures, however, I've mostly been talking about internal engine developments. I think it's also nice to throw this open to third-party crate developers.

Let me all know what you think. And what sort of thing you'd like to read / write for something like this.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions