Automatically degrade maintenance and development status of projects over time

Totally with you on this.

I'm also in favor of (auto-)flagging a module as:

• Currently broken
• Partially broken
• Functional with minor defects
• Fully functional

This could depend on criteria such as issue priority, number of open critical issues, etc.

A time delay could also apply to some criteria in order to not immediately affect the status of the module and allow the maintainer sufficient time to respond and solve or acknowledge the issue.

We really need some kind of community-based quality control in Drupal. It could save hundreds of man-hours of work and investigation.

Well, a time delay in affecting the "rating" would help here. In this time frame the proper priority can be set by the maintainer or even the community, if the issue is not that important or not an issue after all.

Also, community testing guidelines should be issued and abuse of priority should have repercussions on the user found in violation.

True, but you do have to warn and/or revoke issue-opening rights for e.g. a few weeks, when priority is abused in order to speed up responses to one's issues.

Anyway, how can we get more people to join this discussion?

I'm afraid this thread doesn't have very high visibility.

Should we perhaps start a Drupal Groups discussion?

It seems there is no interest in this or this thread is has not been read by anyone from the core Drupal team.

To be more specific, here are some very important projects which now appear to be minimally maintained and should probably be marked as such:

• Date
• Calendar

Commits date back almost half a year, the number of major issues is very large and most comments are a case of "me too" "subscribing".

I personally have some encountered some issues in these modules for which no solution appears to be in the cards...

It is natural to reallocate resources to 8.x and I'm sure everyone will agree that KarenS's work is most appreciated.

However, in the mean time, the nearly abandoned state of the 7.x versions of these modules are being used by a lot of people who would have the logical expectation that these modules would be regularly maintained.

A new user wanting to add a calendar to their site should not need to dive into the issue queue to see why their calendar page is throwing dozens of PHP warnings.

Other modules, such as Views Calc, do not appear to be working at all.

Note that there appears to be no alternative to Date, if you need that kind of functionality.

A warning on the project page would be most useful to advise users to install the module with caution or not install it at all if it is currently broken.

This is kinda the opposite end of #2186377: Highlight projects that follow Best Practices (the carrot).

What's being proposed here is the stick. I think that's good.

There are elements that we can degrade over time. Might even want to have those show as colors when looking at people's profile pages.

Great idea.

As far as the Date/Calendar modules go & KarenS' participation in D8.

What are our incentives for people to contribute back to complex modules like the this one? I posted this issue asking #2183117: Dates are Important - So Why Are there over 1000 open issues?

I've also posted a series of other issues about maintenance of modules.

Our motivation structure really hasn't kept up with the growth of the community.

It should be clear which modules are being maintained by well meaning hobbyists who will get to it when time allows and by Drupal shops which are paying someone (or a group of people) to ensure that a popular module is going to be a stable and reliable choice when implementing a site.

There are lots of excellent folks who contribute to drupal.org on the side and who really know Drupal inside & out. However, the scratch an itch approach really only gets us so far. It's not a great incentive for maintaining a popular project.

I'd be fine with giving the project maintainer the ability to change the project status. However, if the project still doesn't meet the standard the next time it is evaluated it would just be changed.

Ultimately, project maintainers just get too busy most of the time to go back and even look at their projects. We're really not going to have a problem as very, very, very few maintainers are going to try to game the status page to make it look better maintained than it is.

We want to support the behaviors that help the code and community, and put up additional barriers against those behaviors that don't.

I've got no problem with investing in a neutral way to inspect a project and provide an overview indicator that is easily understandable. I'm just thinking about other options.

Ultimately, we need to be able to work experimentally on these issues.

We could apply these changes with an A/B type mentality so we can look at the results. Simply looking at even/odd projects we should be able to get a sense in a month or less what the impact of putting up these ratings might be for an individual project.

We need to understand the impacts on the community and iterate quickly to be able to improve on the feedback we're given.

I put up a patch #2186377-4: Highlight projects that follow Best Practices which has some of the metadata that you'd need to do this.

You'd want to build a function that probably uses drupalorg_project_cron() to do this nightly or something.

Along with an over-time degrading maintenance status, it would also be useful imho to have an indication whether the module / theme currently delivers on what is "advertised", e.g. whether the core functionality works or if it is partially or totally broken.

If the module comes with tests, a github-like indication on whether the latest official or dev branches are passing or failing would also be nice to have.

@marktheshark - can you think of any way to automate that for the 20k some odd modules in contrib?

Is it just a matter of adding another category in the status more serious than critical?

Maybe it's just a matter of counting the number of criticals?

What if it works well in D6, but not in D7?

Agreed about the simple indicator. That should be easy to pull out of what I've done for the Health Indicator. A simple start.

Yet another module with major issues never responded to:

Views Data Export

The status of this module should not be marked as actively maintained.

There was a dev release from 2013-Oct-19. How active should "Actively maintained" be?

The latest dev release date should not be the sole criterion for deriving the maintenance status, imho.

Ok, but this needs to have some numbers.. As I've shown here, there is a lot that can be done #2186377: Highlight projects that follow Best Practices

But someone needs to define Actively maintained.

It would be great if we could find an automated way to get to comment #3. But not sure that is possible.

We can define Actively maintained as:

• Activity in git in the last 3 months
• A release (dev or stable) every 6 months.
• Activity in the issue queue every month.

I really am not sure what numbers to run for, but we really don't want to start off failing the majority of all modules. We have to start off at a level where most are passing. If the norm becomes understood as unattainable then it won't be a motivator.

So based on the current list https://drupal.org/node/1066982

I can see dropping a module to Minimally maintained.

I can see it becoming Unsupported if it doesn't have a D7 release (at this point) or hasn't had activity of any sort in a year.

Moving from infra to d.o. queue.

Yes, please. There are less-experienced people who see a unmaintained module's page and assume that it works perfectly.

This is something we need to address. I've been working on getting some project application policy changes, and those changes will only increase the number of projects and maintainers we have.

One of the biggest concerns has been, and will always be, security. The number of contrib SAs seems to be increasing, and we may reach a point where there is too much for the security team to caretake. We need to protect our user base, many of whom are not savvy enough to recognize a project that is not well maintained. And we also need to be mindful of the many reasons why a module reaches a certain state. Some are perfectly fine in the condition they are, even if they haven't had a recent release, and some are not of the highest quality even with a recent release.

If we want a more robust contrib ecosystem, especially one that is designed to reward and promote quality maintainership, we'll need to start implementing some of these ideas.

A rating system has been discussed for the d.o roadmap, as well as auto-scanning projects for security and health. The scanning is a good start, and if the project application changes are approved we can put that infrastructure in place. Some of the things discussed with the scan involved displaying stats or levels of health on the project page. I'm not sure how this will actually look though.

If the project statuses are automatically changed because of inactivity, is there a point to "minimally maintained"? It seems like we should go to "unsupported" or maybe we need to come up with a new set of statuses that better reflects these changing states. I see a difference between a module that has problems and isn't being fixed, versus one that isn't broken but may have outlived its usefulness.

The idea of counting critical issues has come up a couple times. As a maintainer, I’ve had plenty of issues moved back to a higher priority after I’ve done my best to give it a fair priority. I usually don’t bother updating the status anymore, there’s more useful things to do than nudge priorities. I wouldn’t want to build a system to attempt to restrict priority changes; there are cases where a maintainer does miss something and get it wrong.

Pulling in abbreviated definitions from https://www.drupal.org/node/1066982, and marking a few like “Seeking co-maintainer(s)” off-limits to algorithms.

Adding things we can measure to the issue summary - taking factors from #28 and the original issue summary.

I’m leaving off “they have low or 0 usage stats” since something could be very well maintained, but that doesn’t mean people use it.

Adding some stats to issues. Very broadly - if we say “not active” is not having a commit or issue comment in the last 24 weeks, about 4∕5 of projects will be moved out of their status.

Correcting HTML

I’m not sure where project pages were when this issue was filed, but we do show commits and issue queue activity on project pages. We could de-emphasize these terms, and display activity more clearly, grouped together and more readable.

That's 4/5 of all projects, right? How does that look if only looking at, say, the top 20% of projects?

Adding numbers for projects used on 500 or more sites, which is close to the 20% most-used projects.

From the security team's prospective, this is an awesome idea. However, I would take it a step further.

A bot will create an issue in the public queue. A maintainer would have to mark the issue closed (fixed) If a non maintainer did that, it would just reopen it.

If that happens great. If not 3 weeks later, the bot would move the supported status of the module and maybe tweet or something about it to get attention. This would have prevented what happened with the references module.

mlhess - I think that would be a separate issue.

davidhernandez - with the limit to projects used on over 500 sites, the 4/5 number becomes 1/5 of projects marked “Actively maintained” have not had an issue comment from anyone in the last 24 weeks.

Unassigning myself since I’m not actively working on this. I’d like to spend some time shoring up the visibility of quantitative activity measures, and reducing use of these terms in general.

Moving this over to the project ownership queue, since it's related to #3231027: One-off process to encourage adoption of Drupal 8 projects without a Drupal 9 compatible release.

We either need an issue summary update on this issue, based on that discussion, or since this issue originally dates from 2011, it might be worth starting a brand new issue with a summary and closing this one as duplicate.

This topic need to be re-focused.

My impression is that projects that re not being updated get their "Actively maintained" and "Under active development" stautuses hidden when certain criteria are, but that nothing is actually degraded.

If that's correct, I think it is an excellent solution. The problem at the core here is that some project's status does not reflect reality. By hiding a status that's probably misleading, that problem is solved. Mark this one as "Fixed".

However, as shown by the #3231027: One-off process to encourage adoption of Drupal 8 projects without a Drupal 9 compatible release, we have a different problem whenever a major core version approaches EOL: How to identify and encourage adaption of contributed project that does not have a release compatible with the next major core release.

We need to find a policy for handling this for all future major releases. I am not even sure that this need to have anything to do with the metadata for maintenance and development status, so to focus on that, we need to have a new issue.

So – after 11 years – we need to close this and open up a new issued focused on the problem of encouraging adoption of abandoned contributed projects.