[meta] Determine how to make Shortcut module more useful and maintainable

Shortcut's current usage stats are based on it being in Standard. #3158669: [Policy] By default deprecate non-experimental modules that are used by less 5% of sites before the next major version shows that Shortcut has less usage than RDF (another module in Standard that we have now moved to contrib).

There are definitely some cases where shortcut is useful. However, it's one of those features like QuickEdit that's just there in the UI and does not really get used by many people. There's also been a history of technical debt and critical bugs with Shortcut that we haven't been able to address.

Evaluating it against the other criteria besides usage we've agreed on for deciding whether a module should be in core:

1. Is it a foundational capability? Committers' responses to this were 7 "No", 2 "Maybe", and 1 "Yes".
2. Does it have strategic value for upcoming strategic objectives? Committers' responses were 8 "No and 2 "Maybe".
3. Is it maintainable? Most people answered "No"; only one person answered "Maybe".

We then voted on whether it should be kept in core or moved to contrib, and there were seven votes for "Remove" and one for "Keep".

So there is a lot of agreement, although not full consensus, that this module should move to contrib.

Removing a thing from core requires signoff from all the committer roles, as well as an opportunity for the subsystem maintainer to provide feedback if there is one. That would be @jibran and @tstoeckler in this case. @jibran has already responded in #2, which is an answer that makes me think this module might have a better chance in contrib.

The committer team recently reviewed our scoring exercise on all core modules. There is a reasonably strong consensus that Shortcut is neither a foundational capability nor strategically valuable to the product roadmap, so it should be removed. I am marking RTBC, but leaving the tags on to give maintainers a chance to confirm that they agree.

Myself, @catch, @quietone, and @longwave all agree on moving Shortcut to contrib.

From a framework manager point of view, I'm happy for it to be moved to contrib. I did an audit of our sites and it wasn't in use except for one site where someone had (in error I assume) added the batch progress page to the shortcuts.

Modules like admin toolbar provide and coffee provide a better experience for navigating admin menus.

Not removing the tag as giving others a chance to chime in.

+1 to removal from core, although I guess I'm one of those weird outliers that has made good use of shortcuts on sites where folks love them and use them all the time. 😂 Especially for not-full-admin type users... I've got sites with "Event manager" roles and those users live in their shortcut bar. On 1 site, there's a shortcut set for basically every authenticated user role, and as folks progress through their training / certifications, and get higher levels of site access, their shortcuts change, etc. But almost none of them are admins where full admin_toolbar makes sense...

Life permitting, I'd be willing to help with the core removal, and to potentially help co-maintain the contrib version.

Thanks everyone,
-Derek

p.s. Do we need tstoeckler as the other shortcut subsys maintainer to remove that tag? Should we ping any other framework or product managers? Can we actually mark this fixed and start the process of opening all the right issues, begin to make sure there are no shortcut tests or other tentacles leaking into other parts of core, etc?

Thanks @quietone for reaching out! That was really nice. Due to my minimal or non-existent participation in the core queue (or this one) I guess I couldn't realistlcally have complained if this went forward without my input, but I can't say there wouldn't have been some sore feelings from my side if it did. So I really do appreciate the heads-up, thanks a lot!

Some thoughts about this, in no particular order, but the tl:dr; is: yeah, no objection from my side with moving Shortcut to contrib. Removing the subsystem maintainer review tag, accordingly.

• From #3:
  

  There's also been a history of technical debt and critical bugs with Shortcut that we haven't been able to address.

  I know it's neither here nor there, but just want to point out that I strongly disagree with this assessment.

• Also from #3:
  

  Is it maintainable? Most people answered "No"; only one person answered "Maybe".

  Again, neither here nor there, but this is a really problematic statement. First of all, there's no mention who those people actually are, presumably the committer team, but yeah, please be explicit about things like that. And more importantly a blanket statement declaring something as maintainable or unmaintainable is just a very silly thing. I'm sure there was more context to that when it was actually discussed, but I don't have that context and neither does anyone else following this issue. So that (presumed) context should either have been added or this statement should have been omitted. Unsurprisingly, in this contextless form I also disagree with the assessment.

• Some context (from my surely biased point of view) for #2419387: Remove Shortcut module from core on why Shortcut is still in core and why I stepped up to maintain it back then: The menu system rewrite for D8 was a very complex thing and I think inarguably a pain for those that did it (to be clear, I was not one of those people). Although there are many reasons why it was so painful, Shortcut module and it's particular usage (or abuse) of menu links was certainly one of them. So people wanted to remove Shortcut module to reduce the maintenance burden. At that point, however, the menu system rewrite had already landed, so the maintenance cost had mostly been paid at that point, so to speak. And while it was surely not the module with the least legacy code, in my opinion it was by far not the worst offender and removing it at that point just seemed unfair. So I stepped up and together with @jibran set out to improve and fix a bunch of things to (further) reduce the maintenance cost. As @jibran already noted above most of those things never actually made it into core.
• I haven't been a de facto maintainer of Shortcut in years as my involvement with the Drupal core development community has fizzled. So even if I did object to the removal (which, to be clear, I do not) I'm not sure it would be fair for me to actually "claim a maintainer veto" (and, yes, I know that's not how it works, but even assuming it did). I have had the notion in the back of my head for a while now, that I should remove myself from MAINTAINERS.txt entirely, simply as my being listed there does not reflect reality. I will use this as an opportunity to do that now.
• On the actual technical assessment of the module: I pretty much agree with @jibran, I would put it this way: I think a theoretical, improved version of Shortcut module would be a great fit for Drupal core. In particular, if the UX for managing one's shortcuts was far more intuitive and also if there was a way for administrators to predefine sets of shortcuts for different groups of users (i.e. editors, translators, etc.) it would be a really great fit for a lot of sites, in my opinion. And yes, a modern version of the module should properly use the Entity API instead of working around it or beside it. However, that module does not exist as of now and it's not realistic to assume it will ever exist if Shortcut stays in core. So yeah, let's remove it. If that shiny better version does ever materialize, the maintainers of that can lobby for it to be brought to core if they want to, and if it doesn't or they don't, that's also fine.
• This is just a minor point, but I do think it's worth pointing out that the module landscape is also just very different from back when #2419387: Remove Shortcut module from core was brought up originally. By now, the bar for a module to be in core is just a lot higher, as evidenced by all the removals already, and that's a good thing! So even without my particular reasons for objecting to the removal back then (see above), I think it would be a much tougher case now to argue against the removal.

+1 for removing Shortcut module from Drupal core. Another argument is that it'll prevent this dreaded message when importing config from another site into a fresh install:

$ drush config:import
[...]
[error]  Drupal\Core\Config\ConfigImporterException: There were errors validating the config synchronization.
Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing. in Drupal\Core\Config\ConfigImporter->validate() (line 788 of /app/web/core/lib/Drupal/Core/Config/ConfigImporter.php).

In ConfigImportCommands.php line 324:
The import failed due to the following reasons: Entities exist of type <em class="placeholder">Shortcut link</em> and <em class="placeholder">Shortcut set</em> <em class="placeholder">Default</em>. These entities need to be deleted before importing.

See for example Problem during import configuration.

Thanks @jibran for attempting to fix it, too bad the progress stalled.

I also think this should move to contrib (although we'll need to remove it from the standard profile first).

I use toolbar module on every site, but even if shortcut module is installed, for me at least, it's just an extra 'shortcuts' link in the toolbar which I never click on. I am aware of sites I'm involved with using it - usually when there are multiple types of admin users that need to get to specific spots fairly regularly, but it will still be installable from contrib for those cases. Sites often take other approaches to things like this too, like admin/moderation dashboards or similar.

Since @larowlan has already signed off too, removing the framework manager tag.

I’m going to open the can of worms (sorry!) but I think this feature still has value in Drupal core.

From comment #10:

I think a theoretical, improved version of Shortcut module would be a great fit for Drupal core.

From comment #3:

Does it have strategic value for upcoming strategic objectives?

By the time this was filled there were no plans to renewing the main navigation(#3373292: [Plan] Administration main navigation modernization) or adding a role/persona Dashboard (#3244581: Enhance user experience with customizable dashboards). But I think those 2 initiatives would be really benefited from having a feature like this because it would help the final user. As a context, we’re trying to improve the overall UX of the admin UI (#3373303: [PLAN] Administration UX improvements) and nothing is written in stone, but the the initial hypothesis (which will be validated with user tests) is that this feature could help with user journeys and make the UI more effective and easier to navigate.

On a usability perspective I see this feature as an industry standard since a lot of users assume they will be able to customize their UI with their own most common pages. We can see it named as Shortcuts, Bookmarks, Starred or Favorites, but the same or a similar feature can be seen in a variety of software that goes from browsers to websites like Gitlab and Github to MacOS Finder.

I totally understand the burden of maintaining really old code, but if we remove Shortcuts instead of updating the existing code (and obviously finding a new maintainer/s would be required) we’ll add all the extra work and burden that requires adding a new feature, while Shortcuts already made its case years ago. Discussing it at Drupal Dev Days in Vienna with @lauriii, @xjm, @longwave and @Gábor Hojtsy, it looks like maybe there isn’t many cases where an outdated or unmaintained module has been updated (while several have been removed from core), and maybe this could be an opportunity to figure out a process for this.

For a such a modular system as core + contrib is, I think it's fundamental for the core part of the system to provide a mechanism for creating a customisable set of links to important/often used create/admin pages. Tools for navigating a Drupal application are not optional features but fundamental capabilities. I do agree that current Shortcut ux is not providing what is needed to do that well, but in the general sense, I think this capability should be provided by core.

(forgot I had attached an image, a version of that diagram is also in #3203618: New “content creation” menu proposal, with a previous ux maintainer reviewing it as "great idea, like a more opiniated shortcuts menu." :-)

Adding credits from the in-person discussion mentioned in #13.

The question is, how do we get to the Shortcut module we want from the (mostly unmaintainable) Shortcut module we currently have?

Re #19: As noted above I would appreciate if you could refrain from making such assertions; putting it in parentheses doesn't make the claim any less unfounded or vague.

I, as a (now past) maintainer do not consider the module unmaintainable and I tried to make that quite clear above already. If you disagree, that's totally fair, but then please actually make a case for your position and do not just state it as fact.

Sorry @tstoeckler if it sounded bad. Probably one of the first things we need to do is to evaluate what needs to be changed so there isn't the assumption that what's in there is not maintainable at all and we know what to focus on.

From comment #19:

The question is, how do we get to the Shortcut module we want

Maybe a good starting point would be to give visibility to this need so people know it exists. I guess it could take the form somehow of an "initiative" where a plan would need to be created. And I guess the team working on that could be the ones suggesting where to go, together with some direction of Product Managers as it happens in other initiatives. And I guess the whole process would be a way to show they can be maintainers?
Also I'm assuming this plan could have an initial research process, and part of it could be evaluating the existing code.

From comment #2:

One of the issues I run into very often as a Shortcut module maintainer it the lack of interest from the community in creating and reviewing the patches.

I guess we have to acknowledge some responsibility here as maintainers. I hope with the effort happening around the new navigation and the dashboard we can move some attention into this?

One of the issues I run into very often as a Shortcut module maintainer it the lack of interest from the community in creating and reviewing the patches.

fwiw I think this is one of the factors leading to verdicts like 'unmaintainable' - it's not that shortcut is inherently unmaintainable, it's that if you is try to work on it, you get stuck, because few people work on it. Few people work on it because (anecdotally) most people who work on Drupal core don't actively use it, even if it's installed on sites they work on - e.g. I tend to navigate via browser history or muscle memory most of the time, or clicking through the admin menu, but never shortcuts.

This is compared to say Views which very hard to work on, but which tends to have more people active on the issues (but still overall, very hard to maintain), vs something like syslog module which hardly ever gets worked on, but also doesn't do very much (so overall, easy to maintain).

Shortcut is in the middle where it has both config + content entities, references to paths (which might change under its feet) + interfaces to deal with, but not many people actively working with it.

Removing versions from the title. They can be added back if this is approved.

There is support for deprecating Shortcut and moving it to contrib. However, this still needs product manager review.

Since there is no patch here I am setting this to Active.

My comment from #13 still applies: Shortcuts is a net win for 2 active initiatives so my vote is against removing it from core. Both the new Navigation and the Dashboard are planning on using features from the Shortcuts module.

It is true that it would be great to update the code and functionality it provides, but if we remove it from core it'll be complicated to add it again.

Yeah per #25 if we have new use-cases for shortcuts in core then we shouldn't remove it. I think we should probably mark this postponed - once we're actually using it for dashboard and/or navigation changes in core we could close this as won't fix, if there's a change of direction later and shortcuts usage in core stays as the status quo, we could re-open this for discussion again.

Adding related issues from #13

Since there's consensus that the original proposal is "wontfix", rescoping this to be a meta about fixing Shortcut so it's not something we constantly wish we could remove from core.

The Ideas project is being deprecated. This issue is moved to the Drupal project. Check that the selected component is correct. Also, add the relevant tags, especially any 'needs manager review' tags.

The Shortcut Module was approved for removal in #3476880: [Policy] Move Shortcut module to contrib.

This is Postponed. The status is set according to two policies. The Remove a core extension and move it to a contributed project and the Extensions approved for removal policies.

The deprecation work is in #3569117: [meta] Tasks to deprecate the Shortcut module and the removal work in #3569121: [meta] Tasks to remove the Shortcut module.

Shortcut will be moved to a contributed project before Drupal 12.0.0 is released.