This issue is aimed to figure out the best way to increase interoperability of Commons features by adopting Drupal 7 distributions best practices and standards.

Problem/Motivation

In Drupal 6, many features-based distributions were developed in a fairly monolithic way, in that key architectural decisions and interdependencies made it hard or impossible to structure features in a way that would be interoperable with other Drupal sites, including those based on other distributions.

Commons shares goals with the OAS around making features easy for site builders to configure, having functionality split off into discrete projects as much as possible, and providing solid documentation. Similarly, the Commons MVP requirements state that site builders should, "Be presented with a clear listing of features and minimum necessary configuration steps" and that "If multiple features are enabled, walk through setup of each".

Related issues:

Proposed resolutions

  1. Commit to Commons being developed inline with above stated goals that Commons shares with OAS.
  2. Adopt and enhance the (currently rudimentary and outdated) Kit initiative for Feature interoperability.
  3. Adopt Open App Standard via Apps module/server.
  4. Work together with the Open Atrium developers and any other group-based distribution developers to work out some common bases for compatible groups solutions. Issue: #1555436: Define Groups extension to Kit features specification.

Remaining tasks

Ezra-g will make an effort to get more involved in discussions around OAS, Kit, and the proposed DDX commitment.

Comments

mariomaric’s picture

Title: Leverage Open App Standard » Officially adopt Open App Standard
Issue tags: +architecture

I'm changing title to be more accurate, because somebody can make App and just put Apps module as required module - but the point is to officially support OAS.

One thing that crossed my mind is that we can then develop, for example, Ideation and Q&A features as Apps.
In that case apps can have autonomy, interoperability and own development rhythm, among other things.

Also, IMHO this is probably good candidate for architecture tag..please change issue details if I misunderstood something...

ezra-g’s picture

Status: Active » Needs review

In my view, Commons shares goals with the OAS around making features easy for site builders to configure, having functionality split off into discrete projects as much as possible, and providing solid documentation. Similarly, the Commons MVP requirements state that site builders should, "Be presented with a clear listing of features and minimum necessary configuration steps" and that "If multiple features are enabled, walk through setup of each".

(Note, when referring to the OAS, I'm looking at the official OAS draft at http://groups.drupal.org/open-app-standard/oas rather than the off *.drupal.org page referenced in the OP.)

Barring any unforeseen technical reason that makes it really problematic to do so, I definitely intend for as many of the Commons feature modules to live as their own separate projects as possible. Commons Ideas/ideation and Q+A are great fits for being developed as independent projects.

At the same time, it seems like OAS and Kit are somewhat in flux because OAS is still in Draft status and Kit, an important part of OAS, needs redefinition for Drupal 7 but hasn't seen a commit in over a year. There's also a proposal for a Drupal Distribution Experience (DDE) commitment.

Using an App server as the primary method of code delivery for Commons is a non-trivial departure from using Drush make the Drupal.org packaging system and is therefore unlikely to be prioritized for a Drupal 7 MVP. However, I can see a Commons app server as a possibility in the future. In the meantime, I'd rather focus on committing to the Web Content Accessibility Guidelines (WCAG) 2.0 Level AA.

I propose Commons commit to being developed inline with above stated goals that Commons shares with OAS. At the same time, I'll make an effort to get more involved in discussions around OAS, Kit, and the proposed DDE commitment.

Marking as needs review based on that proposal.

mariomaric’s picture

OK, I updated the issue summary based on provided feedback in this and #1555434: Define Kit/interoperabilty goals for Commons issue.

ezra-g’s picture

Title: Officially adopt Open App Standard » Commons position on Open App Standard

Awesome - thanks, mariomaric! Retitling the issue slightly.

mariomaric’s picture

C/P of comment posted by bonobo:

Just wanted to throw this out there:

Is full interoperability between distributions realistic for distributions in D7?

I can see a lot of benefit for creating features that will work within different instances of the same distro - but, most features (or at least the ones that are interesting enough to want to replicate across multiple sites) make some assumptions about UX, which (generally) implies some assumptions about contexts, regions, and the theming layer.

In short, this is not a simple problem that can be solved by more collaboration.

We are definitely interested in being part of any solution for these issues, but it's worth being explicit about the reality that true interoperability is not a simple thing to accomplish.

mariomaric’s picture

I would go even further: is full interoperability between Drupal distributions necessary at all?

Just like bonobo stated in #5, most features have specific UX and that's even more obvious in Apps because they have additional UX/UI layer above the features.

My first intention with this issue was the idea of Commons following Drupal distributions best practices and standards so that developers who want to extend and build on top of Commons can do it in consistent, documented and as easy as possible way.
Side effect of that could be also huge benefits for end users and distribution site builders.

Trying to force features and Apps to be full interoperable with other (similar?) distributions could be really PITA - as far as i can see, even to develop as more as possible decoupled and independent features is not easy to accomplish (e.g. #1549014: Select a page building tool).

Instead, IMHO, it would be great to work on establishing best practices and standards on how to build Drupal 7 distribution, and, more importantly, improve existing and create new tools (modules!) that can help us achieve above mentioned goal (e.g. #1549442: Use Message API for Activity stream functionality).

Then we could maybe provide based distributions (e.g. Panopoly, Spark, Commons?) that could be used as foundation for some specific use case - you would just need to create specific feature or App and package it together. IMO, this is more sustainable way to flourish Drupal distributions. :)

ezra-g’s picture

Status: Needs review » Fixed

Is full interoperability between distributions realistic for distributions in D7?

I see 100% compatibility between every distribution, app and feature as unrealistic, but I think developing with the general goal of interoperability where possible will go a long way.

It seems like the general position for Commons has been clearly articulated by several folks and like we've got some agreement on the position here - Marking as fixed, but feel free to re-open for further discussion.

Thanks for the input, folks!

bonobo’s picture

Status: Fixed » Needs review

marionmaric - thank you for moving my comment to the actual issue where the discussion is taking place - this technology stuff is hard :)

RE: "even to develop as more as possible decoupled and independent features is not easy to accomplish"

Strongly agree here. One way to start down this road is to split features up so that things like field definition are separate in their own feature, views are contained in their own feature, contexts separate in their own feature, etc, and then you manage your dependencies b/w features carefully. By doing this, someone can grab the features for the content/entity types and field definitions, and views, but not use the context feature (as one possible example).

But this approach really helps site builders the most (as opposed to site admins/maintainers), and a competent site builder will generally be able to define their own entities and build their own views.

As we talk about various approaches to using features that have the potential to harden into a standard, we should look at how features are structured. I've seen a lot of monolithic features where the site builders threw everything into one huge feature. While this is better than not using features at all, it's only marginally so, as any change to config covered by the feature causes the whole thing to be overridden.

RE:

Instead, IMHO, it would be great to work on establishing best practices and standards on how to build Drupal 7 distribution

Agreed.

ezra-g’s picture

One way to start down this road is to split features up so that things like field definition are separate in their own feature, views are contained in their own feature, contexts separate in their own feature, etc, and then you manage your dependencies b/w features carefully.

The Features project page states:

A feature is a collection of Drupal entities which taken together satisfy a certain use-case.

If we break down features into their technical components and export them separately, it would seem that the individual features would no longer meet this goal. I'd rather focus on architecting with an eye towards interoperability.

I've seen a lot of monolithic features where the site builders threw everything into one huge feature.

I agree that this could be problematic, particularly in places where it unnecessarily adds dependencies into an unrelated feature.

@bonobo, since you re-opened the issue, can you describe which action items remain?

mariomaric’s picture

@ezra-g: I think that reopening of the issue was unintentional - it was consequence of almost simultaneosly posting two issues.

bonobo’s picture

Status: Needs review » Fixed

@ezra-g - re re-opening the issue - as @marionmaric said, we were cross-posting.

Setting back to fixed, as it seems we are all in agreement here.

RE:

If we break down features into their technical components and export them separately, it would seem that the individual features would no longer meet this goal.

It depends on how we define use case - if we are solving a use case for the an end user (ie, someone just using the site) then definitely, bigger is better. If we are solving for the use case of the site builder (ie, we do this on just about every build) then breaking things down and using dependencies between features is far easier.

But in any case, this implementation decision is only tangentially related to this issue, which is fixed.

Automatically closed -- issue fixed for 2 weeks with no activity.

Anonymous’s picture

Issue summary: View changes

Updates based on provided feedback...