Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116361
MIME-Version: 1.0
References: <CAF+90c90pTtjxuMaQ88h+njhByfbv4qs=xx72CVPSw40tde6Cg@mail.gmail.com>
 <alpine.DEB.2.23.453.2111150940130.4221@singlemalt.home.derickrethans.nl>
In-Reply-To: <alpine.DEB.2.23.453.2111150940130.4221@singlemalt.home.derickrethans.nl>
Date: Mon, 15 Nov 2021 12:06:54 +0100
Message-ID: <CAF+90c__1D5UMMpi6yX6obtuUZVL4NQRO_nR-Yr7gFq-Sc0teg@mail.gmail.com>
To: Derick Rethans <derick@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000076f58505d0d1cfed"
Subject: Re: [PHP-DEV] [RFC] Migrating to GitHub issues
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000076f58505d0d1cfed
Content-Type: text/plain; charset="UTF-8"

On Mon, Nov 15, 2021 at 10:47 AM Derick Rethans <derick@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

--00000000000076f58505d0d1cfed--