[policy, no patch] Decide if and how to remove experimental modules from core

In https://www.drupal.org/core/experimental, we document that experimental modules may be removed from core instead of becoming stable core modules.

We've also discussed timeboxing most experimental modules to two minor releases (with some longer windows depending on the specific case), and setting this expectation as part of adding the experimental module to core. This module was the first experimental module, so we didn't have that expectation yet at the time, but since little progress has been made on the followups in nearly a year, I think it makes sense to target the removal of this module for 8.2.x if it is not fixed.

I would suggest moving the module into contrib as a pre-release version if it is not significantly improved before 8.2.0-beta1.

repost from 2702545#26

Inline Form Errors breaks all the forms on your site.

is an overstatement. IMO, at this point the 'worst breaks' reported are

• https://www.drupal.org/node/2509268 -- which basically is more due to a poor a poor validation check on mutliple 'checkbox' elements (where as if they were checkboxes it would result in a clean single error.).
• https://www.drupal.org/node/2346773 - details related 'openness'

#2457373: is more of a nice to have, rather than any kind of breaker.

Migrate UI has a form, if that form has bugs in it, it only affects migrate UI.

The two bugs you mentioned affect any form with those kinds of elements - which is plenty of core forms to start with, even if it's not 'all forms'.

So the implications of breakage (however defined) are more severe for this module, which affects every form, vs. one that adds a standalone UI.

of course, only a theoretical example. [although as i look at this module it's not setting form_errors but is basically using drupal_set_message() on it's /upgrade page alone.] Another example of odd form development.

the only other standing 'break' ife truly introduces to the Form System is for Detail Elements (and realistically for Vertical Tabs, which has it's own general UX/a11y concerns) aren't actual breaks of IFE, just poor UX..

The breaks (ie: module uninstall page) is more due poor field choices and validation routines. not at the fault of IFE's message return.

This field/validation balancing is exactly the same with Handle error fields without a message the form and validation and message processing need changes, not IFE).
also to note: issue isn't actually 'because of IFE":

• IFE OFF
• IFE ON

Certainly, anyone building a From will need to be aware of these types of nuances working with form. that's just simply true. If IFE was full core (always on) people would just have to deal with their issues, as they should (:

We all should be well aware that this tool is a great step forward for both drupal's general UX and accessibility. Removing it is a shame. Drupal not committing resources to completing these experimental modules is also a shame.

I don't think IFE is fixable. Issues like #2509268: Inline errors repeated on child elements in module uninstall form are proof of that. We tried to discuss that issue and related ones in Barcelona, and got nowhere. Moving the module to "experimental" was just kicking the ball down the road.

again, that is a poor choice to use a 'checkbox' instead of 'checkboxes' and a dumb validation triggering error on then those items as a nested group

see: http://cgit.drupalcode.org/drupal/tree/core/modules/system/src/Form/Modu...

• line 123-131
• line 170

that issue is poorly titled.

Let me also phrase it this way:
As a businessmen selling Drupal as a product base, IFE as a key point for UX/a11y concerns. It's an easy Sell Feature, one that meets WTAG/503 requirements. Drupal should be committed to ensuring this ability through its framework permanently.

@SKAUGHT, Drupal is committed to accessibility. It is one of our core gates. Accessibility issues are considered bugs, and we furthermore took a risk on this feature by adding it to core with outstanding issues precisely because of the intended usability and accessibility benefit.

Unfortunately, that risk has not paid off in this case. The module is not of sufficient stability to be included in Drupal core at present. It has not thrived in core. If the needed followups are not completed within the next 4 months, then we need to consider an alternative course for this module.

Even if removed from core, it would still be available in contrib.

Edit:

Drupal not commuting resources to completing these experimental modules is also a shame

There is no single "Drupal" that is a pile of resources. It is an open source project. There are only individuals and companies contributing to Drupal. If you need this feature, continue the work you've already been doing to stabilize it, and help others to as well. We still have time to fix it, and even in contrib it would need fixes. Your efforts here are helpful and important!

I agree with SKAUGHT and I'm willing to pledge that I'll work a couple of days dedicated only to this during http://milan2016.drupaldays.org

@dmsmidt, I think that's a great idea!

So far we haven't reached the stage of removing any of the experimental modules from core.

Since we already have #2504847: [meta] Roadmap for stabilizing Inline Form Errors module (IFE), couldn't this issue be about the policy for removing experimental modules in general, rather than specifically inline_form_errors? The handbook page on experimental modules doesn't address describe removal yet.

Based on the current issue title/summary...

If: Yes. Experimental modules are one of the best tools we have at our disposal to allow for rapid, iterative development in core, so ideally we want to add them as frequently as we need to. If there's a concern that sloppy code might stay in core forever, we'll be less inclined to do so.

How: Ideally, the conditions for committing an initial experimental module to core would be:

a) a meta issue similar to #2504847: [meta] Roadmap for stabilizing Inline Form Errors module (IFE) which outlines the remaining work required to get the module to a stable state (ideally the issues would be tied to alpha -> beta -> rc transitions rather than priority, but that's a fairly minor quibble),
b) a timeframe within which that work must happen, which defaults to two point releases (so if something's committed in 8.0.x, it would need to be stable by 8.2.0, if it's committed in 8.2.x, it'd need to be stable by 8.4.0, etc.). Exceptions to this default can be granted by core committers on a case-by-case basis, in the event of a particularly critical piece of functionality (such as Migrate)
c) an "owner" for the project in MAINTAINERS.txt. Upon exiting from core, a contrib module would be created with the same name, under that person's handle. At this point, anyone can contribute to it the same as any other module, including applying for co-maintainer privileges using the standard practice.

Since that functionality existed in core at one point, that means that we wanted it in core initially. That means that if someone does the requisite work to make the module stable in contrib, then we should make it a relatively painless process to get it back into core again.

Oh, looks like this +/- a few other things are already documented at https://www.drupal.org/core/experimental#requirements.

So... fixed?

I'm fine with the two point releases approach for experimental modules, but I do think this should be more of a guideline than a hard/fast rule.

If we aren't able to take one of the most complex pieces of Drupal (FAPI) and make it meet all the requirements for WCAG 2.0 AA (our stated goal since Drupal 7) that's a pretty big deal for the many institutions who have come to Drupal for it's accessibility advantages.

I also do think that we really need to start this only from when there is agreement on this time-frame. Seems a bit silly to go back historically and inform the experimental modules that are already in Core that they have only two point releases to finish this off. There was no exit plan before this, and having one really changes the pressure on getting these things fixed.

Hopefully Workbench Moderation gets brought into Core as an experimental module in 8.2. At that point it will know that it has till 8.4 to address outstanding issues before it is brought out again. It's a feature we'd all like to see in Core, but ultimately it isn't going to break any of our existing organizational commitments if it doesn't get in.

Drupal as an open source project has no organizational commitments. Individual contributors may have organizational commitments through their professional services businesses, but whether this important accessibility feature lives in core or contrib, the code still exists to be used by organizations that need it. And experimental modules that were "demoted" to contrib could always move back into core once they're ready (and arguably have a 'fast-track' since they were there once before).

I think the argument for some sort of "grandfather" clause would be a lot stronger here if there had been any significant follow-up work on the Inline Form Errors module to address some of the major issues that came out of the first commit, but to my knowledge there has not been; it's effectively unmaintained and abandoned, so if it were moved to contrib in 8.2 that would just be clearly communicating its status relative to core support.

That said, I don't feel strongly enough about it that if there was a counter-proposal to extend the deadline to 8.3, that would be fine with me. I more would love to see the people who are making money (or saving money) from this feature to funnel some of that into finishing it up, personally.

it's effectively unmaintained and abandoned

Abandoned sounds a bit harsh, there are still a couple of people who try to keep it in. It's true that it may not be significant enough, but that's just a case of commitment. I don't think it's really hard to finish it if some smart people sit down and take on the open issues. In the basis it's functional, but some eccentric field widgets and forms are problematic. What I fear is that if this goes to contrib, those particular widgets and forms will be harder to fix. Because they reside in different parts of core and not in the IFE module, it would mean implementing a bunch of alter hooks.

What I felt at the DevDaysMilan by the way is that known contributors and (some) core contributors gave up on IFE, which is a pity. WCAG 2.0 AA or not, IFE is just a killer feature for everyone who submits forms.

Recently worked on issues (less than a week ago):

• #2729663: Fragment link pointing to <textarea> should be redirected to CKEditor instance when CKEditor replaced that textarea,
• #2455933: Error highlighting and reporting problems for the current password on the user profile form,
• #2754977: Enhance formErrorHandler to include children errors on RenderElements,
• #2346773: Details form element should open when there are errors on child elements,
• #2560467: Inline Errors not shown for container elements,
• #2509268: Inline errors repeated on child elements in module uninstall form

I more would love to see the people who are making money (or saving money) from this feature to funnel some of that into finishing it up, personally.

A big plus one!

We did decide to "grandfather" Inline Form Errors into a longer allowed experimental plan since the expectations had not yet been set clearly as of 8.0.0. The only other experimental modules as of 8.0.0, Migrate and Migrate Drupal, are exempt from the policy.

As I mentioned on #2504847: [meta] Roadmap for stabilizing Inline Form Errors module (IFE), if an experimental module is removed from core on the basis of an incomplete roadmap, it is still eligible to be added back once the issues are addressed. (If it is removed from core for another reason, such as being obsolete, that won't necessarily apply.)

I've updated #2504847: [meta] Roadmap for stabilizing Inline Form Errors module (IFE) with the decision on IFE specifically. The general policy has agreement from the committer team, UX maintainers, etc. and the expectation of a plan and timeframe for stability has been set at commit time for all experimental modules set in 8.1.x and 8.2.x, and is documented on https://www.drupal.org/core/experimental, so this policy can be considered RTBC.