On Thu, Oct 20, 2022 at 2:26 PM Pedro Nacht via internals < internals@lists.php.net> wrote:
> I've made this suggestion as issue #9778 ( > https://github.com/php/php-src/issues/9778) and PR # 9789 ( > https://github.com/php/php-src/pull/9789), but have been invited by > @damianwadley to bring it to the mailing list. > > The Scorecards GitHub Action basically keeps an eye on a repo's security > posture and makes simple, objective suggestions for possible improvements. > > For PHP's current Scorecard results, see here: > https://api.securityscorecards.dev/projects/github.com/php/php-src. At the > moment it's a raw json dump, but it contains information on the results of > all the individual checks as well as comments on how to improve the scores. > When the Action is installed, this is cleanly added to the project's GitHub > Security Panel with step-by-step instructions. > What actionable benefit could this provide the project? Letting contributors know that some issues weren't responded to within 24 hours or something? I mean... none of us are paid to do that. Of course Google OSS projects have that kind of response, there's a trillion dollar company paying people to do that. But it's not like seeing a notification about something like that would provide php-src with actionable information. If we miss a metric that it's concerned about... who is responsible for doing something about it? Obviously the project is very active, and we have a lot of people who contribute, and we often do have quick responses between all the volunteers for things that need to be done quickly. But metrics and guarantees? If Christoph goes on vacation and Nikita is busy with work and Dmitry hasn't checked for notifications for a few days and everyone else thinks that one of them should weigh in first, then what would such a score actually tell us about the project? That we don't have employees responsible for those tasks? We already know that. What would forcing maintainers to go through a PR and review process for the types of changes that normally get pushed directly to master provide? A way for third parties to weigh in? Can't they already do that through the mailing list, issues, and PRs? If Google wants to help the PHP project, helping the project is probably better than supplying a tool that makes volunteers feel obligated in ways that employees do. Joe, Christoph, Dmitry, Nikita, Dan, etc.... all of these people with deep knowledge of the project and its history are critical to the project, but none of them are beholden to it. We were all sad to hear that Nikita's focus would shift with his new professional opportunities, but that doesn't mean he was wrong to take those opportunities or that he owed anything more than he was willing to give to the project. I just don't see what tangible benefit or actionable information something like this could provide. It's neat, and interesting, and maybe a bit of a novelty. But as part of an organizational workflow for the PHP project... why? Jordan
