Website php.net updates and coordination

1 year ago by Roman Pronskiy — view source — reply

unread

Hello Internals,

By way of introduction, I am Roman Pronskiy, Operations Manager /
Executive Director at the PHP Foundation. I have contributed to and
coordinated the PHP 8 release page in the past:
https://github.com/php/web-php/commits?author=pronskiy.

I wanted to address a few important matters regarding the maintenance
and improvement of the PHP website.

Unresolved GitHub Issues
Many issues and pull requests on GitHub remain unresolved for extended
periods. It would be great to do regular triage and assign these
issues to specific team members for review and resolution. I volunteer
to help review and triage issues, and kindly request php/web-team
membership.
Analytics
It is hard to make any decisions without having a reliable source of
stats and data. With more than 17,000 pages, updating all of them is
impractical. Analytics, among other things, will help us prioritize
updates based on page importance. Using a self-hosted Matomo instance
seems a viable option for this. Derick Rethans will follow up with
more details.
Deployment Process
Recently, there was an incident with a code block pushed to the
website accidentally: https://github.com/php/web-php/pull/1021. It was
promptly reverted, but the case highlighted a potential security risk:
unauthorized modifications could go unnoticed, potentially affecting
all visitors of the php.net website worldwide. In theory, malicious
code could be added to the server directly if access is compromised,
with high chances of being unnoticed.

We need to revise our deployment process to mitigate such risks and
reduce manual maintenance. Derick and I will follow up on this.

Regression Testing
We want to introduce visual regression testing and ensure that every
pull request undergoes more thorough review. This would especially
help review HTML/CSS changes, where we currently have few resources
for manual testing. If anyone has expertise in this area and would
like to review the changes, please check the PR:
https://github.com/php/web-php/pull/994.

I’d like to volunteer to help improve the PHP website and coordinate
efforts. Looking forward to your feedback.

-Roman Pronskiy
The PHP Foundation

1 year ago by Jim Winstead — view source — reply

unread

[ snipped the specific issues ]

I’d like to volunteer to help improve the PHP website and coordinate
efforts. Looking forward to your feedback.

Once upon a time, management of the web site(s) was handled by those on the webmaster mailing list. It doesn't look like there's any active discussion there now, just automated commit messages.

Looking at the commits to the php-web repo, it looks like Luffy (https://github.com/sy-records) and Sergey Panteleev (https://github.com/saundefined) are the 'code owners' of that repo, so I guess they're leading the charge these days?

There's overlap with whoever is actually managing the servers, which was (and still is?) the people on the systems@php.net alias.

Maybe it would make sense to stand up a new mailing list that could serve as a discussion space for those working on this aspect of the project.

It's an area where I'd like to get back to contributing, too.

Jim

1 year ago by Sergey Panteleev — view source — reply

unread

Hi Jim,

Maybe it would make sense to stand up a new mailing list that could serve as a discussion space for those working on this aspect of the project.

I don't think this solves the problem, php-webmaster is still active but there is just no communication there,
when adding a new ML, we will just have a few "silent" mailing lists.

So I guess they're leading the charge these days

Not really, we just decided to start triaging the issues and PRs that are piling up in the repository, a little at a time.

Here is the original PR [1], anyone who wants to do the site can add themselves to CODEOWNERS
(or not and just deal with it from time to time).

There's overlap with whoever is actually managing the servers

I think it makes sense to clarify this with Derick,
I don't have the exact information, except for the info in the wiki [2].

[1] https://github.com/php/web-php/pull/1022
[2] https://wiki.php.net/systems

Cheers,
Sergey

1 year ago by Derick Rethans — view source — reply

unread

Deployment Process
Recently, there was an incident with a code block pushed to the
website accidentally: https://github.com/php/web-php/pull/1021. It was
promptly reverted, but the case highlighted a potential security risk:

It wasn't an accident that I pushed it. Only people with commit access
to php-web can push things, and that isn't a large list of people.

It is the RMs: https://github.com/orgs/php/teams/release-managers
and web-team: https://github.com/orgs/php/teams/web-team

Each has 13 members, but there are some overlaps.

The deploy scripts are all part of php-systems, of which only the
repository owners can commit to, and web-master, which only the above
mentioned web-team can commit to.

unauthorized modifications could go unnoticed, potentially affecting
all visitors of the php.net website worldwide. In theory, malicious
code could be added to the server directly if access is compromised,
with high chances of being unnoticed.

All commits to web-php and web-master are emailed to a mailinglist:
https://news-web.php.net/php.webmaster which I actively monitor.

We can probably improve on this this, but this is all pretty tight,
moreso than committing random things to the PHP source repository.

cheers,
Derick

1 year ago by Jim Winstead — view source — reply

unread

Deployment Process
Recently, there was an incident with a code block pushed to the
website accidentally: https://github.com/php/web-php/pull/1021. It was
promptly reverted, but the case highlighted a potential security risk:

It wasn't an accident that I pushed it. Only people with commit access
to php-web can push things, and that isn't a large list of people.

It is the RMs: https://github.com/orgs/php/teams/release-managers
and web-team: https://github.com/orgs/php/teams/web-team

Each has 13 members, but there are some overlaps.

These aren't public. The only public info appears to be the members of the PHP organization on GitHub, and I think something needs to be done to make the teams and roles (owner, moderator, etc) public information. This could probably be scripted and automated because it looks like it's not just a matter of flipping a switch somewhere on the GitHub side.

Jim

1 year ago by Niels Dossche — view source — reply

unread

Deployment Process
Recently, there was an incident with a code block pushed to the
website accidentally: https://github.com/php/web-php/pull/1021. It was
promptly reverted, but the case highlighted a potential security risk:

It wasn't an accident that I pushed it. Only people with commit access
to php-web can push things, and that isn't a large list of people.

It is the RMs: https://github.com/orgs/php/teams/release-managers
and web-team: https://github.com/orgs/php/teams/web-team

Each has 13 members, but there are some overlaps.

These aren't public. The only public info appears to be the members of the PHP organization on GitHub, and I think something needs to be done to make the teams and roles (owner, moderator, etc) public information. This could probably be scripted and automated because it looks like it's not just a matter of flipping a switch somewhere on the GitHub side.

Jim

Note that even the members aren't public information.
GitHub allows you, as a user, to hide to which organizations you belong.

1 year ago by Derick Rethans — view source — reply

unread

(Follow ups to this should probably go to php-webmaster@lists.php.net
only, and no longer internals@)

It is the RMs: https://github.com/orgs/php/teams/release-managers
and web-team: https://github.com/orgs/php/teams/web-team

Each has 13 members, but there are some overlaps.

These aren't public. The only public info appears to be the members of
the PHP organization on GitHub, and I think something needs to be done
to make the teams and roles (owner, moderator, etc) public
information. This could probably be scripted and automated because it
looks like it's not just a matter of flipping a switch somewhere on
the GitHub side.

I thought they were public.

I also had a look, and there is no switch anywhere.

Going forward, Roman and I have been speaking about getting a more
formal group together here (php-webmaster@) that makes decisions here,
as ad-hoc commits to PHP's website are as much of an issue than ad-hoc
commits to its source code.

cheers,
Derick

--
https://derickrethans.nl | https://xdebug.org | https://dram.io

Author of Xdebug. Like it? Consider supporting me: https://xdebug.org/support

mastodon: @derickr@phpc.social @xdebug@phpc.social

1 year ago by Derick Rethans — view source — reply

unread

Analytics
It is hard to make any decisions without having a reliable source of
stats and data. With more than 17,000 pages, updating all of them is
impractical. Analytics, among other things, will help us prioritize
updates based on page importance. Using a self-hosted Matomo instance
seems a viable option for this. Derick Rethans will follow up with
more details.

I have looked at a few different solutions, and the most reasonsable
seems to self-host a Mamato (formerly Piwik) instance. This means no
analytics data will get send to third parties.

I have set up this instance already (https://analytics.php.net, SSL
certificate not active yet) and also briefly experimented with it.

In order to collect data, we will need to add the following snippet to
php-web:

https://github.com/php/web-php/commit/aef3309d2508b1e1ca0db5c50c829dfdfa7ee24f

By default, nobody (besides me and Roman) would be able to view the
analytics either, but I am open to opening this up for other interested
members of the PHP development team.

I will leave it to Roman to make the case of what sort of information he
would like to obtain, and why.

Opinions?

cheers,
Derick

1 year ago by Jim Winstead — view source — reply

unread

(Followups on this should probably just go to the php-webmaster@ list, but I've included internals@ one last time just to leave a pointer to where the conversation may continue.)

Analytics
It is hard to make any decisions without having a reliable source of
stats and data. With more than 17,000 pages, updating all of them is
impractical. Analytics, among other things, will help us prioritize
updates based on page importance. Using a self-hosted Matomo instance
seems a viable option for this. Derick Rethans will follow up with
more details.

I have looked at a few different solutions, and the most reasonsable
seems to self-host a Mamato (formerly Piwik) instance. This means no
analytics data will get send to third parties.

It does raise questions about whether that means the PHP.net privacy policy (https://www.php.net/privacy.php) needs to be expanded and if we need to have and document a process for people requesting to have their data deleted (GDPR, CCPA). This is probably something that should be done regardless of whether analytics are added to the mix.

Jim