Project Roadmap / Task Tracking

[insidegui]

This discussion started with a question from @jamestut on #315:

I think we should track things that we'd like to do somewhere. What would be the best way to do so in this repo?

I'm currently investigating some options, as I generally don't like to have issues opened in public repos ¹. Of the options below, which one do you prefer?

1 - Having a separate, private repo for issues, where active collaborators would be invited as members
2 - Use the Wiki in this repo to keep track of ideas and roadmaps
3 - Open issues in this repo, with a GitHub action that automatically closes ones opened by non-collaborators
4 - Use an external tool such as Linear

I've never used any of the above, but I'd like to try one of them for this project. Let me know what you think.

¹ Based on prior experiences, the issues section in a public repository where anyone can file an issue ends up becoming a customer support hotline of sorts, and no amount of issue templates or written rules can change that. I know a lot of open-source maintainers deal with it just fine, but I don't have the mental capacity to do so

[DrDonk]

I can understand your pain with open issues here. I had the same problem with my popular repo (https://github.com/DrDonk/unlocker), but what I did find was I started getting emails and other backdoor communication wanting support which was even more annoying. I did find that having issues available but being ruthless in moving help equates to a discussion sort of worked but would depend on number of issues raised. So I'm not sure moving it somewhere else really helps.

Looking at the 4 options:

1. Separate repo for issues - good if you want to keep known issues and roadmap private, but I think most users are respectful and probably should see where the code is going.
2. Wiki is a good idea as it keeps the ideas with the code. Who would be able to edit it? And how to track the actual work associated with an idea?
3. This is what I think would be best. It's open and communicates the plans to the VirtualBuddy community without getting issues hijacked by support requests.
4. I don't have any experience with Linear so can't really comment to its suitability but the obvious use is to keep a private team on the Linear product. What are it's integration back to the GitHub repo?

Ultimately this is a personal decision for you.

On a personal note thank you for the project. I've been involved in virtualisation for 30+ years (IBM VM/CMS thru to VMware 1 onwards) and VirtualBuddy is my go to for macOS VMs. Sadly, Swift isn't one of the programming languages I know so not likely to contribute code, but would be happy to build and test VirtualBuddy.

[jamestut]

As for the Issues section being used by users as for tech support, I can relate. My take on the options that you presented above:

1. I think this is a good one. The Issues section can be a nice task list: the one where we can tick it off, add comments, etc. We can combine this with Wiki to publicly communicate the roadmap, and users could always put something on the discussion if they have inputs to the given roadmap in the Wiki (and based on how they do the discussion, we can even add them as a contributor to the aforementioned private repo).
2. I'm in with this one: this would be a simple checklist that we update manually (or even automatically?) based on the no. 1.
3. Personally I think this would be the best, as we can easily link a PR to an issue (not sure if we can link PR of a different repo to an issue on a different repo?). However, I think auto-close issues seems to be a little bit rude? 🥲. Still, we can pin something on this repo to clearly communicate that "Issues are strictly for contributors, please open a discussion thread for any feedbacks." or something along that line.
4. I also never used Linear, so can't give much input here.