process proposal: roadmaps

[crsaracco]

rust-vst process proposal: roadmaps

Hi all! This is mostly aimed at the maintainers of rust-vst (i.e. the rust-dsp group), but anyone reading this should feel free to share their thoughts as well.

I've seen a person or two in the Telegram chat confused about the future of the rust-vst crate, and a roadmaps process was one of the suggestions that fell out of that discussion. I think having one would help to do at least two things:

1. "Radiate information": Users that are just finding the crate can quickly get an idea for where the crate is headed in the future, and might be able to find where they can contribute their own efforts if they want to help out.
2. Maintainer focus: It will allow maintainers of rust-vst to focus on what's important for the next release (what's in-scope vs. what's out-of-scope), and be able to more easily reason about the overall direction of the crate when considering what to work on, what to merge into master, and how to organize/prioritize issues in the issue tracker.

Many contributors of rust-vst (and open source software developers in general) feel like they don't have too much time per-day to work on the crate; I think having roadmaps would help us to ship stuff faster and more regularly, as a result of the above list.

Roadmap content

The idea would be to formally decide on things that are in-scope / out-of-scope for the (near) future of the crate. If these are written down somewhere, it makes approve / ignore for now / reject decisions on PRs a lot simpler.

How exactly the roadmaps are written is up in the air; I like how Raph wrote his druid-shell roadmap here, but we could also decide to go into finer detail as well -- for example, listing out each release version (0.1.x, 0.2.x, ...) and deciding what's in or out on that level.

Roadmap decision process

Since these roadmaps will be deciding the future of the crate (at least for the near term, if not longer), I feel like we should come to a vague consensus of some sort before one's finalized. Obviously, we can always change directions later if we see fit.

How do we want to go about discussing what should go in them? I see two obvious ways to do it, but there could be more:

• Write up roadmap proposals in the issue tracker, similar to what Raph did in druid-shell, and discuss them there.
• Have a roadmap.md file (or something similar), just create PRs on that document, and discuss the changes on the PR.

How do we want to do the approval / rejection process?

• Simple majority vote: if >50% of the rust-dsp group votes "yes", then it's finalized
• Something else? (some way to include the greater community?)

Side note

While writing this, I rediscovered the "Milestones" feature of Github. Maybe we could use that to store the "final results" of the process? Would it show enough visibility to users?

Discussion

• Roadmaps: yes/no?
  • If no, is there anything we could do instead of them? Or is the current process fine as-is?
• What should a roadmap look like? What all should be included in one? Should it be "here's the general direction of the crate", or "here's exactly what we want to release for version 0.4"? Maybe a little bit of both?
• How do we want to formally decide on roadmaps? Where should agreed-upon roadmaps go so that users can easily see them?
• Is there anything I obviously missed in this proposal?

I have some ideas on actual roadmap contents: what we could do for the near-future (next version or two), but I'll sit on those until we decide if we want roadmaps, and how we want to do them.

[Walther]

Excellent writeup!

Some comments on the very practical grassroot level:

• roadmap.md and PRs on that sounds like a very low-friction approach 👍
• I like the idea of using the Milestones feature you mentioned 👍
• Projects could also be used to organize ideas:
  • wishlist lane for new issues / new ideas (GH Issues can auto-integrate with the Projects!)
  • prioritizing those to milestones / goals (we could even have a separate project board per milestone/release?)
  • easy for people to grab things from priority queue to implement
  • when all things have been reached for a milestone, release time!

[raphlinus]

This isn't exactly the type of feedback requested (which is mostly about project governance), but I'm going to post a series of questions I'd like to see clearly answered in a roadmap doc:

• Is the crate committed to thread-safety? I.e. is it acceptable to release a crate that has a safety hole.
  • If so, what are the review / validation / testing steps to achieve this and to avoid regression?
• Is the crate committed to the "time waits for nothing" principles, which can be defined as no locking, allocation, or anything else on the processing path that adds significant latency variation?
  • If so, what are the review / validation / testing steps to avoid regression?
• Is the scope of the crate to be a minimal type-safe wrapper around the VST 2.4 (pseudo-)spec, or are there other services in scope?
• Is it a goal to make plugins easy to write directly in rust-vst, or is it anticipated that there will be more ergonomic wrappers (of which easyvst is an early attempt)?
• To what extent is it important to preserve existing code and tutorials written for pre-alpha versions of the crate?
• To what extent is clarification of the (pseudo-)spec in scope for this project? Many aspects of VST seem to be based on convention, the extant documents are often vague, and Steinberg is a particularly adversarial steward of the (pseudo-)spec.
• Is the primary focus the writing of plugins, or do we want to actively support hosts? Should those functions be in the same crate, or separate?
• Which platforms does the crate target? Which architectures? x86_64 only, or possibly 32 bit x86 and ARM variants?
• Does the crate have an opinion about which GUIs it integrates with? (Aside, of course, from the tricky technical requirements of being a VST plugin GUI, which require an "attach" API to create a view, and likely a synchronous event loop; these requirements seem incompatible with winit and any GUI built on top of that).
• Does the crate have an opinion about which lock-free queue structure it uses to convey parameters and other data from the GUI and other threads to the real time thread?
• Does the crate have an opinion about what DSP graph running strategy is used?

These last three questions overlap with roadmaps for (in some cases, potential) crates that could be layered on top of rust-vst. For each of those efforts, there is a reciprocal question, possibly out of scope for the rust-vst roadmap itself, but likely useful to be clear:

• Is that crate strictly a layer on top of rust-vst, or could it work with other plugin formats such as VST 3.x, AU, AAX, or LV2?

To be clear, I'm not posting these questions expecting them to be answered here. Rather, in the spirit of the issue, what kind of governance mechanism is most effective in getting these questions discussed and consensus on the answers? I believe that with that done, writing the roadmap document and getting approval will be straightforward. (It can literally be in Q&A format)

[crsaracco]

This isn't exactly the type of feedback requested (which is mostly about project governance), but [...]

Nope, it's even better! These are all very important things to consider. I think it should definitely be included in the first roadmap (should we choose to go that route), and we should definitely take some time to hash each of these out in some way or another, either way.

Excellent response, and excellent set of questions!

[crsaracco]

I don't think we have the volume of effort for this to make sense -- closing.