Discussion & Vote: PL-PIG

[dmolsen]

@bmuenzenmeyer @bradfrost -

I know we have plenty of other things to worry about but I wanted to revive The Spec and add some formal rules to govern it. I realize that I've done a shit job of documenting what's in PL/PHP2. Not just from the nonexistent user documentation but, for our purposes, developer documentation regarding what each piece is expecting. As we roll this project out further I'm sure PL/PHP2 will continue to evolve in a way that affects what should be standard inputs and outputs all core implementations track. The same can be said for PL/Node.

What I'm proposing:

1. The formal adoption of the Pattern Lab Port Interop Group (PL-PIG) (more details)
2. That the voting membership of PL-PIG initially consists of one voting rep each from PL/Node and PL/PHP (Brian and me?). We would then vote on including Brad as a tiebreaker vote and someone who will give a nod to the user's view.
3. That we use this repo to track voting on features that should be added to PL/* Core. Discussion can start in the appropriate repo or Gitter but a vote needs to happen here if it affects Core. Any other part of the ecosystem is exempt as Core should be determining either the interface (aka PatternEngines, Plugins) or the install process (aka StyleguideKits, StarterKits). The install process will be a recommendation because I know each dependency manager does things differently.
4. That I revise The Spec and push to a v2.0.0 version to match where PL/PHP2 is currently at. We could then start proposing changes to that base. I know Geoff has had some good ideas as have the Drupal folks. Honestly, that's my big concern. I want a way to document that each implementation is onboard with those ideas.

I won't be able to get to updating The Spec until later this month but I wanted to propose this before I disappeared.

@bmuenzenmeyer - if you have questions let me know. if you are cool with it just add a +1. We'll then vote on Brad and move from there. I just want that vote recorded for posterity.

[bmuenzenmeyer]

I'll add some comments to my vote too.

The formal adoption of the Pattern Lab Port Interop Group (PL-PIG) (more details)

I like the structure of this document - and the spec in general - as it will serve as a vehicle for better interop between PL/* implementations. @geoffp and I have known for a while that integrating with the shared assets would be "regressing" on some feature-creep that made its way into PL/Node 1.X like defaultPattern and baseUrl, and more recently, some PRs that were declined due to their proposed changes to the soon obsolete PL/Node 1.X Core. In those two former cases, the PL-PIG can be engaged as to whether to add them to the shared assets and core.

You are right that the folks at Target and I are envisioning feature growth, for example, in starterkits, and I'd feel much better if we discussed, designed, and built something like that into the spec so all users could eventually benefit from them.

We would then vote on including Brad as a tiebreaker vote

I think that makes a lot of sense - he has the most operational experience using PL. I'd also think the Phase 2 and Target people are pretty active voices here, as are others, but limiting it initially might be smart.

The install process will be a recommendation because I know each dependency manager does things differently.

I am most "worried" about this, albeit only a little - and only from a true npm upgrade semver perspective. After this issue is closed I will open a new, more detailed one about specification versioning

My final thought is whether this is a priority versus documentation and getting PL/* 2.0.0 ready for WebDesignDay mid-June. That's always been my goal. Perhaps this repo and process is lighter-weight that I imagine at first glance, and it will be a formal means to document some of the discussions that already go on.

Love the direction, along with the docs. An exciting time for the project. Thanks for putting this together Dave.

[dmolsen]

The install process will be a recommendation because I know each dependency manager does things differently.

I am most "worried" about this, albeit only a little - and only from a true npm upgrade semver perspective. After this issue is closed I will open a new, more detailed one about specification versioning.

When I say "install process" I'm talking about the way PL/PHP hooks into Composer events to allow packages to modify the config, register event listeners, and move/install files around the project layout. InstallerUtil might be close to the biggest class on the PHP side now. I'm not sure that level of control/automation needs to be duplicated on the Node side. Maybe Node could/would use something native to Node like Yeoman? There's more native tooling on that end for Node than PHP.

My final thought is whether this is a priority versus documentation and getting PL/* 2.0.0 ready for WebDesignDay mid-June.

While the latter is the priority I think we have ideas bubbling that need to be formalized and prioritized as we push beyond v2.0.0. I'm already thinking about redoing how panels in the viewer pull in content. That would require changes to how core currently operates but allow people to add their own panels for CSS/JS without us having to formally adopt them.

[dmolsen]

I've added my vote. I'll call this approved and move it to closed. Feel free to continue the discussion. I'll open an issue for formally approving Brad as a voting member.

[bradfrost]

Do you guys need anything from me on this?

[dmolsen]

Unless you have anything critical, no. Just be aware you have voting privileges on future issues that crop up here and are requesting a vote. So if you think "shit, this sucks" feel free to vote down or vice versa.

[bradfrost]

Got it!