Some RFCs have Yes/No and some No/Yes which kinda tripped me up while scanning results.. I guess doing any kind of consistent sorting would be a plus, but ideally having Yes first would be great as it's usually like that on the wiki.

This will be really helpful for watching changes on website. Right now last change was 2 months ago - it is easy to forget about the whole project if you need to visit it manually every time to see that nothing has changed since last visit.

Such as https://wiki.php.net/rfc/reserve_even_more_types_in_php_7#vote

The vote about "division by zero severity" is marked as 100% failing. But changing to DivisionByZeroError exception, which is the choice making things change, got 87% votes, which is a passing vote.

Either this tool now predicts the future (awesome) or the timezone friendly display isn't quite right.

When a RFC has multiple votes, it would be better to show them in the original order. This is not the case currently.

PHP RFC Watch scrapes Names and E-mails from the PHP Wiki without asking for consent.

This could be done by keeping a MD5 list of e-mail addresses that have given or denied consent and sending an automated e-mail asking for consent when first discovering a new user.

This is not strictly legal though, as asking for the consent could be seen as already violating users privacy.

I'm talking about these texts:

Here are the contrast ratio:

• white on green: 1.86
• white on red: 2.44
• white on blue: 2.28
• white on teal (not in the screenshot, but used when there is 4 choices): 1.87

The AA accessibility level asks for a minimum of 4.5 for the contrast ratio.

I see 2 solutions to fix this:

• use dark text rather than white text
• use darker background color

Since there are more and more RFCs it would be very helpful to sort them by the state (and perhaps also sort both states alphabetically).

Add something like (1), ..., (n) to the page title to indicate new events since that tab has been active.
Implementation should use the Page Visibility API.

The RFC Make constructors and destructors return void has 34 yes, 22 no. While this is the majority, it doesn't pass the required 2/3 which RFCs need since the Abolish Narrow Margins RFC and as such it is declined (as also stated in the RFC itself), yet the website lists it as accepted.

Bullet for Votes cast should be on the left side instead of right.

iphp bin/console server:run

Command 'iphp' not found, did you mean:
command 'ipip' from deb ipip (1.1.9build1)
command 'php' from deb php7.4-cli (7.4.3-4ubuntu2.15)
Try: apt install

Instead of a React.js frontend I want to rebuild the UI using Twig and Symfony Turbo. There are a bunch of steps necessary for this:

• Convert React.js templates to Twig, move necessary logic to the server side. #79
• Remove Mercure integration for server side redirect after community voting. #80
• Update Symfony and GyroMvcBundle dependencies to Symfony 5.3 or 5.4-dev
• Introduce a new action to render a single RFC
• Introduce Symfony Turbo, implement voting with a Turbo frame in-place update

Currently every time you refresh you need to hide again the RFCs you don't care about

Hi @beberlei

What about adding Chrome notifications for this watch? Shouldn't be hard to implement, but I'd like to know your opinion 😄

For about a week, right sidebar lists also RFCs which are not in voting phase.

Tried to subscribe, getting a 500 error.

A yes-no vote always displays the no vote last, meaning you first have the choice for something changing and then the choice for doing nothing. And that's displayed this way on https://php-rfc-watch.beberlei.de/

AFAICT, in a multi-choice vote, the status-quo choice is also generally the last choice in the list (at least, it is in all RFCs I checked recently). But https://php-rfc-watch.beberlei.de/ will reorder these votes. See for instance the Change undefined variable severity to? vote of the Reclassifying engine warnings RFC. The status-quo vote is Keep notice here, but it is displayed second.

Note however that keeping the red color for this status-quo vote is a good idea, to be consistent with yes/no votes.

Currently, Deprecate ${} string interpolation is marked as accepted for PHP 8.2 while it's still in voting.

https://wiki.php.net/notrfc/scalar_type_hints

😉

E.g. order them last in the list and untick by default?

The Numeric Literal Separator and Allow throwing exceptions from __toString() RFCs are both listed as "Target PHP Version: unknown". Both actually target PHP 7.4.

It would be super helpful to show the date the voting closer per RFC.

PHP votes can either require a majority or a 2/3 majority. It would be great if this info could be available in the display to know whether it is on track of being accepted or no (might not be easy to extract though)

See https://php-rfc-watch.beberlei.de/#Accepted%20RFCs%20for%20PHP%20

Would be nice to have a link to the RFC besides the <label> tag in the sidebar :)

Instead of polling for updates every 60 seconds, use Mercure to push updates when they happen in RFCs or community votes.

For example, Typed Properties is currently shown as in voting, where it's actually on hold.

The logic that detects vote ending currently looks for "this poll has been closed" - it should also consider a vote to be closed if the vote table is no longer present on the page (and/or reconcile the "in voting phase" section on the index page against the RFCs in the database that are considered to have open votes?)

As a side note, maybe looking for a <td colspan=...> might be better than looking for a specific string? Not sure if that would actually make any practical difference but string comparisons for this kind of job always feel wrong to me.

The RFC https://wiki.php.net/rfc/concatenation_precedence only has 2 votes.

But https://php-rfc-watch.beberlei.de/ displays a third one for the block rendering Change the precedence of the concatenation operator (with only 2 votes casted).
Based on the history of the wiki page (see https://wiki.php.net/rfc/concatenation_precedence?rev=1556663802&do=diff), the vote was renamed. And your DB seems to have kept the old name around as well (and number of votes are wrong for the new vote btw).

It would be neat is there will be a date when the proposal was accepted.
This way we can see timeline of accepted features