|
There have been a few (tried Trello and ZenHub), and they've all turned into a mess, so I recently hit the reset button again and am just trying a github project now: https://github.com/orgs/buttplugio/projects/1 tl;dr - Right now I'm trying to standardize our logic on Rust (I'm also the ex-device interfaces lead on firefox at Mozilla, so I love some rust :) ), then extend back out to other languages and platforms through FFI to the Rust base. The Rust work has also ended up creating other libraries, including: - systray, a library for building simple systray apps with rust: https://github.com/qdot/systray-rs
- btleplug, a cross-platform host side Bluetooth LE library in Rust, mostly via copypasta but hoping to unify soon: https://github.com/deviceplug/btleplug In the end, Buttplug is just a hardware abstraction layer, think of it like the USB HID or Bluetooth Profile model, except outside of the protocol specification space. I'd like to abstract the back end a bit more and allow other projects to use it, so you could have, say, a library that abstracts health device protocols or something. |
In my experience, this is mainly caused by planning in too much detail, too far ahead. And then your plans change and it's a bunch of cl noise you have to clean up or live with.
The only system I've stuck with for my FLO projects is the following:
- One tag (or milestone) named "someday/maybe". This is for things that are reasonable to do (you'd accept patches), but not worth the time/effort for you to implement personally. It exists so you can filter them out without closing. - One milestone called "next release". Only add issues to this milestone when you've competed them. Note: don't close these issues yet; keeping them open results in more visibility and fewer duplicate bug reports.
When it's time to do a release, rename the "next release" milestone to the version of the release (ex: v2.4.1), close all the associated issues (making sure they're in the changelog as you go), and replace it with a fresh "next release" milestone.
---
In the past I also had a "planned" milestone, but it's redundant with someday/maybe; anything open and not assigned to a milestone is planned.
Red Moon has the same order of magnitude of open issues as Buttplug, and not much of a community.
- If there were a larger community, I'd probably write a high-level roadmap, describing my vision and areas where it currently falls short.
- If there were other contributors or significantly more open issues, I'd add a "high priority" tag, limited to ~10 issues at a time, so there's a way to engage with less noise.