[policy] Impact on contributed projects and its maintainers

Adding one more related issue.

What impact will this have on governance, funding and other aspects of contrib maintenance? Will this result in different types of contrib, the official ones that are part of Drupal CMS and the others?

Thank you, berdir, for opening this issue. I share some of your concerns. I think it's an open secret that Gin, for example, has been struggling to find new project funding and has lost more funding than it has gained in recent times. It seems that part of Drupal CMS is well funded and contributed to and some companies are even investing full time positions in parts of Drupal CMS (which is great BTW!) while other parts are only worked on in spare time. So there seems to be a gap between the different parts which could create a risk.

What impact will this have on governance, funding and other aspects of contrib maintenance? Will this result in different types of contrib, the official ones that are part of Drupal CMS and the others?

The honest answer is we just don't know yet. It's a really complicated issue without an easy solution. But certainly something we have thought about and talked about, and are conscious of.

What if the product managers of Drupal CMS want a Redirect feature that I'm not willing to maintain? What if I add a feature to Pathauto that conflicts with the strategy of Drupal CMS?

The easy answer from me is: it's your module, you can do what you want! Of course, we hope that we can align with maintainers, and I don't expect there to be many cases where there is a direct conflict. But it might happen. Maybe I am reading into it a bit, but it feels like an unspoken part of this question is, "Will there be pressure from the Drupal CMS team to do something I'm uncomfortable with?" This isn't an official policy or anything but for my part the answer is "No". There are many ways to work around disagreements, some of which are outlined in #3488829-8: [policy] Patching dependencies → . I would think existing governance on this is sufficient, unless there is a worry that efforts would be made to intervene/overrule a maintainer and commit something against their wishes?

So I guess it's more useful to discuss what is the best way to document some answers that would relieve your concerns? I'm not really sure how we could write a policy that is generic but also useful. If you have thoughts on it, or examples of principles that would be a good starting point, I would like to hear them.

I didn't mean to postpone this, sorry! Too many issues open I guess.

I like the idea of "Golden Contrib" which was proposed years ago
https://www.drupal.org/project/drupal/issues/1255674#comment-4917546 →

It's basically a curated list of Drupal modules and themes.
For each project in this list DA must ensure that
- It has active maintainer
- It has a stable release compatible with the current Drupal core
- It has proper documentation
- It complies with the strategy of Drupal CMS

One of the ways this is simultaneously impacting both maintainers and Drupal CMS is the large number of pre-release modules included in Drupal CMS.

That would be completely fine during development or even rc, but now there is a hard deadline for a stable release in January which I don't believe was communicated to any of those contrib maintainers before it was announced - it certainly wasn't communicated to or discussed with core committers or the security team beforehand.

There is clearly funding going into some parts of Drupal CMS, but one way to reduce negative impact on contrib maintainers would be to provide some funding towards tagging stable releases of versions that are included.

The other side of this is for site builders. Will we get stuck on older versions of CMS because a module we're using doesn't get updated, as was frequently the case back in Drupal 5, 6, 7? I would like to see a category of contributed modules that includes some kind of guarantee that they will get updated along with Core releases and will not be abandoned. Indeed, I believe this is necessary for the long term success of Drupal-CMS.
The implications of this is that there needs to be some sort of committee, that would define a process so that if a developer is no longer able to maintain a module, they can facilitate finding someone else who will. This along with #6 above.

We already have a process for taking over modules that are no longer maintained. A "guarantee" is not really feasible, since there is nothing commercial here, we are all just volunteers or sponsored by our companies at their discretion.

Certainly, we are vetting the modules included in Drupal CMS carefully, and it is highly unlikely that a module that is included would be totally abandoned. But if that did happen, the Drupal CMS team and the wider community would work toward a solution. I don't think this can be formalised, at least not for now.

Re #9: see also https://www.drupal.org/project/puwg → as a formalized way to keep projects updated to the latest versions of Drupal if the maintainers are unresponsive.

Thanks @dww!