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:
- #1554852: Define Drupal Distribution Experience (#DDX) commitment
- #1524868: Have D7 GDO run a distribution profile (such as Drupal Commons)
Proposed resolutions
- Commit to Commons being developed inline with above stated goals that Commons shares with OAS.
- Adopt and enhance the (currently rudimentary and outdated) Kit initiative for Feature interoperability.
- Adopt Open App Standard via Apps module/server.
- 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
Comment #1
mariomaric CreditAttribution: mariomaric commentedI'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...
Comment #2
ezra-g CreditAttribution: ezra-g commentedIn 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.
Comment #3
mariomaric CreditAttribution: mariomaric commentedOK, I updated the issue summary based on provided feedback in this and #1555434: Define Kit/interoperabilty goals for Commons issue.
Comment #4
ezra-g CreditAttribution: ezra-g commentedAwesome - thanks, mariomaric! Retitling the issue slightly.
Comment #5
mariomaric CreditAttribution: mariomaric commentedC/P of comment posted by bonobo:
Comment #6
mariomaric CreditAttribution: mariomaric commentedI 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. :)
Comment #7
ezra-g CreditAttribution: ezra-g commentedI 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!
Comment #8
bonobo CreditAttribution: bonobo commentedmarionmaric - 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:
Agreed.
Comment #9
ezra-g CreditAttribution: ezra-g commentedThe Features project page states:
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 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?
Comment #10
mariomaric CreditAttribution: mariomaric commented@ezra-g: I think that reopening of the issue was unintentional - it was consequence of almost simultaneosly posting two issues.
Comment #11
bonobo CreditAttribution: bonobo commented@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:
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.
Comment #12.0
(not verified) CreditAttribution: commentedUpdates based on provided feedback...