Governance of the Kit Spec [#1456518]

Thanks to febrarro, I just got the keys to Kit. However, I can't run wild with it. DevSeed built this spec for a particular approach to module and theme building. At this point, there are a number of people, especially distribution maintainers, that need to be on board with any significant step in order for it to move forward while staying relevant.

That means that I can be a coordinator and a contributor, but there needs to be some kind of consensus for content changes. How should we resolve that? Drupal does not really have infrastructure or workflows built around defining standards, so it's going to be awkward.

I have a few ideas about how to resolve the decision-making and collaboration around Kit. They can all be separately implemented.

Move strategic decisions to a Kit Working Group on GDO. Issue queue is used for text changes & review. (done)
Move text composition (and the working copy of Kit) to GitHub. Forking/Pull Requests seem like a much more sane workflow than patches for prose. D.O would still host canonical snapshots.
Prefer new ideas in Kit to be written as part of a standard extension. E.g., The Debut standard. However, we should run with the idea that an extension extends, rather than contradicts, anything in Kit itself. All modules should tag .info files with Kit and every extension standard they support.

Comments

Comment #1

patricksettle CreditAttribution: patricksettle commented 29 February 2012 at 22:41

Great ideas, I especially like the move to GitHub for the working copy. Will make it much easier for people to contribute. (*secretly wishes d.o had moved to github during the great git migration)

Comment #2

btopro CreditAttribution: btopro commented 2 March 2012 at 07:01

Big fan

Some other suggestions:

Instead of just language about how to implement Kit, how about a template feature / example module that would theoretically work anywhere.

Also there are some modules in dependencies and functions that can help make things like Context block placement even more cross-platform compatible (like http://drupal.org/project/regions) or the use of theme_registry_alter to enforce a standard look and feel for the feature incoming.

Comment #3

febbraro CreditAttribution: febbraro commented 2 March 2012 at 16:13

Those ideas sound good to me. I especially like #2, the fork/pull request workflow is really nice for more than just code.

Comment #4

Grayside CreditAttribution: Grayside commented 3 March 2012 at 07:45

@btopro: I think an example feature demonstrating Kit conventions is an excellent idea. As would be a simple drush command to "validate" the components of a named feature. Building both of those is an example of something that I would say should remain as part of the D.O repository & sorted out in this issue queue.

Documentation on applying Kit, and modules that facilitate it's philosophy are something else. I'd say that's where handbook pages should step in.

Comment #5

btopro CreditAttribution: btopro commented 3 March 2012 at 23:51

Agreed. Really like the validation idea. I'd be willing to pitch in on making a module / UI side to it. Seems like it could be a nice little stamp next to each feature on the features page thats like a "kit certified" type of mark. If it's NOT kit compliant it could also have a tab in the feature where revert and diff show up to try and communicate how to make it kit compliant.

Comment #6

Grayside CreditAttribution: Grayside commented 4 March 2012 at 01:53

Great idea. Let's spin that off to separate issues and return this thread to it's topic.

Comment #7

Grayside CreditAttribution: Grayside commented 21 March 2012 at 14:27

Kit spec moved to github. Again, this is to provide better tools around collaboration on text, the only valid-for-reference version will be on Drupal.org.

https://github.com/grayside/kit

Comment #8

nedjo

he/him/his

English

CreditAttribution: nedjo commented 3 April 2012 at 02:34

Thanks for taking the initiative Grayside.

I've been musing about how we should approach this. The Dev Seed devs made a good start with Kit, but there's lots more to do. As we see an explosion of features and Apps sets, there are many sources of incompatibility that reflect basically meaningless differences, like how a particular field or role is named.

To address this, we could look at pulling a lot more specificity into Kit. But doing so would increase the barrier to compliance. Alternately we could, as suggested, evolve various extensions to kit, as I tried to do in Debut. But, if the Debut experience is any indication, an extension is may be unlikely to gain a lot traction and/or may be too specific to be broadly usable. Possibly what we need is nested Kit specifications. Kit basic would stay pretty much as it is, almost universally applicable, but there would be a higher level of Kit with more specified.

I'm not clear on why we need Github. Is it that we can't fork and pull on d.org?

One todo is update the Kit project page with explanation of how governance works, including a link to the github repo.

Comment #9

Grayside CreditAttribution: Grayside commented 3 April 2012 at 18:22

Thanks nedjo, that's the idea of the Kit extensions. We can't have conflicts in standards, at bear minimum we will confuse people. I've also been thinking of this as the seed for broader standards, not so much what should be in a feature, as how different features should relate to each other. E.g., a Kit Distro extension defining where to put dedicated content management pages.

I don't find patches to be a tenable way to review documentation changes, and with general approval moved forwards to use github for this. Forks/Pull Requests as a mechanism are at least close to the old-school manuscript-shipping method of collaboration.

Comment #10

btopro CreditAttribution: btopro commented 4 April 2012 at 02:39

Like the idea of tiered compliancy, I could definitely see OG based features falling into one of these separate tiers of compatibility. Also, theme regions would need to be taken into account as part of the "core" level of compliancy as it relates to blocks placed into contexts. Name spaces could be compliant but a block region name may be non-standard and then coming up with ways of dealing with that (like http://drupal.org/project/regions which has a way of "repairing" themes that don't implement a region) could also fall into a different tier of compliancy (non-standard theme region yet provides its own method of dealing with it).