Proposal: Informing external standards/integrators of important changes/tickets asking for community input

[jrfnl]

Background/Context

Every once in a while tickets are opened for PHP_CodeSniffer with proposals which impact external standards and/or external tooling integrating with PHP_CodeSniffer.

In the run up to a new major, this may happen more often. Similarly, it will happen a little more often in the next few months while I'm finding my feet and working through some of the maintenance backlog.

These tickets can be proposals for new features, proposals for breaking changes, or other big changes.
These tickets will often be labelled with the Type: meta label, the Type: breaking change label and will always initially get a Status: waiting for opinions label.

Some examples of tickets like this in the past are:

• PHP 8.0 | Proposal for handling "namespaced names as single token" squizlabs/PHP_CodeSniffer#3041
• PHP 8.2: dynamic properties are deprecated squizlabs/PHP_CodeSniffer#3489
• Possible improvements for sniff performance analysis squizlabs/PHP_CodeSniffer#3784
• The Future of PHP_CodeSniffer squizlabs/PHP_CodeSniffer#3932

And some current examples:

• 4.0 | Rename master branch to stable #3
• Proposal: treat deprecations/notices/warnings coming from sniffs in a more end-user friendly manner #30
• New Feature: handle deprecation of sniffs natively #164
• New Feature: only load sniffs containing fixers when PHPCBF is run #165
• 4.0 | Revise exit codes for PHPCS and PHPCBF commands #184
• 4.0 | Filters/ExactMatch: remove getBlacklist() and getWhitelist() methods #199
• Upcoming: proposal about adding type declarations to public API methods in PHPCS 4.0 (parameter) / 5.0 (return).

Typically, these type of tickets can benefit from the input of external standards maintainers / tooling integrators, whether it is to make sure that a certain impact/use is not overlooked or to measure support for a proposal.

Up to now, I've often semi-randomly added some people in a cc list to these tickets, often based on who came to mind and/or who I'd seen as recently active or based on the history of affected code.

I never meant to exclude people or offend by forgetting to mention someone and apologize if anyone has felt bypassed in the past. This was never my intention.
Along the same lines, I never intended to bother people who don't want to be bothered with these type of tickets.

Going forward, I'd like to take the "randomness" out of the equation.

Proposal

I'm proposing to add a community-cc-list.md file to the .github folder with a list of GitHub handles of people who would like to be informed of these type of tickets.

That list will then be used, when appropriate, to ping the right people on a ticket.

As the list will be in a simple markdown file in the repo, anyone can add themselves to the list and/or remove themselves at any time via a PR.

PRs adding/removing other people to/from the list will only be merged if the people being added/removed leave a comment on the PR consenting to it.

Now, you may already watch this repo. In that case, being on or off this list will not directly impact you as GH will only send you one notification anyway. You may still choose to be on the list anyway.

So, I'm hoping this will be the last time I'm using a "random" list of people to cc:

/cc @kukulich @wimg @weierophinney @GaryJones @dingo-d @klausi @photodude @Potherca @webimpress @fredden @michalbundyra @sirbrillig @othercorey @greg0ire @dereuromark @umherirrender @stronk7 @Ocramius @anomiex @derrabus

Open question

Should there be one list ? Or should there be two separate lists, one for external standards maintainers, one for integrators ?

Action plan

I'll be opening the PR to add the file in a moment and will leave this proposal and the PR open for the next two weeks or so.

If you want to be on the initial list, just leave a comment on this ticket or on the PR and I will make sure to include your handle before merging the PR.

If there are any concerns about this proposal, please raise them by leaving a comment.

[Ocramius]

Typically, these type of tickets can benefit from the input of external standards maintainers / tooling integrators, whether it is to make sure that a certain impact/use is not overlooked or to measure support for a proposal.

Agreed.

I'm proposing to add a community-cc-list.md file to the .github folder with a list of GitHub handles of people who would like to be informed of these type of tickets.

@jrfnl you could also add these people to a limited scope/access group, that becomes pingable under @PHPCSStandards/group-name, FYI. Obiviously, this requires someone with admin access to add/remove people, but somebody would merge .github changes anyway, so... 🤷

[jrfnl]

I'm proposing to add a community-cc-list.md file to the .github folder with a list of GitHub handles of people who would like to be informed of these type of tickets.

@jrfnl you could also add these people to a limited scope/access group, that becomes pingable under @PHPCSStandards/group-name, FYI. Obiviously, this requires someone with admin access to add/remove people, but somebody would merge .github changes anyway, so... 🤷

@Ocramius IIRC that would require people to become members of the PHPCSStandards organization though before they could be added to such a group ? Or am I mis-remembering this ?

Seems simpler to allow this to work via PRs. That way, when the pool of people who can merge PRs will grow, anyone with merge access can handle these type of requests, no need to always get an admin involved.

[kukulich]

Looks good to me and I would be happy to be on the list :)

[greg0ire]

Count me in as well 👍

[Ocramius]

@Ocramius IIRC that would require people to become members of the PHPCSStandards organization though before they could be added to such a group ? Or am I mis-remembering this ?

Yes, correct, but the notification flow allows for easier pings.

Anyway, happy to be on the list with either approach, just proposed something that worked well in other orgs :-)

[jrfnl]

@Ocramius IIRC that would require people to become members of the PHPCSStandards organization though before they could be added to such a group ? Or am I mis-remembering this ?

Yes, correct, but the notification flow allows for easier pings.

Anyway, happy to be on the list with either approach, just proposed something that worked well in other orgs :-)

@Ocramius Appreciated. I may well look into this at some point in the future anyway, but let's start with the md file approach.

@kukulich, @greg0ire @Ocramius I've added all three of you to the initial list in PR #228 now.

[wimg]

As always, happy to contribute where and when I can ;-)

[dingo-d]

You can add me, sure :) Although we mostly work on the same codebase so I'm usually in the loop about the changes 😄

[asispts]

I'd like to be included on the list too. Thanks.

[jrfnl]

@wimg @dingo-d @asispts I've added you to the initial list in PR #228 now.

[fredden]

This makes sense. While I am currently "watching" this repository, I do get different notifications when mentioned versus just watching. I'd like to be on this new "sometimes CC'd" list.

[jrfnl]

@fredden Added!