Improving GitHub Project management

[adamshiervani]

In the past six months, we’ve been heads down - scaling production, support, shipping, and preparing for retail availability. Unfortunately, the GitHub project management side of JetKVM fell behind. Issues weren’t properly triaged, and feature requests piled up without a clear system for prioritization or visibility. That’s on us.

We’re now making a systematic effort to bring structure to how we manage and communicate development progress here on GitHub. It's not rocket science, but at a high level, we have two types of "GitHub Issues": Bugs and Feature requests.

For features, we explored a number of third-party tools designed for community-driven voting, prioritization, and feedback. But most of them felt bloated with separate logins, disconnected from the GitHub workflow. We want everything to stay in one place: where the pull requests happen, where users already comment, and where links actually resolve back to code. So we’re keeping the conversation here.

Our plan is to have a GitHub project board composed of bugs and feature requests. The board has a basic roadmap structure so people can get a quick overview of what we're doing and what is planned. Something like now, soon, or later.

This should make it easier for contributors and users to see what’s actively being worked on, what’s planned, and what’s still up for discussion. The details are not settled, but the goal of giving people a clear overview is clear.

In the last few days we've been mainly going through old tickets, closing duplicates, closing completed ones, and assigning them to the appropriate category. We've done some work already, but this is what we have left:

• Go through all tickets without a defined type (bug, feature, etcetc.).
• Clean up and remove outdated labels
• Introduce a new, consistent labeling system
• Build a GitHub project with appropriate project state
• Create pull request templates that prompt contributors to link PRs to relevant issues
• Migrate #feature-requests from Discord to GitHub
• Link to the GitHub roadmap on our website

We're expecting this to be a changing thing along with the project needs, but if you have any suggestions that you think would improve this, feel free to comment, and we'll take it from there.

Thanks for bearing with us while we get things cleaned up. If you’ve opened an issue or suggested a feature and it’s been in limbo, we’re getting to it now - and we appreciate your patience.

[dseven]

This is great to see! I was getting a bit concerned.

I think you need to publish (and effect) some "rules" for contributors. A few ideas to start with, based on past experience with opensource projects...

You hint at this already, but PRs should be linked to issues. The issue describes the problem, and the PR describes the solution. Every PR should address at least one issue, linked with appropriate github keywords

PRs should solve ONE problem (fix a bug, or add a feature), not try to bundle / sneak in other unrelated changes.

Simple PRs (e.g. bugfixes) should contain one commit - not a "dog's breakfast" of tweaks, typos corrections, merges of the upstream branch, etc. People need to learn how to rebase and amend commits in their own forks. Otherwise the commit history is going to be a mess. There may be a case of muliple commits for complex cases (feature additions), but each commit should have a discrete purpose, relevant to the issue being addressed.

PRs should be reviewed, probably ideally by at least a couple of people, and any issues raised should be addressed before a PR get merged.

[adamshiervani]

This is all great stuff; we'll create a PR for the PR template, and I'll make sure you'll get tagged.