On Sun, May 9, 2021 at 8:49 AM Joe Watkins <krak...@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
