Add 'Requires RFC' to bugs.php.net was Close some old issues

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