Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:116285
MIME-Version: 1.0
References: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
In-Reply-To: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
Date: Thu, 21 Oct 2021 17:06:54 +0200
Message-ID: <CAF+90c_rrykaHU-U7sBW9cxTPGCk0MzcKkZU-BiH2MiqyNsMQQ@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary="000000000000b894a305cede3f5a"
Subject: Re: [PHP-DEV] Bugsnet
From: nikita.ppv@gmail.com (Nikita Popov)

--000000000000b894a305cede3f5a
Content-Type: text/plain; charset="UTF-8"

On Sun, May 9, 2021 at 8:49 AM Joe Watkins <krakjoe@php.net> wrote:

> Morning internals,
>
> We have a spam problem on bugsnet, it's not a new problem. Nikita had to
> waste time deleting 20 odd messages from bugsnet yesterday and this is a
> common, daily occurrence. We clearly don't have time for this.
>
> Quite aside from spam problems, bugsnet is hidden away in a dark corner of
> the internet that requires a special login, doesn't integrate with source
> code or our current workflow (very nicely), and doesn't get updated or
> developed.
>
> Having moved our workflow to github, now seems to be the time to seriously
> consider retiring bugsnet for general use, and using the tools that are
> waiting for us - Github Issues.
>
> I'm aware that bugsnet serves as the disclosure method for security bugs
> and github doesn't have a solution to that. Leaving that to one side for
> now ...
>
> I'm also aware that bugsnet carries with it 20 years worth of crusty old
> feature requests and bugs, that are never realistically going to be dealt
> with. In the past I've spent time trying to close very old bugs that no
> longer seem relevant, the fact is that there are so many of these that I
> don't think I made a dent.
>
> It seems obvious that we don't want to migrate all of the data on bugsnet,
> but nor do we want to loose the most recent and relevant reports.
>
> I propose that we disable bugsnet for all but security issues leaving
> responsible disclosure method to be handled in some other way at a later
> date. Leaving bugsnet in a (mostly) readonly mode.
>
> We then send a notification to all bugs that were opened against a specific
> and supported version of PHP, notifying the opener of the change and
> requesting that they take a couple of minutes to open their issue on
> github.
>
> I think we might get quite a good response here - anyone suffering the
> worst consequences of bugs - production servers can't be upgraded and so on
> - are already waiting for a notification from bugsnet, I'm sure the
> majority of them will do as we ask.
>
> In some set number of weeks (to be decided), and depending on the response
> to our switching over to github, we can try to determine at that time if
> it's worth trying to import any data from bugsnet. We can also consider at
> this time when it might be appropriate to retire bugsnet entirely.
>
> We will not be free of spam simply by moving, but github has the tools we
> need to moderate the content properly - you can block people. In addition,
> I feel people are less likely to misbehave if they think their co-workers
> or employers might be able to see what they are doing, which may have an
> effect also.
>
> It may be over optimistic, but we might get better engagement with bugs on
> github than anywhere else also - Github is where people are tending to do
> their business today.
>
> Github is maintained, hosted, developed, and free, and while it isn't the
> perfect tool for the job, nothing else is either. We could spend time
> (which we don't have) developing bugsnet, or installing some other solution
> in a dark corner of the internet, and solve no problems at all, and be
> burdened with the ongoing maintenance of that solution.
>
> The people who have to spend the most time on this are release managers,
> and so while I'm talking to everyone, it is release managers opinions that
> I'm most interested in, they are the people who will be and have been most
> effected by the shortcomings in bugsnet, whose opinions are most relevant
> in this space.
>
> I don't think a vote is appropriate, this decision should be made by the
> people whose "jobs" are directly effected - with input from the community,
> of course. Not least of all, it will take a month to close a vote, by which
> time we will have wasted another (working) day or more of Nikitas time.
> Having said all that, I am looking for a consensus before we take any
> action. My arm can be twisted, but this is my current position and I think
> it's a reasonable one.
>
> On the issue of responsible disclosure ... we can treat this separately,
> with the recent change in the workflow, this process is in need of review
> anyway. How that is handled should be decided by the people who have a hand
> in that process, and so it seems prudent to leave it aside for now.
>
> Cheers
> Joe
>

To follow up on this proposal: We have been using GitHub Issue for docs for
a while now (https://github.com/php/doc-en/issues) and I'm about to disable
submission of new docs issues on bugs.php.net. I think it's time to switch
non-security bugs for PHP proper as well, for all the reasons that have
already been discussed.

For docs we didn't really do anything special in terms of labels etc. I
think for the php-src repo we do want to introduce some more structure for
categorization and triage, as the volume tends to be higher there.

For that purpose I've created a prototype of how things could look like
here: https://github.com/nikic/test-repo/issues/new/choose Note that
creating a bug report will open a form using the recently introduced issue
form feature.

I'm proposing the following label structure (the list at
https://github.com/nikic/test-repo/labels is incomplete though): Each
report has either a bug or feature label. Additionally it starts out with
the T-needs-triage label. Once a project member triages the report, the
label is removed and a category label is added instead, e.g. C-OpenSSL for
issues relating to the OpenSSL extension.

I also have a few more triage labels (T-needs-feedback, T-verified,
T-invalid, T-wontfix, T-duplicate), but I'm not sure we actually need any
but the first one or the first two -- I personally don't see a lot of value
in having a label for why exactly an issue has been closed, the fact that
it is closed is usually sufficient.

As for the migration itself, I think we should approach this the same way
as docs and open issues on php/php-src without actively migrating old
reports from bugs.php.net. We should retain bugs.php.net in read-only form
indefinitely, and also allow comments on old issues for the time being.

Regards,
Nikita

--000000000000b894a305cede3f5a--