On Mon, 2016-02-08 at 14:13 +0000, Dan Ackroyd wrote: > On 30 January 2016 at 07:19, Stanislav Malyshev <smalys...@gmail.com> wrote: > > > > As far as I can see, the only way to do it is to edit local database, so > > somebody with shell access and DB password is needed. > > What is the process for adding new status to those available at > bugs.php.net ? Does anyone know who has access to the box, and are > they allowed to add a new status by themselves, or do they need to get > 'approval'?
From a technical perspective anybody who can push to the web-bugs-repo can add a status. The status is just a varchar() field in the database. No admin task needed to change it. > Just to reiterate, adding a 'Requires RFC' would be useful to help > clear the backlog of feature request issues that have been open for > years, and are just not going to be done, unless someone proposes an > RFC for it. And other FRs are just not going to be done, unless someone proposes a patch for it (or attracts attention from somebody who can) I don't see a big difference, especially as it is a somewhat gray line where we need an RFC and where a patch is enough. Maybe instead of a status a checkbox would be better. Since even if a FR requires an RFC it is still open and unassigned or might be assigned. (this then again might need somebody with power on the server to change the database schema) > But it would have more use going forward. It allows issues that are > feature requests to be moved out of the 'Open' state quickly, so > people looking for actual bugs won't be shown issues which would > require an RFC. We might improve the reports to separate between bugs. This might be useful (while one person's feature request might be another person's bug) > Just as an example, there is a feature request to "add ini setting > that will toggle between old and new behavior, giving developer an > option to choose between better debugging capabilities and better > performance" - https://bugs.php.net/bug.php?id=71543 > > This seems quite unlikely to happen....not only are there very few > people who could implement this change, they are very unlikely to want > to do it, and all RFCs introducing new ini settings seem to receive a > poor response. I'd vote for being brave and closing it with a nice text. If the user persists they can reopen it. Maybe even worth a canned answer. > Having that issue sit open, means that all of the lovely people who > look to fix bugs will be wasting time reading that issue. While the > issue is open, the reporter also has the incorrect expectation that > someone might be looking to do that issue "any day now" when > realistically, it's not likely to happen. One more reason to close it. :-) Some history mixed with opinion: Back in the days we had Jan aka. "Mr Bogus" who was quick and brave in closing bugs as "bogus" Nowadays "Not a bug") I always liked that as a quick feedback to the user, who could accept the reasoning or re-open. Probably with more details or better reproduce case. This helped other developers a lot. (True, some of his responses might have been questioned under an CoC) Unfortunately nobody else since had the time, stamina and motivation (and probably knowledge to do assessments quickly) to do this. Back then, as a user, I liked the quick responses and sometimes "laughed" (not literally) at other projects where I sometimes got a first response a year or two after the report. After moving on. johannes
signature.asc
Description: This is a digitally signed message part
