Triaging issues reported on GitHub

I couldn’t agree more. Many things users see as bugs or problems, can more often than not be resolved by others with more knowledge and experience and thus free up Github for development. Obviously, real bugs do come about, but a forum is a great place to discuss how urgent those bugs are and the specifics of what needs to be fixed.

I haven’t done much until now. Here I am now at the forum. I have been looking for an open source project to support and maybe AntennaPod is the right place for me. It’s something I use every day and I have tried many of the paid/proprietary apps out there and nothing comes close to AP. Which makes me love it even more.

One thing I’ve seen done elsewhere is for community members to begin reviewing open issues on Github. You then see if you can duplicate them and start a new thread on that issue on the forum with expanded documentation or information. This helps clean out a lot of issues that may have been fixed and it was not known or intended, but still happened. It also helps the developer focus more on writing code than running triage and can eventually help guide updates. There are many other benefits too. It’s also a way to start directing people to use the forum for questions and initial bug reports and frees up the Github space from unnecessary cruft.

@ByteHamster I’m not sure how you feel about that idea. If so, I would likely be willing to start helping with that. Someone could also add a link in Github pointing to the new thread here.

2 Likes

I would rather keep the issues (and their discussions) on GitHub. This makes it easier to reference them in pull requests and provides a better overview about what needs to be done (closing etc). I know that this can somehow be mapped to the forum but for pure issue tracking, GitHub is probably already optimized a lot more than a forum will ever be.

Many questions by new users can be solved in the forum. This is why new AntennaPod versions will primarily link the forum and not GitHub. If it later turns out that it is actually a bug, I would open an issue on GitHub to keep an eye on it more easily.

The list of issues on GitHub should be pretty clean already. Around twice a year, I take 3-4 hours to scroll through all open issues and decide if I think they align with my goals for AntennaPod (most important one: getting easier to use instead of getting harder to use by not adding more and more settings). While doing that, I also close duplicates.

2 Likes

I understand. Thank you for the clear explanation.

If you need help in any way, I’m happy to do so. Please let me know.

1 Like

And that’s great. At the same time, @tenkara_vt, you are warmly invited to spot any duplicate issues and let us know (either here on the forum or by commenting on the issue on GH).

Similarly, if you would be happy to help with triaging, I’m sure that’d be beneficial to the project.

  • If the issue is reported on GitHub, it’d be best to stick to that platform and report back on test results there.
  • If someone has a potential bug and reports it here on the forum, it’s of course fine to report back on your findings in the same thread. But like @ByteHamster said: if we’re sure it’s an issue, the details and any (potential) fixes should be discussed on GitHub.
2 Likes

Brilliant! I’d love to help. Thanks for explaining further.

2 Likes