On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans <der...@php.net> wrote:
> Dear Internals, > > I think it is a mistake to decide on a whim to move over to GitHub > issues without having evaluated anything else. > > GitHub is a proprietary platform, where unlike with the code > repositories, the interactions and issues are not easy to migrate out of > again. It is also now owned by MSFT, and although they are making > friendly noises towards Open Source, I remain largely skeptical (with as > a hint, the stuff they're pulling with AI code completion). > > I understand and share that "bugsnet" has many issues, and I don't > necessarily object moving to something else. > > However, in the last 25+ years we've always hosted this ourselves, and > this prevented any sort of vendor lock in. I think it is important to > own our own data here, or at least have full access to any interactions. > > This jump to GitHub Issues feels rushed, and I worry that we end up > making the wrong decision, especially because from the RFC it seems we > need to build some functionality (tags scheme, for example) on top of > it. And this will need to be maintained separately, and I worry that too > few people are going to be interested in gardening the issues on GH. > > I believe we would be much better served having a look what is > available, and see what else is suitable. I'm therefore intending to > vote no on this. Hey Derick, The RFC includes a bit of discussion of alternatives in abstract ( https://wiki.php.net/rfc/github_issues#alternatives) and the key point (which has also been brought up by other people in the meantime) is that the choice of GitHub issues is very much not a whim: For better or worse, GitHub is where nearly all open-source projects are hosted, which means that pretty much anyone involved in open-source has an account there and is familiar with the workflows. It is also where PHP hosts it's repos and where we accept pull requests. An alternative issue tracker has to compete not just on technical grounds, but also on integration, familiarity and network-effect. For an open-source project, these aspects are quite important when it comes to interaction with casual contributors. Working at JetBrains, proposing YouTrack instead of GH issues has certainly crossed my mind -- there is no doubt that at a technical level, it's a much better bug tracker than GH issues. But that's simply not the right question to ask. The right question is whether, given our rather simple requirements, is it sufficiently better to overshadow the other benefits of GitHub issues for an open-source project? I don't think so. We just need GH issues to be "good enough" for our purposes, and I think that at this point it is. I'll also mention that the discussion about this migration has been going on for six months, and in that time all I've ever seen are vague mentions of alternatives, but nobody has provided any in-depth analysis that goes beyond a simple name drop. I went through the trouble of providing a detailed evaluation of how the GitHub issues migration will look like, while the alternatives are still at the state of "Phabricator is a thing" (ooops, it actually isn't -- it managed to be discontinued while the discussion was going on!) Finally, for me an important part of the migration (whether to GH Issues or something else) is specifically that we don't host it ourselves, because we have historically always been really bad at that. Of course, letting someone else host it is incompatible with the desire to fully "own" our data. I do appreciate the general sentiment here though. Regards, Nikita
