Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114343
MIME-Version: 1.0
References: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
 <de8c00e1-bf7d-a5d6-03a9-6aaf85960d1a@gmail.com> <C67FE36C-8143-427B-AC9C-FAEBD658DDE3@gmail.com>
 <CAGgaK7Kv4vi-H2VnGkxduhHGYUWs7mBDSDpRWkcDfBVTkSJ1cg@mail.gmail.com>
 <bc1ad84e-3919-d819-8c60-635539afc4c5@gmail.com> <CA+kxMuS-iqkZju41KfSmaw18QYs6ZDnpw+pm_OvJ=zJi1nPt=w@mail.gmail.com>
In-Reply-To: <CA+kxMuS-iqkZju41KfSmaw18QYs6ZDnpw+pm_OvJ=zJi1nPt=w@mail.gmail.com>
Date: Mon, 10 May 2021 17:10:54 +0200
Message-ID: <CAF+90c-4ig7FDb+jqgQMmGhbO0OoV7PmUBrpxnHVS6Q+ksWJsw@mail.gmail.com>
To: Dan Ackroyd <Danack@basereality.com>
Cc: Rowan Tommins <rowan.collins@gmail.com>, Joe Watkins <krakjoe@php.net>, 
	Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="00000000000016e07905c1fb305a"
Subject: Re: [PHP-DEV] Re: Bugsnet
From: nikita.ppv@gmail.com (Nikita Popov)

--00000000000016e07905c1fb305a
Content-Type: text/plain; charset="UTF-8"

On Mon, May 10, 2021 at 3:29 PM Dan Ackroyd <Danack@basereality.com> wrote:

> Hi Joe,
>
> > We have a spam problem on bugsnet
>
> I would snarkily say "maybe accept the PRs from people wanting to work
> on it?", but I realise that ignores the underlying problem, that PHP
> lacks people. And particularly lacks people who can dedicate time to
> understanding, reviewing and saying no to things.
>

Yes, I think this is something people often don't get: It's not just a
matter of finding someone who can implement a change, but also someone who
is willing to review it, and someone who can perform necessary
infrastructure changes, such as server configuration changes or database
migrations. The last part is where things commonly fail.

Even if the plan is to move to a different platform, I'd like to take
> the time to document what is lacking about bugs.php.net currently.
> Please can someone turn on issues for php/web-bugs?
>

Ha, this is a great illustration. You do realize that the bug tracker for
bugs.php.net is bugs.php.net? Under the "General issues - PHP.net Website
problem" category, I believe. However, bugs.php.net is really not suitable
for the kind of use you have in mind. And this also extends to other areas.
For example, for php-src we sometimes use
https://github.com/php/php-tasks/issues to track and coordinate certain
changes, because bugs.php.net is very inconvenient for that purpose.

So, here's my 2c on the proposal. Let me start with issues I see with
bugs.php.net:

 * bugs.php.net is regularly semi-down (slow to the point of being
unusable). Either Derick or myself regularly restart the server to recover
it. I don't believe anyone ever looked into the cause.

 * There is a lot of linkspam, and it's getting worse. I delete a few
comments ever day. On some days it's just a few, on some days it's dozens.
This is something that *can* likely be addressed, but may degrade user
experience further, e.g. with recaptcha, which is notoriously finicky.

 * Next to linkspam, we unfortunately also suffer from hostile user
comments from one Reindl Harald. This user is banned from the mailing list
and our GitHub organization, but we are not able to effectively ban him
from bugs.php.net, because it requires no form of authentication
whatsoever. You can enter an arbitrary email. I think many people don't
appreciate it, but this is actually a ***really big problem***. This user
is consistently and routinely very rude to bug reports, which hurts the
overall reputation of the PHP project. While it should be clear that he
does not represent the PHP project, it still remains a fact that that if
you submit a bug on bugs.php.net, you are quite likely to get some insults
thrown at you. This is not great.

 * I think to resolve the previous point (and linkspam as well), we need to
require authentication on bugs.php.net, which would further degrade user
experience. As part of the git.php.net/master.php.net incident response, we
also discussed whether we could move bugs.php.net to authenticate using
GitHub, now that all PHP contributors need to be part of the PHP GitHub
organization. I think if we wanted to retain bugs.php.net, we'd have to
pursue something in this direction, with all users required to authenticate
through GitHub.

 * For me personally, as a developer with a php.net account, bugs.php.net
is actually a somewhat okay system. I think the main people suffering from
it are bug reporters not affiliated with php.net. One reason is that
there's no good way to manage your reported bugs -- the only thing you get
is a per-bug (!) password to edit it later, bug you can't track bugs you
reported or similar.

 * Bug reports are submitted with incorrect categories very often. I can't
really blame the reporters for that, because there's a *lot* of them, and
they're grouped, so it's really not easy to find the right one (even for
me). This is common to the point that I would consider the inability of the
reporter to specify category/label on GitHub a feature rather than a bug --
this is something that should be done by someone during triage, who is
familiar with the available categories/labels.

 * bugs.php.net does not support checkboxes or edits to the bug
description, which makes it completely unsuitable for tracking issues and
any kind of coordination works (this is part of the reason why the
php-tasks tracker exists).

 * bugs.php.net does not support labels -- only top-level categorization.
For example, we can't mark bugs as "probably easy" or "good first issue" to
give newbies something to chew on.

GitHub issues address most of these concerns, and are tightly integrated
with the pull request workflow. GitHub issues is not the most advanced bug
tracker out there, but the unfortunate truth is that it's still much better
than bugs.php.net. Some thoughts on how our usage would look like:

 * As was already mentioned, there's no support for security issues, so
we'd retain bugs.php.net for that purpose, at least for the time being.

 * Categories are translated to labels and applied during triage. As
mentioned before, I believe it's advantageous that the triager adds them
and not the reporter. Our inflow of new bugs is also low enough that I
don't think triage would be an undue burden. The labels could be fairly
similar to the current categories (mostly one per extension), though we
also have a good bit more flexibility, because we are not limited by a
single category per issue. An issue can be both ext-gmp and buildsystem for
a build-system issue in ext/gmp, not just one of them.

 * It's worth noting that issues are per-repository, which means that
documentation issues will now live in the doc repo(s), and PECL issues in
the PECL repos. php-src will only have issues relating to php-src
specifically. This is great.

 * The minimum minor PHP version affected should probably also be specified
through a label -- I don't personally search issues by version, but other
people (cmb?) might. If search by version is not common, we can have this
information only in the issue description. The operating system can be a
label as well, though we should only add that if the issue is actually
OS-specific -- this is pretty rare.

 * One somewhat annoying GitHub limitation is that "saved replies" are
per-account, not per-repo or per-organization. This means that someone
doing a lot of bug triage would have to explicitly configure these. (I
personally don't use the canned replies on bugs.php.net, but I know other
people do.)

 * I don't think any other functionality provided by bugs.php.net is
useful, in particular:
  a) I pretty much never look at bug votes -- though GitHub has thumbs-up,
thumbs-down as an equivalent there.
  b) I have not once made use of the "Reproduced - Same Version - Same OS"
information.
  c) Pull request association is handled automatically by GitHub.
  d) Patch upload is no longer supported -- this is great. We should
probably disable that even if we keep bugs.php.net, because patches
submitted as anything but pull requests are almost certainly going to get
ignored.
  e) Did I miss anything else that bugs.php.net does?

Finally, switching to GitHub issues makes the bug tracker more
user-friendly. This will likely result in a larger number of reports, both
legitimate and bogus. Previous comments focussed on the downside of that
(we will need to close more support-style tickets), but there's also the
upside that it's easier to get people involved with PHP. PHP has something
of a reputation of being unapproachable to new contributors, and the bug
tracker is one part of that (the other parts being the internals mailing
list and the codebase :P)

TL;DR Yes, I do think switching from bugs.php.net to GitHub issues would be
beneficial for the project. Details on how to do that need to be ironed
out, but I think the direction is the right one.

Regards,
Nikita

--00000000000016e07905c1fb305a--