Open jrfnl opened 10 months ago
Semantic point but I would second @kenguest's suggestion of naming and referring to the repo and standard as PER-CS
(or a variation thereof) rather than PSR-PER
. PSR specifically refers to PHP Standards Recommendations whereas PER refers to PHP Evolving Recommendations; combining the two feels like mixing separate interests (even as PER is an extension of PSR-12).
Gentle reminder, @jrfnl, that there is a migration document detailing the differences between PSR-12 and PER-CS v2 at https://github.com/php-fig/per-coding-style/blob/master/migration-2.0.md should it need to be consulted for supporting PER-CS in PHP CodeSniffer.
This link hadn't been copied over from the squizlabs/phpcs ticket that I filed over a year ago.
This link hadn't been copied over from the squizlabs/phpcs ticket that I filed over a year ago.
@kenguest Yes, that comment was posted in the gap between when I opened this issue and the official take-over announcement, which is why it wasn't copied over.
I'd actually been thinking off this issue not too long ago.
If it wasn't clear from the above, my preference would be for this new repo to be run by a team of ~two maintainers, with me available in the background for consultation when needed.
The "vacancy" description for these roles would be as follows:
For the initial setup, I'd estimate approximately a week's work. For the continued maintenance, I'd estimate 1 - 2 hours a month. For the optional tasks... I don't dare to put an estimate on that.
The call for volunteers for the above is open.
If anyone is interested, but wants help getting started, I'm happy to plan a few pairing sessions via videocall to help with the initial setup.
If there are several people who are potentially interested, but not yet sure if they are up for it, I'd be open to a mob programming session to help people get more familiar with the moving parts/answer any questions/explain whatever needs explaining.
Anyone who is interested in getting involved with this, please, please leave a comment on this ticket.
@jrfnl Any update on this issue? Have you managed to setup a new PER-CS repo or find someone who willing to volunteer?
@stankarp If there had been volunteers, you would have seen their comments in this ticket (or a comment by me that people had reached out privately), so no progress so far, unfortunately.
My offer to help get this off the ground with some videocalls to get the maintainers started is still open.
@jrfnl I'm considering supporting this. I do not have loads of spare time, but I would love to work on this. According to your 'to do' list above, my first question would be. Is this desirable in a separate repo, or integrated into this repo?
@jrfnl I'm considering supporting this. I do not have loads of spare time, but I would love to work on this. According to your 'to do' list above, my first question would be. Is this desirable in a separate repo, or integrated into this repo?
That would be great!
It will be in a separate repo, but, as far as I'm concerned, the repo will be in the PHPCSStandards organisation.
The reasons for having a separate repo is quite straight-forward:
Does that answer your question ?
Fair enough.
PER 1.0.0 is identical to PSR-12, so this will be an "easy fix".
What is a good approach to get started? Start a repo under my own name and then migrate later to the PHPCSStandards organisation?
Fair enough.
PER 1.0.0 is identical to PSR-12, so this will be an "easy fix".
Correct, PER 2.0.0 is the bit which needs work (and setting up the repo and CI etc).
What is a good approach to get started? Start a repo under my own name and then migrate later to the PHPCSStandards organisation?
grin I actually already created a private repo in this organisation for it. Let me see if I can invite you to that.
Would you like to set up a call to talk things through ? If so, probably best to sort that out off-GH. You can DM me on Mastodon, X or - seeing your location - on the PHPNL Slack.
I'll get in touch tomorrow to schedule something. :-)
I don't have too much spare time but willing to help out on some of the work. I also don't have too much experience contributing to open source but i have to start somewhere :man_shrugging: Let me know if there is anything i can do.
Repost from https://github.com/squizlabs/PHP_CodeSniffer/issues/3793:
@kenguest asked:
I replied:
@kenguest replied:
My current line of thinking on this is as follows:
PER-200
, to prevent it from becoming a moving target failing builds at random. Each ruleset can include the previous version and build on top of that.PER-latest
, which would include the ruleset for the current version and would need to be updated each time a new version is added.PSR-PER
.PSR-PER
repo would only contain rulesets, not sniffs.