[Policy] Remove tour module from core

Is this happens I may want to volunteer to help look after the contrib module. Maybe work with the maintainer of tour_ui and consolidate the 2

Updating title to show this is a policy discussion

+1 on removing this from core. It's a great feature, but I assume a big part of Drupal installations don't use it. So I'd say it'll have more chances to improve on contrib.

There are 50 open issues for the Tour module. I tried to get some movement on them after presenting on the module at Drupalcon Global, but haven't made much progress.

What would the steps be to remove it from core?

What would the steps be to remove it from core?

We became quite the experts in deprecating core modules/themes during the 9.5.x/10.0.x development cycle.

We even have a nicely documented procedure, which starts here: https://www.drupal.org/about/core/policies/core-change-policies/drupal-d...

Spoke to larowlan about this on slack. But if we move this out would see if the tour ui maintainers would like to consolidate if they are around.

And maybe it would get more traction as a contrib module

I used Tour extensively on several client sites and they were pleased with the results. There was nothing about my use that particularly benefitted from it being a core module -- if anything it was a disadvantage as there were several improvements-in-progress I would have liked in Tour that would have easily made it into a contrib module, but could not penetrate the core gates. I also used it solely for institution specific information, not as a tool to teach Drupal.

I also spent many paid Acquia hours doing the Joyride -> Shepherd change and I think I did a decent job but I couldn't shake the feeling it was time poorly spent.

Finally, I think the time is better spend working to make the UI's more intuitive. Nobody reads the docs anymore. I bet only 10% even got to this sentence.

In conclusion, I like Tour, I've used it for cool stuff. I also don't think it needs to be in core and as the person who shouldered much of the recent Tour maintenance burden - I could have dedicated that time to stuff that results in better future benefits for Drupal.

As a core product manager, I agree with @bnjmnm, unfortunately Tour in core did not quite work out, and it would be much better to improve the UIs themselves, especially since Tours are not being created (or maintained), so the benefit we hoped to get by adding it in core did not work out.

From: https://www.drupal.org/about/core/policies/core-change-policies/drupal-d...

1. Discuss module removal
1. Open an issue against the Drupal core ideas providing justification for removing the module.
2. Seek approval from product managers.
3. There must be someone willing to maintain the module or theme in contrib (at least to co-ordinate security releases while it is still in a supported core version), and a contributed project should be made with the same namespace
2. When the above issue is marked Fixed and the decision is to remove the module from core, then follow the steps in Remove a core module and move it to a contributed project to complete the process.

So it sounds like 1.1 and 1.2 are complete based on comment #11.

I reached out to the maintainers of the Tour UI module in https://www.drupal.org/project/tour_ui/issues/3326308 to see if they have any interest to maintain.

FWIW: https://www.drupal.org/project/tour is still available as new home for the Contrib Tour module

Moving this to RTBC per #11

@smustgrave Do you want to create the module in the contrib space?

I can definitely get to that by tomorrow if that's cool.

Thanks @thejimbirch.

@smustgrave I think you've done the dance before. IMHO you should claim the contrib module URL, but not (yet) do the git-subtree-split magic, until we moved all the tour related tests into the module itself? After that the split can be done and will be "self-contained"

So what's the procedure here?

We deprecate the module from core to be removed in D11.
Do we have to wait for D11 before moving issues over to contrib? (I got a number in review that probably will have better luck there).

I somewhat was there for rdf but that ball was rolling already when I volunteered to look after it.

We deprecate the module from core to be removed in D11.
Do we have to wait for D11 before moving issues over to contrib? (I got a number in review that probably will have better luck there).

For once, we do have decent documentation on what-to-do-when (Big thanks to @quietone!): https://www.drupal.org/about/core/policies/core-change-policies/module-o...

I'll do the admin for creating META issues shortly, but to answer your question: Looks like the moving of issues has to happen after the module is actually removed from Core, so that would indeed be D11.

I somewhat was there for rdf but that ball was rolling already when I volunteered to look after it.

Ah, I thought you were in from the beginning. Anyway, I think if we follow the excellent documentation and admin us through all META and child issues, we'll get it right the first time :)

We should wait until fairly late in the process to do the subtree split to contrib - we had a lot of problems with divergence between the contrib and core versions of modules between say 9.2 and 9.5 for modules that were moved to contrib earlier like Aggregator.

The first thing as Spokje says is to open issues against core to move tours + tests into tour module itself so that everything is self-contained in the module.

There may also be issues like removing it from the standard and/or Umami install profiles, styling in themes, upgrade path test database dumps etc.

Went ahead and got the URL https://www.drupal.org/project/tour

I think this would be an opportunity to merge Tour UI with Tour ... I have almost abandoned Tour UI :-/

See also #3326308-2: Deprecate Tour UI

100% would like to fold in Tour UI with tour.

There are number of tour issues in review or close but probably won't land in core. Should they stick around though till Drupal 11?

Know it was mentioned maintaining both core and contrib was difficult.

So, looking at the Aggregator module, I believe we need the following:

1. [Meta] Tasks to deprecate the Tour module in Drupal core (D10)
2. [Meta] Tasks to remove the Tour module in Drupal core (D11)

Is that correct?

@thejimbirch yes that sounds correct.

Note that in terms of doing this in practice, we should do all the pre-removal steps for tour (like moving any tours in other modules to tour, ensuring tests pass with tour removed), but for the creation of a tour contrib module, deprecation from Drupal 10, and removal from Drupal 11, we'll probably want to explicitly schedule those for a specific, later, minor release of Drupal 10. This is because we had a lot of issues maintaining the contrib subtree splits from core for modules like aggregator and quickedit, so keeping that window of time relatively short should hopefully reduce the overall work. Everything else can and should be done asap though.

Can get started moving all tour config and tests under the tour module if that helps.

The deprecation policy include the steps for a Module or theme removal process. The work that can be done before the subtree split are in this section.

So if no one else has made the tickets can give it a shot.

Should we postpone tour tickets while we decouple it from core? Currently there a few in review that aren’t being looked at. So not sure what to do with them.

Removing a module from core requires the signoff of the subsystem maintainer when there is one, as well as all the committer roles.

The committer team recently reviewed our scoring exercise on all core modules, and there was not clear consensus to remove Tour, so it needs to be discussed further (both by the committers, and with input from the community).

Since Tour is a usability feature, I think we would also need Usability signoff on removing it.

My personal perspective is that we need to write more Tours, and enable Tour as part of Standard.

Please don't start tasks to remove this module yet as it does not have signoff or consensus.

Do think if tour remains in core we would have to look into bringing in Tour UI as currently the manual creations of tour config is tedious, which may be why it never took off.

From a module maintainer's perspective, I agree with larowlan.

I also don't want to step on any toes or process outlined by xjm above.

I really hope this is a fork in the road and Tour gets to have a new life in contrib and benefit many.

The module had some very lofty goals and I appreciate every single community member who has worked on it.

I've posted in the #ux channel of Drupal Slack requesting a review.

https://drupal.slack.com/archives/C1AFW2ZPD/p1675258116044409

Should we go ahead and start postponing tickets on this?

Example #2044407: Write tour integration for shortcuts page

If this got merged we would just have more to unravel later.

We shouldn't postpone tour issues until this is RTBC.

However, we can postpone that one, because #3311180: [meta] Determine how to make Shortcut module more useful and maintainable is RTBC.

Thanks, @xjm, for keeping the process on point. Given that the product owner, 1 framework manager, and 1 release manager had all voiced support already, it did look like a done deal. But thanks for the transparency about the full team not yet being in agreement, and for helping everyone understand the (sometimes confusing) world of Drupal governance.

+10 to this from @bnjmnm in #10:

Finally, I think the time is better spend working to make the UI's more intuitive. Nobody reads the docs anymore. I bet only 10% even got to this sentence.

+1 to removal.

+100 to all of #27 from @catch. We suffered a lot by doing the subtree split too early for QuickEdit. 😬 As soon as this is decided and we proceed, we should consolidate tour inside itself, and open issues where we *try* to both deprecate it and remove it, make sure tests work, etc. But we should wait on everything else until "the last possible moment." 😅

No idea what my life will be like when/if this is all happening, but I'm also willing to help @smustgrave navigate these treacherous deprecation/removal waters, and possibly to help maintain contrib tour.

Thanks everyone!
-Derek

Removing Needs usability review after our discussion with @xjm, @lauriii and @smustgrave at DrupalCon Pittsburgh. If it goes to contrib it might have more chances to be maintained and get updates, and since we don't have that many tours in core right now it won't be a UX issue.

I think I should have removed the "Needs further discussion" tag too because there's a general agreement on moving forward with this. Since @xjm and @catch already agreed, and Product Managers too, I'll leave the RTBC and removing the "Needs release manager review" to some of the Release managers that haven't commented yet.

+1 to removal. It seemed like a good idea, but the execution has failed; there seems to be no interest in adding tours or improving existing tours for core itself, but we still have the maintenance burden; we already did the migration to shepherd.js and now it needs a major version update.

This can still live on in contrib for sites that need it - I have a customer site that provides a tour for onboarding, which seems to work well there, but in core alone I agree that we should spend time directly improving UI/UX instead.

And want to add when it gets to to contrib idea is it breathe new life into it. Merge in tour ui for example

FWIW https://www.drupal.org/project/tour_ui seeks a new maintainer

We recently used Tour to great success in onboarding new users to the American Bookseller's Association bookseller platform. However, the value was in that the tours were really application specific, and not generalized Drupal admin UI Tours.

However, that's a single site out of everything we've done with modern Drupal. I think it's safe to say that most Drupal sites aren't used as SaaS platforms. So, +1 from me to moving this to contrib.

For the record, I agree with #43 and support moving Tour to contrib.

Saving credits.

Thanks everyone for expressing your opinions and to xjm for saving credit.

We have agreement here and sign-off from all the different managers, this can be closed now. The actual work will happen in the core issue queue.

Also was made co maintainer of tour ui. So will be getting that ready to be merged into tour when we move it!