[policy, no patch] Decide whether to enable Announcements Feed for 7.x by default

If I read the docs correctly, I think we should know more about the status of the D10 Announcements feed module by Drupal 10.2 alpha deadline, which should be in the week of October 30, 2023 (see: https://www.drupal.org/about/core/policies/core-change-policies/experime... → ). Because this date is before the next planned D7 release (December), we will be able to react to this decision, if the module was promoted to stable (and potentially included as in one of the profiles as enabled).

Of course, we can decide on our own course of action in the meantime (this might just help us).

Added a proposal from the DA perspective to the issue summary.

I would like to know the counter-arguments against enabling by default, so that I can try to brainstorm ways to address them. The value of enabling by default is huge for the D7 EOL effort.

Thanks @hestenet for adding the DA perspective!

I am adding some other points to consider here:

1. The module is in Drupal 10.1, starting in 10.1.0-alpha1, for approx. 6 months, but no new content has been added since. I think we should "revive" that feed sooner the better, because if we add it to the D7 (as enabled by default) and there will be 4 posts for the next year, I think it woould not look good.

2. Is it possible to get an approximate number of installs for the D10 Announcements feed module? Seems like that something similar was done in the past for core modules: 🌱 By default deprecate non-experimental modules that are used by less 5% of sites before the next major version Active . Just for an illustration, how many sites activated/"tested" this in D10.1.

3. Per comment #3 - the 10.2 alpha is close, but so far it does not seems like to me that there is any momentum in changing the stability of the experimental module, or in adding it to one of the installation profiles / enabling by default. If there will not be any change, this decision for D7 will be tougher (also with regard to the numbers from point 2). Tracking the progress here: 📌 Mark Announcements Feed as stable Fixed

That said, my personal opinion is, that in case there is be a low number of installs in D10 so far (point 2) and there will be no movement according to the point 3, then I think we should consider a two step process:

• Try to finish the reviews/required sign-offs and commit it in the current state (without enabling the module by default) until December, so it does make it into 7.99. This will allow us to collect some additional feedback from the D10 and also D7 sites, which will enable the module.
• (in case of consensus) Prepare and add the enable by default functionality to the next release - June 2024 (or possibly, we can try to make an additional release after 3 monts in March 2024 just for this, like it was done in the past for the PHP compatibility issues).

I see this as more cautious approach, but understand that it is not ideal for the DA. But as I said, it also depends on points 2 and 3.

1. Initially we were intending to be very cautious and restrained about the total amount of content being published to that feed - but I agree we could step it up a little. I think somewhere between 6-12 posts a year is probably a reasonable target. It is slightly chicken and egg since it would be a bit odd to post D7 specific items to the feed before it's availiable in D7, but nevertheless, I agree we should work out more content.
2. I am not 100% sure about how easy it is to query for active use of the core module yet. That's a good question I'll have to look into further.
3. I'll need to regroup with some of the D10 maintainers to see what they would like to see in order to reach stability. I'll begin reaching out on that front.

• I think those outlined plans are reasonable - although as I see that as motivation to try and make as much progress on 2 and 3 as we can, so we have data to back up the more accelerated versions of the plan.

Announcements feed was including in standard profile/enabled by default in Drupal 10.2!

Hoping that will help us build confidence towards doing this in D7. The longer time horizon we have to communicate with D7 site owners before EOL the more resources we can provide to them and the better we can shepherd them into a good experience with the EOL process.

Something similar happened in the Commerce module recently, where they decided to enable similar functionality by default for all existing sites: 📌 Document the communication to 3rd party sites Active ( https://www.drupal.org/project/commerce/releases/8.x-2.37 → ). I mention it here just for info and we can probably learn some lessons from it.

I think we would need a very good communication/explanation and we also discussed a possibility to opt-out of this behavior via a new config option in settings.php. So that sites that would not want to enable the module automatically would be able to set this and it will cause the installation process to be skipped.

possibility to opt-out of this behavior via a new config option in settings.php

Do you mean a variable that would be checked in the install hook and then will make the module NOT to be installed? This would only prevent the installation if the change is made BEFORE running site updates.

Or a variable that would prevent the module from being installed at any point when the value is set.

Yes, the variable that would only prevent the installation, if the change is made BEFORE running site updates. There can be sites, which for various reason do not want this enabled by default (maybe some company policies, etc..). The release notes could mention this and each site which will set the variable will not have the module enabled when updating the Drupal version. It would have no effect when installing/uninstalling via UI.

Cool.

I guess we can use the hook_requirements to check for that variable. I'm not sure how an update.php or drush updb will behave when an error is defined in the hook. We just want to skip the installation, but it's not an error.

Do you have any better suggestions for implementation? (maybe we can discuss that part on the other issue, or maybe discuss here and just comment on the other issue with the selected suggestion).

I think that if we agree on a decision here, then we will need to create a separate issue for implementation, as the main issue is just about adding a module itself. And it will be more transparent to have the auto-enable process in a separate issue.

I guess we can use the hook_requirements to check for that variable. I'm not sure how an update.php or drush updb will behave when an error is defined in the hook. We just want to skip the installation, but it's not an error.

Could not we just do the check in the update hook? If we add a condition around module_enable() directly there?

Yeah, sure thing! A separate issue just for that makes sense.

Happy with your suggestion too, especially if the other issue is already merged and the module is already present in the codebase.

fwiw, I'd advocate strongly in favor of automatic installation. (Naturally, as pointed out above. ; )

Here's why: I think the need for the Drupal project, and in cases like ours, maintainers of significant ecosystems, to communicate proactively with end users outside of module update hooks outweighs the potential concerns. Install any other piece of software, including many an open source project, and you're going to get proactive project messaging. (Reference a WordPress installation as one example; we referenced WooCommerce during our design phase.)

Building this into our software does not violate any social contract that I'm aware of, especially given the long history of RSS feeds in general. (In fact, if I had any gripe with the Announcements module, it's that it doesn't do more, e.g., to show the messaging in-site, allow me to dismiss messages I've read, etc.)

One concern raised in our issue that I think is worth considering is the idea of a man-in-the-middle attack getting bad information into the feed. I'm not sure what to say or do about that ... though I tend to think if drupal.org itself were compromised, we'd have much bigger issues to worry about than whether or not some graffiti made it into the announcements feed. 🤷‍♂️

The other concern raised was the potential for IP logging when the feed is consumed. I think this can be handled with a privacy policy. I tend to think IPs are generally of limited utility, given most are going to resolve to an AWS block, not a specific domain or organization. But it is possible if they were logged and those logs were disclosed that targeted attacks could be attempted against those machines somehow. Very theoretical. A good countermeasure is just don't log those IPs.

Thinking about the fractional increase in risk, too, most of these sites are already reporting in to d.o for update notifications, so seeing a machine fetch a feed is no different. (In fact, it would be more useful to attempt to track referer URIs from people who actually click on links in the feed, again, an action that could be disclosed and or prevented by a privacy policy.)

If we do need a compromise position, though, we could have an update hook choose whether or not to install the Announcements module based on whether or not the Update Status module is enabled. At that point, we're at least not increasing a site's exposure to d.o. For the sites where it isn't installed, we can put a nag either in an update hook or in the back-end. (i.e., we could add a dismissible message across admin routes strongly suggesting the module be enabled and / or a permanent message atop the status report page.)

fwiw, I'm not naive re: the fact that some of our users prefer maximum control over things like these; I just think they're in the minority position of being both vocal and highly active in Drupal already (meaning, they're the least likely to need the messaging, which is why they'd disable it in the first place). I would just recommend a solution that serves for the majority use case and makes the uninstall step clear for people who don't want the module.

Oh, and for what it's worth, we do use the pattern of a variable set in settings.php bypassing update hooks. Typically this involves field changes to entity types we expect may have a tremendous number of records in the database, allowing a site owner to skip the change in update.php and complete it some other way. It's not a bad solution, though I do expect the same sites that would disable it would tend to have Update Status disabled, too.

The D7 maintainer team have discussed this a bit.

Another semi-relevant example that came up is the case of JetBrains enabling their AI assistant by default, and some users being quite vocally aggravated about not being able to cleanly disable / remove the feature. There are threads about this on reddit / hacker news.

@fabianx and I both like the suggestion of enabling the module by default, but having an opt-out variable documented in the release notes.

We can canvass a few other opinions, but I think that's pretty close to a consensus on the approach.

@fabianx and I both like the suggestion of enabling the module by default,
but having an opt-out variable documented in the release notes.

We can canvass a few other opinions, but I think that's pretty close to a
consensus on the approach.

+1 - that works for me.

Just to re-iterate that point:

- Automatic enabling is good for 80% of sites, which do not care either way
- Being able to opt-out of automatic enabling is important for sites, who want to control the process of what gets installed when

It is important to not just take the stance that "you can disable it afterwards again", because of privacy concerns when the feed is consumed, which can happen when e.g. cron runs in between module enabling and disabling.

Thanks everyone! I think that we have found a solution which everyone agrees with (updated the IS), so I think we can close this. The implementation is being done in the separate issue here: 📌 Enable Announcements Feed by default, but allow opt-out Needs review

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