Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:114323
MIME-Version: 1.0
References: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
In-Reply-To: <CAOwTYAtOti3+Tv9Cu5fK6bQ3tjAibRHUWOctnQFfGJyaoQYExw@mail.gmail.com>
Date: Mon, 10 May 2021 09:56:55 +0200
Message-ID: <CAEPJduk5P7b9UrO-PJxg=LZ4MnUSfNjC+Q6UiKBiDDWX76hXFg@mail.gmail.com>
To: Joe Watkins <krakjoe@php.net>
Cc: PHP internals <internals@lists.php.net>, 
	PHP Release Managers <release-managers@php.net>
Content-Type: multipart/alternative; boundary="000000000000b128e905c1f51f70"
Subject: Re: [PHP-DEV] Bugsnet
From: kontakt@beberlei.de (Benjamin Eberlei)

--000000000000b128e905c1f51f70
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.
>

One downside of this "easy access" is that Github Issues tend to get used
as support question forum, at least from my experience on Doctrine it can
easily be 50% of the issues that are support questions. This is much more
work to process than simple spam issues, because there is a human on the
other side who need to be directed towards the proper support channel.

In addition I agree with Rowans assessment that large projects usually have
lots of automation in place on top of Github issues that we would again
need to configure, write or maintain in one way or another.

bugsweb on the other hand is a "classic LAMP" stack application, so maybe
we could look into removing the infrastructure variable from the hosting
equation and look for a PaaS provider? Spam protection third party services
are also available and might potentially be integrated with in a reasonable
amount of time.


> 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
>

--000000000000b128e905c1f51f70--