[Policy] Move book to contrib in Drupal 11

I am a Drupal core product manager and I support this. I don't believe book module has a contrib ecosystem either (in other words it is not a platform that ecosystem modules generally build on). The final criteria is maintenance. It does have a maintainer @pwolanin, so he would be important to get a signoff from. Swapping the tag for that.

The module could change faster in contrib if there's someone willing to maintain it

Just wanted to chime in as a user of book module. We use it on several sites and are planning to continue using it newer sites in future. Book offers a very unique capability, which is simply not available in contrib thus far. It is good for creating documentation and help pages on a website.

I recognize the need to keeping a lean(er) core, so not complaining, but thought to add a user voice to this thread and must say that it has been nice for it to be a part of core thus far.

@toamit thanks for mention! For documentation purposes there experimental help topics module in core and https://www.drupal.org/sandbox/jhodgdon/2369943 configurable help module

@toamit: as the issue title and description says, the module would be moved to contrib, so it will be available from there. If there is interest in keeping it up to date, people will be able to pick it up from there.

@andypost and @gabor-hojtsy thanks, will keep a lookout for updates and changes to the book module and the help-topics module and its (hopefully) emerging ecosystem.

@toamit I will also chime in that the book module is very useful. We use in on several sites and will continue to do so as it moves to a contrib module. I am hopeful that a maintainer will step up.

Moving it to a contrib module may make it even better as community requests for features, many that exist, may get merged in.

I love the book module.

Terminology nit that might be relevant here...

Many developers, when we see the term 'deprecated', we associate it with 'avoid using this', which doesn't seem to be the case here, where the main idea is probably more along the lines of 'lets shift the maintenance of this code from core into contrib'.

Maybe we could title this issue (and possibly other similar ones) accordingly to better reflect that?

I second what marcoscano said about avoiding using the word "deprecated" with the book module. I'm not sure how much usage statistics there are for the module, but from my perspective there are a lot of government agencies that leverage it for various purposes (e.g. documentation, micro pages, guides, etc.).

I think there is a contrib ecosystem for the book module, with some great ideas about directions it can be taken:

https://www.drupal.org/project/drupal/issues/3173808
https://www.drupal.org/project/entity_hierarchy/issues/2862096
https://www.drupal.org/project/ideas/issues/1261130

Book module has great potential because it simplifies page creation in that each node has a book "menu" item that is automatically created and is a one-for-one representation of the site structure itself. The node and the menu item are coupled. There's no fiddling with menu configurations, path aliases, permissions, etc. The menu link, site structure, path aliases, and even permissions (with contrib modules added) happens at the point of node creation.

I'd hate to see it just get "deprecated". I would of course love to see it get removed from core, like the blog module did, and into the contrib marketplace so that it can grow instead of being treated slightly like an afterthought.

I'd hate to see it just get "deprecated". I would of course love to see it get removed from core, like the blog module did,

That's what this issue is suggesting, but once we have the contrib version, we have to 'deprecate' the core version to tell people they need to switch.

deprecate
verb

1. express disapproval of.

In the IT world, deprecate also carries the meaning that, although it is available or allowed, it is not recommended or that it has its failings and should be avoided.

Deprecate is not the right word here. "Retire" is though.

But that's the point, once it's in contrib the core version is not recommended and should be avoided.

Sorry, I don't want to drag this conversation out but...why would you need to avoid something that is retired?

It gets retired from core (and hopefully moves to contrib) and so therefor there isn't anything to avoid. Unless you're saying that users should avoid the contrib version?

Maybe a better title might be:

[Policy] Remove book module [from core] and move it to contrib in Drupal 10

@aseabrook: That would be another issue. First we need to tell people, we are removing the module in a current Drupal major version (currently 9), then we need to create a copy of the module in contrib, then we need to remove the module in the future major version of Drupal core (Drupal 10). These are the three large scale steps that then involve a lot more intermediate steps. For example, for forum module, telling people it will be removed would happen in #1898812: [policy] Deprecate forum module for removal in Drupal 11, while the actual removal would happen in #3199419: Move forum module to contrib. These two steps happen in entirely different major versions of Drupal core, so we handle them as separate related issues.

I'd be willing to co-maintain the contrib version w/ @pwolanin if this moves forward and he's interested.

Overall, I'd be 10% sad this is leaving core, and 90% in agreement that's exactly what needs to happen. So +1. 😉

Thanks,
-Derek

Since Drupal 10.0.0-beta1 and 9.5.0-beta1 are right around the corner, the Book module would need to be removed in Drupal 11 (not Drupal 10), correct?

@aseabrook, "Deprecate" refers to marking the code as something that will change in the next major version under our continuous upgrade path. It does not mean "denigrate" or "disparage" or "depreciate". There is a key in the info.yml file in the codebase that will be set to deprecated once the required tasks are done.

I'm fine with changing the title here because it's a policy issue, but the child issues will still mention deprecation in D10, because it's a part of the process we need to complete.

@xjm Thanks for clarifying and for changing the title, though I don't think it was necessary. I don't really agree with our usage of the word deprecate in this instance but I think @Gábor Hojtsy explained it well and showed there is already precedence with its usage, so I can't really argue with that.

I wanted to second @dww and say that I'd also like to contribute/co-co-maintain(?) the contrib book module. I don't really have a history of maintaining contributed modules though so I'm not really sure how that process works or if I even qualify.

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 is @pwolanin in this case. I spoke with @pwolanin about this previously was something along the lines of "But what about hierarchical things?" and "Meh, okay". It would be good for him to give his own answer here, though. :)

The committer team recently reviewed our scoring exercise on all core modules. There is a reasonably strong consensus that Book 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 committers a chance to confirm that they agree.

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

From a framework manager point of view, I'm happy for it to be moved to contrib. There are contrib solutions like entity hierarchy (disclaimer, I'm a maintainer) that have support for other entity-types, multiple hierarchies and drafts.

Moving book to contrib will hopefully unlock velocity.

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

I concur with larowlan that moving this module to contrib is a reasonable step. The Drupal 8 port (which I had a large hand in) is pretty crap and the name of the module doesn't convey what it's about or its capabilities.

Is having structured/hierarchical content really that rare a use case? Maybe it's more for docs and organizations? I do feel like Drupal core should ship with some (maybe lighter weight) capability to do this or we need to have the contrib solutions be very solid and obvious.

Menus already allow for hierarchical organization though (just lack the next/previous pagers).

I am removing the 'Needs subsystem maintainer review' tag because pwolanin (listed in MAINTAINERS.txt as the maintainer of the book module) agrees with moving Book to contrib.

Sad to see this go because along with taxonomy module it was one of the two features that got me involved in Drupal in the first place.

However, I use taxonomy on 99.9% of sites I'm involved with, and book module on exactly one site that was first installed in 2005 (exactly two sites if you include Drupal.org, which is a bit older than 2005), so it makes sense for it to live in contrib and/or eventually for there to be a migration script to a more generic solution like entity hierarchy. Removing the framework manager tag since @larowlan already signed off too.

No objections to remove it from core and hopefully have it prosper in contrib. As Gábor points out, an important part of what it does is already achievable with core menus. What Book adds to that in management and outlining have a very clunky UI that has received very little attention over the years.

I wanted to think that paging through a hand-picked selection of things (entity queue?) is in itself not an uncommon use case. There's even a Paging category for contributed modules, but a quick look at usage numbers there shows numbers from 3000+ installs then tapering of quickly and mostly for older versions of core.

Two product managers @Gábor Hojtsy and @yoroy agree to the removal of Book. Both @xjm and I agree that the 'Needs product manager review' tag can be removed.

Thanks to everyone for commenting! This now has approval, and sign off from the various managers. I am marking this fixed.