I'd often hear people complain in the lines of "it's has a lot of stars and constant commits but there's over 100 issues so we might want to avoid it". Which really rarely correlates. Maybe the term "issues" is just too loaded, especially when often those are feature suggestions or even information/how-to tickets - not exclusively bugs or "issues".
Before Github, it wouldn't have come across any sane mind to file a feature request or other discussion/information under the name 'issue', for... they are not issues. It would have gone on a mailing-list (occasionally a web-forum). Issues (identified bugs) on the bug tracker, and the rest in a place of discussion.
Of course, that led to the same problems, and they eventually allowed customizing the term "bug" on your own bugzilla installations.
And I know the PMs actually went through the enhancement requests the customers logged (I think it was once per a release cycle), and evaluated whether any of them were worthwhile to implement or not.
So, in proprietary software, using a bug tracker to track feature requests is a lot older than Mozilla/Bugzilla.
Agreed.
But GitHub is also slowly fixing this.
For example the "Discussions" beta feature is enabled for specific repos. Here's it in action for the ImageMagick repo at https://github.com/ImageMagick/ImageMagick/discussions.
It's only available on a small subset of repos tho and it's something you can turn on and off at the repo level. I was given the option to enable it in my one of my repos, but it's a fairly new project with no discussions yet https://github.com/nickjj/flask-db/discussions.
I hope the Discussions feature becomes generally available soon.
That's also true but where do you draw the line with vendor lock-in and convenience?
If you use Google's mailing list service then you're locked into Google. What if they decide to drop that like many other services in the past?
If you use a self hosted forum / mailing list instead, the repo owner is on the hook for setting up and configuring a server along with potentially registering a domain name just for that aspect of an open source repo. With something like Discourse that could be like $20 / month + domain just for 1 instance of it.
If you decide to use Discord or Slack as a side channel for casual chatting or feature requests then you're locked in there too and there's no persistence (at least not with Slack) or SEO discoverability.
That and with any of the above solutions chances are folks will end up reporting bugs in those side channels which means someone needs to go back and write them up as proper issues, often times that'll be the repo owner. Plus now all users need to jump through hoops by registering on those external platforms to give a feature request on a project on GitHub.
I hate the idea of vendor lock-in but at some point integrated platforms make sense because the alternative is worse. As a developer I really like having my code, CI, issues and a place to chat all in 1 spot. If GitHub dies, that's fine there's always Gitlab. If Gitlab dies, there's always Bitbucket but at this point the developer community would likely revolt and come up with a new solution.
Can I export all the data in a publicly documented, machine-digestible, patent-unencumbered format? Is the site helping, or at least not obstructing, alternative clients for interfacing with the feature?
If the answer to any of these questions is "no", then it's vendor lock-in.
So I'd say, GitHub isn't locked in as of now, they're quite open. But your definition is good, and it's probably a good idea to re-evaluate every now and then.
[1]: https://stackoverflow.com/questions/41369365/how-can-i-expor... [2]: https://docs.github.com/en/rest
Discussions can already be enabled on any public repository in the repository Settings ("Options" tab, "Features" section, check the "Discussions" checkbox)
Keeps issue bloat under control and allows users to request features in the same place as the code.
What's wrong with just tagging feature requests?