Issue queue review: phew #753
emcniece
announced in
Announcements
Replies: 2 comments
-
Woow, amazing work. I hope I can get back on track with my computer and arduino shortly so I can also review some of the documents |
Beta Was this translation helpful? Give feedback.
0 replies
-
@emcniece you're off to a very good start, thank you! |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
After a few long days and nights, I have finished reviewing the entire issue queue (this repo only). It was a lot. You folks are an industrious bunch, damn!
Data, please
I attached some labels to each issue to try and capture any affected platforms and the general focus or topic being discussed. Here's what the results look like:
Feature requests, UI/UX, and Gcode-related issues make up just over half of all 187 open issues. There are some recurring performance issues and a few documentation/question related tickets, but it's neat to see that so many people enjoy the app, have hope for its growth and see opportunity for quality-of-life improvements!
The Issue Backlog project has a table view of the data - I tried to assign a status like "Todo" if the ticket is ready for action, or "Blocked/Waiting" if it needs more info. The "Triage" status indicates that the issue needs verification or testing, feel free to start with these.
There were so many feature requests that I split them out to their own Feature Request project. These are largely unlabelled - if anyone is interested in this area, do feel free to label as you see fit.
Stalemate
These issues go back years, to 2018 or so. People come and go over time, some move away from the software, some will change hobbies, and we won't get answers from everyone when we revive old threads. Some issues will inevitably be left hanging and won't have a way for us to verify the report. What should we do with issues like this?
A few issues have been preemptively labelled with
stale
due to lack of activity. One management tactic is to install a stale-bot to automatically expire inactive issues and keep the cognitive load down, but such bots can be considered harmful - especially in a project with long dev/release cycles. There's even a few issues in this project that have had posts every year, and still going!I'll stick to the
stale
label and we'll close old issues that can't be verified, have had releases since the report, and where the author doesn't respond. If your issue has been labelled withstale
, just reply and we'll start moving it forward again!Next up
I've started learning about the project by reading all of these tickets. Now that they're labelled I'm hoping the community can more easily find a topic they're familiar with.
Next I'd like to focus on speeding up the build pipeline and figure out the release process. Once that workflow is established we should be able to speed up the dev/build/release/feedback loop, enabling more agile turnaround.
Underpromise and overdeliver, right?
+2 weeks: organize the 199 open issuesBeta Was this translation helpful? Give feedback.
All reactions