Add support for the MAINTENANCE_MANIFESTO.md

https://www.lullabot.com/articles/healthy-open-source-maintenance goes to a 404 page.

GitLab, and I believe GitHub too, has some amount of CONTRIBUTING.md integration, which may be somewhat redundant with this file?

Drupal.org gives project maintainers the ability to add issue submission guidelines, which appear above the new issue form. This could overlap with that functionality too.

@e0ipso Nice idea! That said, the "Maintenance status" and "Development status" of modules seem to convey similar information. What is the benefit to adding this file rather than just revisiting the status options available and how those options are displayed to the end user?

For people who have been paid to create modules -- but not paid to maintain them -- I could imagine a similar benefit to simply being able to set a module to "minimally maintained" and then to set the development status to "hire the agency I work for to sponsor features" (to quote your article). But what you said makes sense to me, and I like the flexibility of a `MAINTENANCE_MANIFESTO.md` file that can be catered to a module's particular situation. Plus it would be a format that could be adopted by other free software communities.

Perhaps a good question to consider is whether we want this work like a select list, with limited options that the community agrees would be helpful, or if we want this to be more like a body field with pretty much unlimited flexibility. I guess I could also imagine this being good information to simply include in the description field of the module.

Personally, I don't have strong feelings about how it's implemented technically, but I really like the idea replacing (as you rightly put it) "complicated social interactions" with a standard for conveying more about the state of a module, what users can expect, etc.

+1

I agree 100% with the rationale for the MAINTENANCE_MANIFESTO.md file. Your blog post did a great job of explaining it! I even agree that the file should be easily accessible and linkable from d.o.

I think that this particular issue might be putting the cart before the horse though. If we start the initiative by adding a d.o feature, there's a good chance we'll end up with a less than ideal designed-by-committee solution.

Where should the link live?
What should the UI for adding one look like?
What options are available?
Should we have 5 templates or 10?
What should the first sentence of the 3rd template be?
Should this template cover that?

Instead of starting with a d.o feature, I think it might be good to let this norm emerge in the community and then formalize it.

How could we do that?

Make a GitHub org called maintainers-manifesto and create a really simple, static, single-page site (maybe that uses GitHub pages or something) under that org. The site would explain what the idea is (it could link to your blog too) and it could link to a few example files that are ready to go.

We could add a few default templates very quickly and then accept pull requests to add and refine those templates iteratively. This would be in place of trying to come up with a completely acceptable set of templates all at once so that they could be added to the d.o feature.

I think you could come up with a little embeddable HTML snippet on that static page (that you know passes d.o's HTML filters) and add them to all of your maintained projects. Put that snippet at the top of the static site's homepage. That snippet could have a placeholder for a link to the file. For d.o, that link would go to a project's GitLab (so it'll render the markdown). I would add that snippet to all my project pages. We can then reach out to other top module maintainers and ask them if they would also embed the snippet on their project pages.

When it becomes a norm to have this file and that snippet, and when that norm has been refined "in the wild", then we should make it part of d.o by default.

WDYT? I'd be happy to help with any part of that process. I really like the idea of the file :)

I agree that https://www.lullabot.com/articles/healthy-open-source-maintenance is great 👏👏👏❤️

My only hesitation is that it may be hard for this to become the norm without Drupal.org prompting you about it when creating / editing your project node.

I think you could collaborate with a handful of module maintainers that have high-visibility modules (think https://www.drupal.org/project/webform and https://www.drupal.org/project/entity_embed). That results in maximal exposure for minimal effort and has the highest probability of encouraging more module maintainers to follow this example.

I wholeheartedly agree with this issue. Most (all?) of my modules has a maintenance status not at all covered by the current drupal.org checkboxes: this module is in use by our company, we released it, we strive to make it general but noone is paid to fix the issue of anyone else and because we dumped like a dozen modules it'd be a major time and cost issue to actually maintain them properly. If someone comes along to take it over, yay. It is a cross between abandoned and actively developed.

Huge +1 to this. We need to find more ways to make contribution sustainable and this can help a lot. Thanks for giving your time for this @e0ipso!

+1 to this! I've shared some feedback about the landing page with @e0ipso. Looks great!