Problem/Motivation
Many maintainers feel anxious because of issue queue pressures. They have a hard time saying "no" or setting maintenance expectations. They may have thought to just share their code and keep take a look at the issue queue occasionally. The reality of a maintainer may be a bit stressful and could lead to burnout and contributor abandonment.
There is more context in this article.
Proposed resolution
Drupal.org could check for the presence of a special file called MAINTENANCE_MANIFESTO.md
. This file sets the expectations on the module maintenance (how to get your bugfix prioritized, how to sponsor certain tasks, what to expect in terms of response times, etc.)
When a user creates an issue for a project that has a MAINTENANCE_MANIFESTO.md
, a message should be shown to the user linking them to the manifesto.
What I'd put in the manifesto are things more in the line of:
- "I understand this is important to your company, but I don't want to work for free for your company. This is the process to get us to collaborate on making this happen."
- "I am sorry that I broke your site after the update, but I may not work actively to fix it. You need to understand this before installing the module."
- "I'll work hard on this module as long as my Open Collective budget is over $XXX, otherwise I'll need to slow down maintenance."
- "I will fix bugs by my own order of priority. You can get a bump on the priority list by helping me write documentation."
- "There is a ladder to co-maintainership. If you help contributors, write tests, participate in discussions, etc. you'll be offered a seat in the module mainteners."
These are more personal reasons, and also more financial reasons. I think that having a free-form file (with some templates / snippets) will allow for more flexibility on the side of the maintainer. That will avoid having to file Drupal.org feature requests to add yet another nuanced option to the existing radio buttons. It would also be portable to other registries like packagist, npm, …
When a maintainer creates a project, they should be offered a set of pre-made manifestos in a radio button. This will commit the manifesto to the repository with a link to the canonical pre-made manifesto, so the maintainer doesn't have to write it.
If a manifesto matches one of the pre-made options, a badge/icon should be shown when viewing the project page.
Remaining tasks
- Get buy-in from the Drupal Association. HELP NEEDED!
- Create screenshots with mockups.
User interface changes
- The issue creation form now adds a message if the manifesto is present.
- The project creation/edit form has a list of pre-made manifestos to choose from.
- The project page displays a badge when the manifesto is present.
Comment | File | Size | Author |
---|---|---|---|
#4 | maintenanace.png | 58.38 KB | mtift |
Comments
Comment #2
drummhttps://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.
Comment #3
e0ipsoI believe the
CONTRIBUTING.md
talks about the users of the project, not the maintainers. I could be mistaken about that, but in any case, that's just how I've seen it used. I see a different purpose just like I see differences between a project CoC and the CONTRIBUTING.md guidelines.This is very on point. I belive the feature may benefit from some evolution, for several reasons:
Comment #4
mtift@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?
Comment #5
e0ipsoI think this hints that we agree on the principle that the status quo doesn't capture all the nuances that may be interesting to cover.
Maintence and development status are great indicators of the project activity and level of involvement. However, I struggle to see how to choose between Actively Maintained and Minimally Maintained. I always try to respond in a "timely manner", but if someone is going to treat that as an SLA then I should say that it's Minimally Maintained even though active maintenance and development may be happening.
With regards to Development Status I have never considered anything other than Active development. Because if someone comes with a cool idea, I'll work to see it merged. Even if I see it "feature complete".
What I'd put in the manifesto are things more in the line of:
These are more personal reasons, and also more financial reasons. I think that having a free-form file (with some templates / snippets) will allow for more flexibility on the side of the maintainer. That will avoid having to file Drupal.org feature requests to add yet another nuanced option to the radio buttons.
Another reason is that this is an established pattern for similar things:
LICENSE.txt
,CODE_OF_CONDUCT.md
,CONTRIBUTING.md
,humans.txt
, etc.I don't think the current tooling in Drupal.org covers for that. I pondered before writing the article about the
CONTRIBUTING.md
, but I don't think that's the intention of that file.Comment #6
e0ipsoComment #7
mtiftFor 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
Comment #8
gabesulliceI 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 :)
Comment #9
e0ipsoComment #10
e0ipso#7
Yes! That is one of the goals, to lower the barrier for this to be adopted elsewhere.
#8
I agree vigorously with most of this. 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 don't see any problem executing your vision and when we have a decent list of manifestos we ask for it to be implemented in Drupal.org to help bootstrapping adoption and awareness.
I just learned that idiom. In Catalan we have putting the plow before the ox, which I guess is very similar in spirit.
Comment #11
e0ipsoFor now, we have this Org without nothing in it. We'll see how this evolves if anyone else jumps in.
https://github.com/maintenance-manifesto
Comment #12
Wim LeersI agree that https://www.lullabot.com/articles/healthy-open-source-maintenance is great 👏👏👏❤️
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.
Comment #13
e0ipsoThat's a very good tip. I'll try to get a list and ping the maintainers when we have more manifestos. Also, I wonder if @jrockowitz would be interested in being involved in the process.
Comment #14
Ghost of Drupal PastI 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.
Comment #15
e0ipsoJust sharing some progress here. I created a landing page for the initiative: https://maintenance-manifesto.github.io
If anyone has them, I'd love to get inputs on:
Comment #16
ckrinaHuge +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!
Comment #17
slv_ CreditAttribution: slv_ at Lullabot commented+1 to this! I've shared some feedback about the landing page with @e0ipso. Looks great!
Comment #18
e0ipsoAfter a round of feedback on the MAINTENANCE_MANIFESTO.md site, I am happy with where things are at. https://maintenance-manifesto.github.io