Skip to content

Instantly share code, notes, and snippets.

@Tobotimus
Last active March 1, 2019 00:36
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save Tobotimus/ac8b6bfe852b17a4d50aa568fa9b8fc5 to your computer and use it in GitHub Desktop.
Save Tobotimus/ac8b6bfe852b17a4d50aa568fa9b8fc5 to your computer and use it in GitHub Desktop.
3.1 Roadmap

So, 3.1's been talked about for quite some time, but I'm guessing many people still have a lot of questions. Users asking "what will be included?", devs asking "what should I work on?", and QA asking "what should I be reviewing?". Hopefully this will help answer those questions, and a few more. It'll also be a bit of a test of my novice-like project management skills 😬

Whilst reading this, just remember a few things:

  • Goals are goals, not deadlines. Most of us have been around open source long enough to know deadlines are rarely adhered to πŸ˜„
  • A sprint/release having a particular focus does not mean everything which doesn't apply to that focus is going to be excluded or ignored. For example, if the main focus of a sprint is Audio, that doesn't mean a QA member is going to be forced to review audio PRs exclusively, or that all non-audio PRs are going to be ignored. We have lots of people involved in this project with a vast array of skills and interests, and I don't take that for granted.

Where we're at

How I'm picking which features are going to be focused on for this release are mostly based around these factors:

  • Who's available to work on the features and what their expertise is
  • Which features in 3.0.0 cause common issues
  • Which missing features are commonly requested
  • Which core features and enhancements are prerequisites for other important features down the line
  • What do our dependencies demand (deprecations, discord.py updates)

Based on these criteria, this is what's mostly going to be focused on for 3.1:

Audio

Audio is one of our most popular features, but also one of the most extensible. When 3.0.0 was released, Audio was great, but many planned features were not implemented yet. @aikaterna has been working on them consistently and is available to finish these features off in the near future. Lavalink is also one area which causes common, hard-to-debug issues, and could use some big improvements.

Cog base class enhancements

This is something which won't have a profound effect on cog creators or end users, but is necessary for planned future features such as context-based locale and a core scheduler. It's also important to catch up to discord.py and recent changes to its cog system. I'm available and willing to work on this over the coming period.

Mod, mute, temp-mute

The release needs something for users on top of what's described above, as audio is not used by everyone. There are some issues and PRs already open to work on this area. Whilst we've lost one of our most active and proficient contributors to this area recently, I think there are a few people still active who are willing to contribute to this area πŸ˜ƒ

Sprints

The development of 3.1 is going to be somewhat broken up into sprints. Each sprint will have a particular focus which will help propel a particular feature forwards.

Duration

The framework of each sprint will last for 2 weeks, with the sprint itself going for about 10 days. This allows a couple of days at the start of each sprint to organise what is to be included, and a couple of days at the end to assess how it went, and maybe do a bit of testing/cleanup/fixing if any issues slipped through. We might even do a pre-release!

Organisation

Sprints will have both an Epic for discussion about the focus topic and a GitHub Milestone to track what we're aiming to have completed.

Sprint 1 - Audio focus

Sprint 1 has sort of already been started off by @aikaterna - most (or all) of the actual "features" being focused on have open PRs, all that's needed for them is QA. I'll be working on some enhancements for internal Lavalink server management too. There are also a few other features/enhancements which aren't must-have but any contributors willing to open a PR for them will have the QA fast-tracked if they manage it within this period :)

Sprint 2 - Cog framework focus

This'll include some enhancements to the cog base class (such as more parity with discord.py's recent changes), CogManager enhancements, mostly internal optimisations and some features for cog creators. Cog creators have an opportunity to come forward and ask what they want to see improved about the cog framework, and it may become included in this sprint.

Sprint 3 - Mod and other features

What's included here will be dependent on what was achieved in previous sprints, and whatever consensus there seems to be amongst users and cog creators. Discuss below if you wish!

Some things we at least hope to include here are:

  • Mute enhancements
  • Tempmute
  • Modlog using warnings
  • Game-specific streamalerts

Roles and Responsibilities

Most of you are probably familiar with the usual faces and what people do, but I'm giving people responsibilities here based on their recent/expected activity and availability:

  • I'll be trying to manage the release, will work quite a few of the features, and try to fix all the bugs no one else wants to πŸ˜„ If you have any questions or ideas about the management, I'm happy to talk.
  • @aikaterna will be an important dev this release, mostly because of Audio. I'll be working closely with her to decide what will be included with regards to audio features.
  • Your usual friends from QA, @Redjumpman, @calebj, @aikaterna and our newest member @TrustyJAID are going to be testing and critiquing PRs included in the current milestone. If they wish to QA something not in the milestone, they can talk to me and I'll probably add it in :D

If I'm misjudging someone's availability and have left you out, talk to me πŸ˜ƒ

Risks

What happens when things go wrong or we don't complete the milestones on time?

As I said above - no deadlines, just goals. Things missing the deadline in open source is not uncommon. One thing we can do is make the 3rd sprint's milestone bigger or smaller depending on how long the first two milestones take. Unfortunately we can't whip people into work when things slow down 😈

Schedule

Here's a pretty crude and basic Gantt Chart which hopefully outlines a "schedule" but as I've emphasised, our schedule is pretty loose and it's OK if we don't stick to this exactly.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment