Maintainership for Documentation pages and sections

Updated issue summary

How would we handle "abandoned" documentation? In projects we have a process for abandoned projects. We also have the option for "seeking co-maintainers" and "seeking new maintainer" under maintenance status. Would documentation need something similar?

Also, I'm marking this with the d.o content strategy issue tag so we can tie it back to that work.

I doubt that anything approaching all of our thousands of documentation pages would actually have a maintainer. I also don't think we need anything as sophisticated as what's needed for projects. Just a field where people can add and remove themselves as a maintainer would probably be sufficient; if more is needed down the road it could be revisited.

With the new content strategy and IA work being done in #1133434: [META] Content Strategy for Drupal.org one of the ideas is to use organic groups to structure things. If this is the case we could potentially end up with a scenario where subsections of the handbook are individual groups, and groups can have one or more owners. Essentially, maintainers in this case.

For example, you could have a D8 theme manual, and a D8 module developers guide. Or even, documentation for a contrib project like token module.

We could then do things like:

- List the groups of documentation pages someone maintains on their profile
- Send out notifications whenever a page is added or changed in the group. g.d.o. already does notifications, and you can even opt for a nice summary version
- Show a group owner all the pages in the section they are maintaining
- Potentially control various permissions for who can edit, etc. on a per group basis

This seems like it would get us pretty close to a lot of things we're talking about here. My one concern would be granularity. Are the groups we create granular enough? Is D8 theming guide a level of granularity that's appropriate for maintainership? I think it might be. And I suppose this would at least be a step in the right direction and we can come back and try and make things more granular in the future if necessary.

The last I saw of the Content Strategy was that Projects (contrib modules, themes, distributions) on drupal.org were going to become Groups (using the OG module), and that each Project/Group would have its own documentation area. So I think that takes care of part of what is needed here -- documentation for the "Foo Bar" module or the "Baz" theme would be moved into the Group for that project, so that Projects would have the ability to maintain their own documentation.

This was one of the main points of the proposal here, so maybe that is enough.

I guess we could have the Theme Guide be a project as well, and have a group of people be the maintainers... It wouldn't be granular (like the proposal here where people could sign up to maintain a page or two), but at least we could get a few people to sign up to maintain the whole thing and presumably get notifications when anything in that group was edited. But... not really sure how that would work with our other existing books, and would that mean that we'd move all the docs on drupal.org into being Group Wiki pages? Would the general public lose the ability to add/edit pages, and would we still have the Community Documentation? Hmmm...

From what I can gather here #2481515: [META] Structure Drupal.org content around areas of user activity, the idea is that basically all top-level sections on d.o. will become a "group". In talking to @tvn at DrupalCon it sounds like you could also in theory have sub-groups within a group. So something like:

- Documentation
--- Structure Guide
--- Site Building Guide
--- Theming Guide
--- Module Development
--- Etc.

Could each be their own sub-group. Maybe even with further division if appropriate. @tvn or someone who knows more about what the plan is can probably speak better to this than I can. I also really have no idea how this affects navigation/book pages. But presumably, all existing pages would be moved to one group or another.

Permissions wise, each group would be able to control their own permissions. So presumably the default would be to mirror what the permissions are on the community documentation pages now. Though in the long run having permissions be granular at this level opens up some interesting possibilities in the future for implementing moderation/review in at least some subsections of the documentation.

Some additional info that might help define this a bit more. We would be implementing several Organic Group content types under this plan. #2481519: [META] Content Model for Drupal.org.

"Documentation" at the top level would likely be a "section". So would most of the handbooks under that section.

Also related, the documentation content type being proposed as a replacement to book pages would also have a "follow" functionality so that users could choose to get updates for changes to that node. This could also bridge the difference between maintainership of a section or project or initiative and the interest in helping keep an individual page of documentation up to date.

What remains to be completed here?

The Sign up to maintain this page button described in point a of Proposed resolution has never been implemented. Every person with the community role can edit documentation pages (except some sections), but people cannot add themselves as maintainer of documentation guides.

"sign up to maintain this page" - How would that work? Is that automatic or is there some process to follow?

Basing on the description, it is a submission button with a custom submission handler which adds the currently logged-in user to the list of people who signed up as documentation maintainers.
Since the used verb is sign up, I am not clear if that means there is a list of people who is willing to be maintainer somebody else will approve, or people who "sign up" are automatically added as maintainers. In both the cases, custom code must be written.

The conversation around has shifted a lot in the last 10 years. I would argue that just signing up, without some sort of approval process, will result in spam of some sort. Much of this conversation and the original issue was before we implemented all of the user confirmation workflow to reduce spam.

There might be a path to allowing confirmed project maintainers to sign up automatically or perhaps better would be for a documentation maintainer request to be sent to the project maintainer for approval.

I doubt there is bandwidth for the development of either, but @hestenet might have some ideas.

Let's consider this issue closed.