3 ms·
This mostly happens, I think, on projects which don't care about bugs from the general public. This includes Angular, but also Go and Firefox, for example. Thei
by ddevault 6y ago
This mostly happens, I think, on projects which don't care about bugs from the general public. This includes Angular, but also Go and Firefox, for example. Their teams are working at a level too far detached from the general public to care, and they mostly focus on their internal priorities instead. And that's a valid approach to managing your FOSS project - it comes with no express or implied warranty of merchantability or fitness for a particular purpose, in all caps no less.
If a bug report does not immediately catch the attention of the maintainers under such circumstances, it's unlikely to do so later on. The maintainers don't care about dupes, because they didn't care about the original either. They're going to have tens of thousands of tickets no matter what.
Of course, if you find yourself at the wrong end of this process, the best way to get attention for your bug report is to attach a patch.
- swills 6y agoTo me, this is exactly right and summarizes the situation well. Maintainers actions demonstrate their priorities, which are driven by their funding rather than community needs. This is the difference between community driven projects and corporate driven ones (even if the corporate drive is indirect via funding). Writing a patch is often the only path forward and often even that is ignored or nit picked until people move on.
- cdubzzz 6y agoThis is a solid explanation. It also makes me wonder, why even use GitHub at a certain point? It seems like GH is a one-size-fits-all approach and the primary reason to use it is to get _more_ issue, PRs, etc. in your project. But once you hit a certain scale, maybe it’s time to move to a more customizable solution?
- ddevault 6y agoBeats me. This is why SourceHut lets you pick and choose any number of repos, bug trackers, mailing lists, etc, including zero, to associate with a project. I suspect that some projects just use GH to shut the peanut gallery up; a lot of people will demand that any large-ish project moves to GH if they aren't already there. That certainly seems like why Golang did it, for one.
- strenholme 6y agoOne reason for the demand to move to GitHub is because it makes it easier to find software to solve a problem which is actually open source software if everyone has a GitHub mirror. Searching for “Open source foo” often times results in a bad search results: https://www.google.com/search?query=Open+Source+WOFF+generator https://www.google.com/search?query=Open+Source+WOFF+generat... doesn’t link to the open source reference C language WOFF generator but https://github.com/search?l=C&q=WOFF&type=Repositories https://github.com/search?l=C&q=WOFF&type=Repositories does find it.
- ddevault 6y agoYour case is a bit weird. You're looking for a specific niche codebase, whose authoratative source has disappeared, and end up at a non-authoratiative archive. That's Google on hard mode. If you knew you wanted the reference converter, a more specific Google search would have worked: https://www.google.com/search?q=ttf2+to+woff+reference+converter https://www.google.com/search?q=ttf2+to+woff+reference+conve... A more in-depth research effort into the solution space also turned up things like FontForge and github.com/google/woff2, neither of which showed up in the GitHub results, but depending on your use-case are likely to have been compelling options. I think it's more important to use FOSS infrastructure for FOSS projects than it is for those projects to turn up in a search result. I also think that projects can and should market themselves in a manner which extends beyond appearing in search results. However, I do acknowledge that GitHub search can be useful. I have been thinking about letting you link up repositories hosted on not-sr.ht for your sr.ht projects, which are indexed here: https://sr.ht/projects https://sr.ht/projects So you could, for example, have a GitHub repository, a GitLab repository, and a sr.ht mailing list, all under the same project, indexed in one place. This would go a long way towards establishing a single list of FOSS projects. It would be centralized at first, but I have also been thinking about using RSS to federate the project list across many independent sr.ht installations: centralization gone.