Establish heuristics for core feature evaluation

Thanks so much for splitting this productive discussion off from the Thread of Doom™. The criteria looks pretty great at first glance. I'll take a closer look later.

Have we decided against "Core as Framework; Distributions as Product"?

This issue is mute if we go in that direction. Going the distribution route, we'd be best served to strip everything out of Core except the framework and bring in all the modules back in from contrib in packaged distributions.

retagging

I tried to deal with the false dichotomy of framework vs. product in http://ca.tchpole.net/node/4. These heuristics can be applied to very low level APIs as well as particular end-user features and lots in betweeen. The packaging approach allows you to split, but it does not determine exactly where that split is (or that you can do the splits without pulling a muscle).

Thank you for #6. :)

Michelle

I tried to deal with the false dichotomy of framework vs. product in http://ca.tchpole.net/node/4. These heuristics can be applied to very low level APIs as well as particular end-user features and lots in between. The packaging approach allows you to split, but it does not determine exactly where that split is (or that you can do the splits without pulling a muscle).

I'm trying to clear up is whether this is a discussion about the split between...

• Drupal Product and Contrib
• OR...Drupal Framework/Platform and Drupal Product(s)

I read it as a split between things that are handled by the core development "team", regardless of how the framework/product discussion ends up, and things that are handled by contrib maintainers.

Michelle

It's a discussion about what "rules of thumb" can be used when weighing a particular piece of functionality for inclusion, removal, or refactoring.

Are we talking about what should be included, removed, or refactored in the core as the "product"?

If so, then this discussion will completely changed if we move to a distro model because we won't have ONE product...but many.

So we really need to know this first: Is core going to be the product in D8? Or will there be multiple products for D8?

I don't follow item 4. If something can be controlled from multiple UIs, it should be in core? If something can be controlled from multiple UIs I'd say that's a good thing in general, but I don't think that automatically means it belongs in core.

And subscribing. :-)

There are some domain-specific questions that aren't covered (like accessibility,

Whether a particular component is accessible should not be a factor for its theoretical inclusion in Core. Whether it is possible to make such a component accessible ought to be a criteria. Clearly this almost always only applies to components with a UI.

E.g. Should a modal dialog component be added as a renderable element in Core? One would, at least, want to know if it is possible to make the modal dialog UI pattern accessible.

sub

@catch I was wondering if trying to sort APIs and core modules into your model of Levels and sorting out dependencies in a graphic picture could help decide how low-level stuff is and how other stuff is building on it.
Sorting out these Levels and getting clear where stuff is might help.

e.G. if there is something that is very low-level and this part of Drupal is old cruft but lots of other parts depend on it, this is where work would have to start.

Working from the bottom upwards gives some Logic and order to this otherwise tangled mess.

@eigentor I think that'd be great, but it also runs the risk of looking like this at the moment. However if we didn't look too closely at some of the circular dependencies I reckon it'd be doable to come up with something.

I started out over here https://docs.google.com/drawings/d/1QVqmARfsYeyA22j9OuLHCp18cNgeX4f4dIBL...
This should be editable to anyone.

I guess it makes no sense to try to list everything on there.
Also it probably makes no sense for now to list all the dependencies, this would be another graphic. There could be more dimensions inside the area, as to how old and outdated parts are, which could be indicated by color, how much code certain parts contain, which could be indicated by size and shape of the bubbles (there are lots of shapes available = fun :) ). Color stuff red that practically everything depends on, or maybe that is totally outdated and a pita for all progresss...

I am not sure if this becomes useful, but all this talk about modules and elements can at least made be visible with such stuff. And nothing depends on Blog module and is clearly a product-type kind of feature: to the utmost top right it goes.

If you think there are specific criteria in this post that simply wouldn't make sense if we went to a distro model, that probably makes sense to flag and discuss here.

If we don't have a clear definition of core to start with, how are we ever going to come up with criteria on what to include in core. My concern is your list is too vague to be useful. Especially adding to the fact that it's not a hard and fast set of rules. If this is going to be a vague and subjective approval system is there really a point to having it?

Can you give me an example of how this list would help us figure out inclusion (or exclusion) of the following features:

• Blog API
• WYSIWYG
• Content Creation Kit
• Views

subscribe

subscribe.

One thing that I feel is missing from the proposed list of heuristics is something around user experience, matching user expectations, something like that.

Let's take the example of a separate administrative theme, which was added in Drupal 7.

---

- Is it needed for Drupal web sites, automated tests, installation profiles, or drush commands to operate properly?

No.

- Is it a "defining" quality of Drupal or an important differentiator from other web CMS projects?

No. Rather, the inverse; the *lack* of an administrative theme leads to a much steeper learning curve for new users and content editors because it breaks expectations that other CMSes set.

- Is it a "building block" that can be used to implement many different user-facing features?

No.

- Can it be controlled or managed from a variety of tools (drush, GUI admin tools, install profiles, packaged configuration, etc.)

No? (Sorry, I really don't understand what this one means; could probably use refinement.)

- Would it be impractical or impossible to implement as an optional plugin or contrib module?

Nope. Perfectly practical to implement in contrib, see Rootcandy, Rubik, etc.

- If more robust solutions to the same problem exist in contrib, is it compatible with or "easily migratable to" the contrib solution?

Yes. Just download another theme and change the setting.

- Does it have a positive or neutral impact on the number of "tightly coupled" connections and dependencies between different parts of Drupal?

Yes? I think it's neutral? But this heuristic could do with a bit more refinement, I think. Not quite clear how you would evaluate this on a feature-per-feature basis.

- Does its presence significantly improve the experience of first-time evaluators, experienced builders, or developers building on top of Drupal -- without significantly diminishing the experience of the others?

Yes.

---

So you have a separate administrative theme meeting 3 of the 8 criteria. Not much more than Blog API, really. And this was a super contentious thing when it went in, because core developers were used to how the old admin interface worked, they considered a separation between front-end and back-end something that other CMSes were doing it wrong, they misliked the process around D7UX, they thought the theme was ugly, they thought the theme wasn't flexible enough, and 100 other things.

OTOH, of all the D7UX changes, this was easily the single most beneficial one made, because suddenly our users have orientation. They know instantly, visually, starkly, the difference between when they are in an administrative context and when they are viewing their site as a user would see it. Suddenly Drupal behaves the way the rest of the Internet expects a CMS to behave. And our D7 usability testing gets to actually test D7, instead of testing the confusion around D6's Drupal's admin interface, because that all just fades in the background as a non-issue now.

So we need to ensure these heuristics empower the UX team to make sound, strategic, design decisions without core developers using these heuristics as a tool to block UX improvements they disagree with.

The admin theme example is indeed striking: the defining quality it brings to the experience rests in the API changes allowing the definition of an admin theme, which was somehow more easily defined in core. It did not rest in the actual admin theme being delivered, for which (better or not) alternatives exist in contrib.

So what you just demonstrated is the fact that a mechanism for an active theme had to belong in core so that its implementations could fulfill UX requirements, but that providing a core admin theme was not necessarily something to be provided by core.

In the platform/kernel/whatever vs product/distro/profile/whateverelse distinction, it seems this means it should belong to the latter, not the former, and yet the presence of an admin theme in core, as far as I can see, is not among the list of things to be removed. Which probably means something needs to be changed in these heuristics.

"So what you just demonstrated is the fact that a mechanism for an active theme had to belong in core so that its implementations could fulfill UX requirements, but that providing a core admin theme was not necessarily something to be provided by core."

No, what I just demonstrated was exactly the opposite. Drupal 6 had the mechanism in core to use alternate admin/front-end themes. It wasn't until we added an admin theme to core in D7 that our usability issues with user orientation went away.

Maybe: Is it something that is a general expectation from any CMS? Say, this would keep signatures and pictures on users in core and yes, the admin theme.

@webchick says the admin theme meets 3 of the 8 criteria but I actually think it clearly meets a fourth:

"Is it a 'building block' that can be used to implement many different user-facing features?"

Yes, absolutely it is; a number of modules (e.g. Views) are now shipping with a Seven-specific CSS file (and putting lots of effort into making that experience top-notch) based on the idea that a whole lot of users will be using Seven to administer views.

That's 4 out of 8 right there. With @chx's/@webchick's suggestion of "general expectation from any CMS" (which could just be an expansion or rewording of the 'defining feature of Drupal' bullet) that's 5 out of 8, which seems like a good number to me.

Perhaps what's also missing here is something about "required or used by other parts of Drupal core" (this was being discussed in the other thread, I think, before this one split off)? In this case, Drupal core ships with the standard install profile, which wanted an admin theme in order to achieve its UX goals. (Now some people might disagree with the standard install profile being in core in the first place, but that's a totally different issue; taking it as a given that it's there, we obviously want it to work as well as possible.) Add something like that and it's now 6 out of 9.

eaton: It sounds like webchick is also confused by criteria 4. I still don't understand that one. From your description, it sounds like it only applies to plumbing code (which is fine). And then... something that is only usable via the GUI would get a -1 on core inclusion? But by the same token, that would imply that anything that can be controlled from multiple front-ends should be in core, which I don't agree with. I think that one still needs some work.

I'd like to add the 'does something in core depend on it' one from the other issue as well. That's a practical issue in terms of removing features (i.e. anything in the standard profile would be a prominent ux change). As well we should at least partially validate large api additions on whether they can replace/enhance things in core. I doubt we'd have committed uuid support unless there was a plan to use it later, and that might have prevented what happened with actions.

If we're adding components, whether something in core would be able to use them or not feels like a consideration. We currently have several features that are completely disabled, or dead code in includes somewhere.

Maybe a criterion "Do many of the top 40 Contrib Modules build on it" could help. Which could not help Admin Theme in this situation, except that Views builds heavily on it which is a strong pro.

But stuff like Admin theme, and other, that define the UX, rather belongs in the default install profile rather than the core core, or is that a misunderstanding?
In an effort to shrink down the very core of Drupal, almost any user facing stuff is quite a few steps up the level-ladder.

The fact that the top 25 contributors contribute 85% of Drupal core patches (or whatever the numbers) creates a problem that renders a lot of this endevour useless (at least for the moment). As long as the same people that work on the very core have to maintain Snowman, there will be no relief in maintenance burden.

But being optimistic to have quite different maintainers for the more user-facing stuff in the future can paint a different picture.
I should hope that the further we go towards the user-facing level, the less knowledge of the lower levels people must have to contribute say to, Dashboard.

And if it is not possible to make this true the entire level system is not worth its gunpowder.

At least this is how I see the entire discussion: there is some stuff that may be really removed and moved to contrib, but the more interesting part is the seperation inside core, so the maintenance burden can be distributed between different interest groups.

And this again might attract different contributors: people that are proficient with Javascript but don't necessarily can nor want to understand field API.

subscribing, reading, thinking

Here's a good non-module example:

#308865: Drop IE6 support in Drupal core.

Is it needed for Drupal web sites, automated tests, installation profiles, or drush commands to operate properly?

No. Well unless you were using IE6.

Is it a "defining" quality of Drupal or an important differentiator from other web CMS projects?

No.

Is it a "building block" that can be used to implement many different user-facing features?

No.

Can it be controlled or managed from a variety of tools (drush, GUI admin tools, install profiles, packaged configuration, etc.)

No.

Would it be impractical or impossible to implement as an optional plugin or contrib module?
Security support would be impractical or impossible so was left in. edited to add, this required breaking down the 'feature' into more granular components (markup, css, js, security).

If more robust solutions to the same problem exist in contrib, is it compatible with or "easily migratable to" the contrib solution?
Not yet.

Does it have a positive or neutral impact on the number of "tightly coupled" connections and dependencies between different parts of Drupal?
Negative impact if you look at the patch that was committed - all kinds of IE6 hacks littered all over the place.

Does its presence significantly improve the experience of first-time evaluators, experienced builders, or developers building on top of Drupal -- without significantly diminishing the experience of the others?

No.

Does it match common patterns and best practices for similar tools and web applications?

No, lots of other tools and web applications are dropping it.

That's a mark in their favor. ;-)

I am concerned about the new criterion. What is a "similar tool and web application"? That almost begs the question of what type of tool Drupal is so that we can find something "similar". The answer to that criterion will vary widely depending on if you consider Symfony and Cake to be "similar", Zend and PEAR to be "similar", or Wordpress and Joomla to be "similar".

So while I support the concept there, we should be careful not to turn that into a circular dependency. :-)

sub

sub

I like how this set of criteria is evolving. I think it could provide a healthy starting point for discussing whether something should or should not be included in core.

As long we use these criteria to support our discussions and decision making process, and not as a law to force a decision one way or another, I'm very comfortable with them as is.

Excellent work.

eaton: I think you misunderstand me. The point is what does "similar" mean.

"Is this something people coming from Wordpress would expect?" is a valid question to ask.

"Is this something people coming from Zend Framework would expect?" is also a valid question to ask.

You'll get very different answers depending on which of those questions you ask. :-) If we want to ask both, then we run into whether we want an AND or an OR. Should Drupal have everything that Zend Framework (a "pure" component framework) *and* Wordpress (an application) users are used to? That would be one really big core...

The answer may be "yes", but I'm just highlighting it as a potential bikeshed spot unless we have a clearer picture of what "similar" means. And that's before we even get into the various proprietary systems we compete against...

Can't it be contextual? If we're discussing an API change, it should be discussed in terms of larger PHP standards, interoperability with other systems, etc.

If we're discussing UI changes, it should be discussed in terms of what general web users expect based on de-facto standards and what other CMS-ish things do.

I guess I don't really see a need to spell it out that much. Obviously, if we're introducing a new HTTP library, we're going to be looking at Zend/Symfony, and not so much WordPress and PHPNuke.

Perhaps something like "does it match industry best practices, standards, and expected conventions?" That side-steps the "similar" question and allows us to look at the web industry as a whole.

(An awful lot of what's going on in Drupal 8 dev right now is based on ongoing trends in the web dev industry as a whole, which I suppose would be a good sign.)

I agree with #50 although I wonder if the word "observe" or "follow" would be better than "match"? That might be overly quibbling or not make any difference...

Sub.

sub.

Very excellent questions and discussions raised here so far and how these can fit in and work with the proposed/finalized Drupal 8 gates.

Regarding #45 "Would someone coming from another system be baffled by this, or would it seem familiar" - this is pretty well established from both a DX and UX point of view as the principle of least astonishment. It doesn't mean we need to copy from other systems, just keep to established patterns unless we have a very well defined reason for not doing so (and mechanisms to compensate for the inevitable astonishment!). We use this principle all the time on the small scale to assess if a patch/module has been built the "Drupal-way" or not - the difference here is that we are applying the same principle to the big wide world of web sites/frameworks/platforms/products/software.

I like these criteria a lot. And I agree with treating these as discussion guiders rather than strictly formulaic. For example, something might come up that answers yes to only 1 of the criteria, but a very strong yes, and that might be as compelling as something that answers a weak yes to 5 criteria.

sub

/me more listening.

Also - finally, I'm beginning to feel less like I might need to abandon Drupal.

Hooray for defining the heuristics (my my that's a tricky word to get ya head around) for evaluating these fundamental changes to Drupal.

I don't know if it's been said elsewhere but I'm still digging through all the various threads trying to catch up.

Here's why getting this right is so important.

I'm not a site builder or themer, but they are the closest Drupal roles to describe where I connect with Drupal. Mostly I work with users who are dealing with a website someone else has built for them. Sites large and small. Some users have access as User 1, some don't. I may have worked on building the website, or I may have inherited a website built by persons unknown.

Much of the debate on the platform/framework v product and making core maintainable has literally made me feel like I needed to start looking for an alternative web product for myself, my clients, and for the future of my business.

The debate itself made me feel unwelcome. It made me feel "in the way".

At DrupalCon I was privy to a conversation where someone announced that Dries had just committed the patch to remove the blog module from Core. I use that module - on a number of different websites. So... that left me wondering if I'd ever be able to upgrade those sites. Blog has been moved to contrib but I still have no idea if that means I'll ever be able to upgrade those websites.

I asked a question about migration and upgrade pathways during the core conversations that effectively got railroaded by some 'non-answer' that the migrate API would magically fix all that. Will it?

So... @Eaton - thank you for spending time unpacking all these issues, and posting with such clarity.

I'm still uneasy though. If the core developers of Drupal abandon anything that looks like a product, and no-one steps up to provide a distro or profile that actually delivers a product... where will that leave me? Or is that the point. People like me just shouldn't be interfacing with Drupal?

That's what I was wondering. So - yay for heuristics. Rather than simply amputating problem limbs without a thorough diagnosis of the disease, and possible cures. Looks like there's hope.

Much of the debate on the platform/framework v product and making core maintainable has literally made me feel like I needed to start looking for an alternative web product for myself, my clients, and for the future of my business.

@kattekrab: Well, in fact the debate is in great part about improving the organization of those different Drupal layers, to better serve all Drupal developers, builders, and users. It does not mean at all that some layers are going to disappear.

It's true that sometimes a rather dramatic language is used to catalyze change, however it's clear that Drupal is an especially and increasingly successful open-source project. The problem is maybe too much success. ;)

[edit]

At DrupalCon I was privy to a conversation where someone announced that Dries had just committed the patch to remove the blog module from Core. I use that module - on a number of different websites. So... that left me wondering if I'd ever be able to upgrade those sites. Blog has been moved to contrib but I still have no idea if that means I'll ever be able to upgrade those websites.

Yes, blog was removed from core but of course moved to contrib, now at http://drupal.org/project/blog . See also #1263208: Upgrade path for blog module removal.

If the core developers of Drupal abandon anything that looks like a product, and no-one steps up to provide a distro or profile that actually delivers a product...

It's all right, many people are taking care of the product layer, including core contributors like Eaton (see the Snowman project). See also #1260214: Choose your Drupal, Additional distribution documentation, etc.

Reviewing the useful eight or nine points of the Issue Summary, a possible #10 criteria to also take into account could be related to the following from webchick. It's a two years old quote, but equally clarifying and remarkable today:

My personal philosophy is that core should be the home of features that 80%+ sites need, and provide necessary APIs so that everything else that could possibly be needed for building everything from an IRC daemon to a Facebook clone to a personal brochure-ware site. Drupal core is not in the business of competing with PHP-Nuke and cramming every feature possible into it; in fact, just the opposite. If I am building an IRC daemon or brochure-ware site on top of Drupal, I have no use for user-swappable themes, or buddylists, or favourite lists, etc. even though those are considered critical features of my Facebook clone site. However, in each of those cases, I do want features like user authentication, permissions, localization, etc. This cross-over spot is the business of Drupal core.

Every feature that's added to core (esp. if it's not encapsulated in a switch-offable module such as per-user themes) is more code that needs to be parsed on every single page and more code that we need to maintain over time. There is a large movement in the Drupal community for a smaller core that does nothing more than the basics and adding more robust tools for packaging "Distributions" of Drupal that can be catered to specific use cases, many of which may include per-user themes as a baseline feature. I'm highly in support of efforts that enable this, and far less in support of efforts that glom on legacy features, particularly when they make little sense and make core development more difficult.

So, it's possible that later the primary or most popular download from drupal.org will be, rather than core, maybe an official Drupal distribution, edition, or bundle for site builders, or another one for users, with core and a selection of contributed modules with their own maintainers, like Views, etc. (Similar examples for Drupal 6 are Acquia Drupal, and Cocomore Drupal).

Core would be just the central framework section, that is the section maintained by core developers, and also available as one of the two or three main downloads.

A partially related issue, that could help with some aspects of this is #1036780: Drupal.org should collect stats on enabled sub-modules and core modules . Of course, the above quoted criteria is, rather than about usage stats, more about the common basis.

#1036780: Drupal.org should collect stats on enabled sub-modules and core modules should be a major factor when deciding what to remove.

Hi everyone

Going back to the good points about an administrative theme, I think these also apply to Toolbar and Overlay.

AaronMcHale

...same feature request for contrib: #1439316: Provide means for module maintainers to collect heuristics on certain settings of their modules.

Removing Criteria #4 and adding Criteria #9, as per comment 33

Bumping to major, we need some guidelines for what features get into minor releases and how.

This is a great idea.

Most of these make perfect sense to me.

I'm not sure I understand / agree with #6. If there is a more robust module in contrib, wouldn't that be an argument for removing the less robust solution from core or bringing the contrib module into core, and not an argument for keeping them separate? (Edit) For example, Drupal 7 has some basic support for translating some of the text on the site which gets along well with i18n and entity translation, but those modules are both in core now.

Is there an action being proposed? I'd be in favour of getting this list into some official documentation. That would make it more convincing if it's going to be used as a reference for issues like #1255674: [meta] Make core maintainable.

I created a policy proposal that is related #3158669: By default deprecate non-experimental modules that are used by less 5% of sites before the next major version

I think it is more actionable. This would only establish the default behavior. People could still advocate that a module not be removed even it is below the agreed upon usage threshold.

I think the criteria listed in the summary of this issue would be good reasons to advocate for a module to not be removed from core. But a case would have to made for each module.