Roadmap for separation?

WPTT / WPThemeReview

PHP_CodeSniffer rules (sniffs) to enforce WordPress theme review coding conventions

MIT License

208 stars 38 forks source link

Roadmap for separation? #163

Closed dingo-d closed 5 years ago

dingo-d commented 6 years ago

Do we have any roadmap for the standards separation?

Maybe it would be good to have some milestones that we want to have before separating the standards - the number of PRs merged, issues resolved etc.

It would be good, because wprig is currently using WordPress (in addition to WordPress-Core, WordPress-Docs and WordPress-Extra), and I suggested that it would be better to use WordPress-Theme instead (especially since WordPress loads every standard in the WPCS). But when I went ahead and try to implement it, I couldn't get it to work for some reason. So before making any further changes to wprig, it would be better to have the standards separated in my opinion.

Suggestions, thoughts, opinions are welcomed :)

CC @jrfnl @grappler @ernilambar @pattonwebz

jrfnl commented 6 years ago

Proposal roadmap:

A number of the open PRs still need some work, let's get that done & merge or close them within the next few weeks.
- Do we want to set a deadline ?
- Do we want to set up a call in a few weeks to talk through the open PRs & clean the slate ?
By the time that's done, WPCS 1.0.0 should be out.

After that, IMO we can just separate the Theme ruleset into a stand-alone standard.

If we do so in this repo, the PR for this will be horrific, but that's a one-time-only price to pay. The main problem is that we cannot indicate that this repo is no longer a fork of WPCS.
The alternative is opening a new repo for the "clean" stand-alone standard, but that would loose the history/issues etc.

I'd like to suggest contacting the GH helpdesk to see if they know of some "hack" we can use to get round this.

dingo-d commented 6 years ago

I think a good deadline would be a week after the WPCS 1.0.0 is released, and I'm definitely open for a meeting, we should just coordinate to find the best time.

I'm more inclined to have a new, separate repo, and archive this one. This way the history will be preserved, but we'll have a clean start in the new repo. Any open issues can be manually rewritten (this can be done in an hour or two).

If there's a way to just 'defork' this repo even better, but I doubt that there is an easy way to do it.

pattonwebz commented 6 years ago

I've been on a project before where they had to switch from a fork to a standalone repo and the only way to do it I believe is to reach out to support and ask them to do it behind the scenes.

It's a quick process, I think it only took them like an hour from when they reached out till when it was completed.

dingo-d commented 6 years ago

@pattonwebz That's even better news :)

jrfnl commented 6 years ago

See #169 for a detailed action list

jrfnl commented 5 years ago

As the repo history has now been rewritten and the change is contained in the develop and master branch, I'm closing this issue.