Add maintenance status for projects

Good idea.

Call it "Unmaintained/abandoned/obsolete" so it is a catch all.

Ok well that's a little long. ;) We should probably pick one or two of those. :)

And come to think of it, we might want two statuses:

Unmaintained (seeking maintainer)
Unmaintained (obsolete)

This would differentiate between modules where the maintainer is just too busy and those that have been obsoleted by newer technology (for instance, most of the content type modules w/ Drupal 5.x).

how about simply

"seeking maintainer"

and

"obsolete"?

Works for me!

I'd like: "looking for co-maintainers" so you can backup before you get hit by the bus.

after discussion in IRC with webchick, i started to implement this. however, we discovered that we really want these to apply to themes and translations, too, and we're not currently using the 2nd-tier terms for either of those.

it'd probably be best to have another vocabulary entirely, that applies to all project nodes, for "Maintainence status" or something, with the choices "Seeking new owner", "Seeking maintainers", and "Obsolete". not sure what to do about modules that are "happy" with their current status. no term? make the vocab optional? *shrug*

it's not clear we need/want the custom browsing stuff for these terms, like the module categories. but, i'm just not sure. we should figure it out before we take any more action.

further thoughts?

p.s. i deleted the existing obsolete/seeking maintainer terms until we decide if that's really what we want or if we want this separate vocab.

I think the simplest solution is:

a) Separate vocabulary "Maintenance status" with terms:
- Maintained
- Needs help
- Obsolete

b) Don't worry about integrating with project module, at least at this stage; the pertinent info can be visible on the project page, and you can click "Obsolete" to get a list of obsolete modules.

however, if it's not the official project browsing pages, people won't necessarily know where to look. for example, imagine i'm a young dojo-ite, and i want to look for some modules that are seeking help. unless i already had that taxonomy page bookmarked, i'd just have to scroll through projects, looking for 1 that says "needs help" and then know to click on that to get a list of all such projects. :(

the plus side of doing it as a module category (which still requires no additional code, only taxonomy configuration) is that people will automatically understand how to search for all modules in each of these states.

however, i guess we could add links to these taxonomy term pages in the contributor links block or something. not sure where else to give them visibility. we could add a new block that only shows up on /project/* pages or something with these links, instead...

I wouldn't create a new category for it in the existing project vocabulary. That seems a little bit awkward. I'd implement this either using a new vocabulary or using a simple field in the project_node table.

Anyway, the implementation is not that important. What IS important is how we want to present this information and how we envision this to work when looking at individual projects, when showing listings of projects, etc. I think we should start from the use cases and than figure out the implementation.

I think this goes further than just adding a new taxonomy term or a taxonomy vocabulary. If we want to do this right, the user interface and interaction design go first -- the implementation details follow that.

For example, on a project's page it should be super-visible whether a project is maintained or not. And by super-visible I don't mean tucking a small taxonomy URL somewhere in the corner of a page in the middle of a bunch of other taxonomy links. Instead, there should be a box with red text saying that this module is no longer being maintained.

I'm not convinced we're approaching this the right way. For example, I _still_ think this is a better approach: http://buytaert.net/temporary/project-information-at-a-glance.png ...

Why do I think it is the better approach? Because it let me weigh in and estimate the risk.

For certain projects I might be willing to take more of a risk than for other projects. If I setup a Drupal site for my intranet, or a throw-away conference website, I don't really care how active the project is or how many maintainers it has. I might even chose to go with an abandoned project and an older Drupal version. (What does 'abandoned' mean? If it works for Drupal 4.7 but not for Drupal 5.0, it could still be a very useful module -- we can't remove it from the listings. I could decide to go with Drupal 4.7 instead of Drupal 5.0 just because I need this project.)

However, when I setup a high-profile Drupal website that will be around for years to come, I might want to discard projects that have only one maintainer. Or, maybe there will be poorly or slowly maintained modules that are not officially abandoned. Should be have a 'barely alive category' as well? I don't think we do, yet this kind of information is important!

Providing me all that information allows _me_ to make a decision based on my needs and experience. At the end of the day, you can't make that decision for me.

Yes, 100% agreed on your screenshot being a much better approach. There is a critical feature request against project module for it here: http://drupal.org/node/79550 (assigned to me, even).

The problem is, grokking project module code is very hard; sticking an extra couple terms in is very easy. And both ways, people get a sense of what projects might be struggling, and what projects would be potentially dangerous to depend on. They obviously get a much better sense of that from automated quality metrics, but this is a simple way for a maintainer to clearly flag, "I'm not going to be maintaining this." or "Don't bother using this module at all -- use something else." We might even need this functionality regardless of the quality metrics... for example, if there's a module that I need to write for a client, there might be a flurry of activity which would bump up my stats; however, I might have no long-term plans to provide support for the module, and would love for someone else to take it over if it's found to be useful.

The reason the terms kind of have to go in the same "project category" drop-down is because otherwise, short of randomly clicking on projects until you find one that is abandoned/obsolete and then clicking the term, there's no easy way for people to get a list of abandoned projects. If we add them to the project drop-down, "<obsolete>" and "<abandoned>" will show up in the listing here: http://drupal.org/project/Modules and people can easily bring up a list. They'll also automatically be shown on the project page such as "Community" and "Modules" are here: http://drupal.org/project/og_forum.

The only way to do it with a separate vocabulary is to build support in a generic way into Project module, and again we have the "Project module code is hard to grok" problem (as well as the "dww has 120643 things to do, and we should really try not to pile more things on him if there's a simpler solution to the problem."

Those are my thoughts, anyway. I'm happy to hold off until the project metrics stuff is done, but I will need a long time to figure all that out. :(

The problem I see with adding a manually applied term is maintenance and perceptions of fairness. How much research do we require before tagging a module obsolete or unmaintained? I believe we had a recent one that Eaton was asking about that wasn't unmaintained, it was the contributor was to busy with his real life job to respond in a timely manner..

Speaking as someone who is only now starting to grok cvs, and is working with a number of active contributors, I've been pondering this question for a while, perhaps seeded by the frequent discussions on the email list. Picking up on Dries' suggestion, and looking at the user interaction etc., I can see three main goals:

1) The ability for a contributor/maintainer to disassociate from a project.
2) The ability for the developer community to evaluate whether a project is indeed abandoned.
3) The ability of a user/"downloader" to discern whether a project is being actively maintained, and how well.

While #3 is already possible by reading through the CVS messages for the project, I think the screenshot Dries posted looks great. A simple policy, such as (and I'm making up a bad example to illustrate) a project with x bug reports that have not been addressed in y months gets flagged as officially abandoned -- and an algorithm reflecting such could be built into the code that generates the block Dries posted.

With such a flag, the module gets listed in a custom page or views display -- an archive of old code, so to speak -- where the code is there for perusing for ideas, snippets, etc. by other developers looking for ideas. This would take care of #2.

#1 would require the ability for Joe Bloggs to manually flag or un-flag the project as his officially maintained project, to implement something a little more trackable than the informal "anybody want to take this over?" email.

My question is this: Does this status need to be reflected in the project module functionality? If the module or theme's project node itself has a flag that effects display only, and not any of the issue tracker functionality, would that be enough? If a person can go to a list of abandoned modules (with rss feed) as well as see what a module's active status is at a glance on the module or theme's description node, wouldn't that be enough? Could this not be done without having to modify the project module's issue tracker? Is there a need for such status to be reflected in the CVS respository directly as well?

As someone who closely follows developments in Drupal contrib, and is involved in decisions whether to try to update/enhance existing modules as well as whether it's worthwhile to contribute a given piece of code written by our developers, I can see how such functionality could be most useful to our workflows and decision making.

However, as a php not-quite-a-beginner and CVS n00b, I'm sure I've missed something, so if this comment is only marginally useful, I apologize in advance. :D

Wow, I came up with this idea 3 months later apparently.

Dries, I like your idea here, but I don't like the idea that we might wait 6 months or a year to get something we can have almost right away because it fits in well. In fact, it seems to me that this goes *against* your 'complexity is a disease' motto. Keep It Simple.

We create the taxonomy (I'd also be in favor of a new vocabulary and making a link in the handbook and maybe a contributor link as well). I'm in favor of "Maintained", "Needs help" and "Unmaintained". For the most part we can let the module maintainers handle the setting of these; for existing modules we can pretty much leave it alone until we get some community consensus on the development list.

I think a tool like this would be very, very valuable, and would be a great way for people who are new to Drupal but want to contribute can.

I'll also add that I don't think module metrics are the same thing.

They're not as accurate as me, as a module maintainer, going in and setting a module "Unmaintained". That's unequivocal and has nothing to do with with any statistics about it. So I don't agree that module metrics would replace this; instead, module metrics give us a tool for deciding if a maintainer isn't being responsible. That's different.

Another nice thing is that when we add the vocabulary, and make it required, existing projects will not get a tag; projects that continue to not have a tag after several months become easy candidates for "check with the maintainer, see what's up".

Auto-categorization algorithms are all well and good, but they take time to get "right". Heuristics are like that. That's good goal, but for right now we can get ourselves a little added benefit without much work, and without the potential for having to undo much work.

Right now, there's no good way to know if a module maintainer even *wants* extra help, or wants to offer a module up for someone else to take over. There's a page in the handbook somewhere that lists modules up for adoption, but it's, um, unmaintained. :-)

A simple taxonomy flag that a module author could set for "co-maintainer wanted" or "up for adoption" makes it trivially easy to advertise such facts to other developers. It also provides potential information to users/downloaders. It reduces the workload for whoever is maintaining the manual list.

Total cost: About 2 minutes of someone's time with d.o admin access.
Benefit: Easy and automated maintainership administration for some tasks.
Cost to undo later if we come up with a much better way: About 2 minutes of someone's time with d.o admin access.

It sounds like a bargain to me. +1

What's the status of this? I like the idea of a dedicated "Maintenance status" vocabulary, it's the easiest way to keep an up to date list of module seeking maintenance... as opposed to a wiki page that each module owner has to edit.

The status seems to be that many of us thought this was a good idea, then Dries said he didn't like it, then people replied, and by then Dries had lost interest or was busy with other things. :( So, it's languished here months. It'd still only take about 5 minutes to implement. It still wouldn't have ideal integration with the d.o project UI. It still wouldn't completely solve the problem (see http://groups.drupal.org/node/7191 about that). It still might introduce some (IMHO minor) problems of its own. But, that's the status. It's currently paralyzed by Dries's initial objections...

I guess there's also the open question of exactly what the terms should be called, but that's secondary. See #7 and #8 above. I don't really like "obsolete" as a catch-all for both "module could be useful but the maintainer is AWOL" and "no longer useful thanks to CCK and Views"...

I agree with Derek. This vocabulary can be quickly implemented as an interim solution. If Dries wants another solution, which does not mistake computed metrics/statistics with human-generated information, he should provide a valid concept for this.

I actually believe Dries' comment #10 is still valid; he didn't say he wanted automated metrics instead of this, but he did say he thought we need to figure out how we want to present/use the module status information. And once we've determined this, then figure out how to implement this (d.o taxonomy, project.module taxonomy, project.module table column, ...).

I also believe this would be a good thing for automated metrics to have available. If the status is set to "obsolete", the status block thingy could say that it was obsoleted, and if it's looking for a new maintainer, it could say something to this effect. So, yeah, I don't see these as one issue, but rather two separate issues that both have their worth, and most likely both could and would benefit from each other.

Of course, we could perform additional steps afterwards. For example, install the Term display module, or have one of our already overstrained d.o maintainers develop a customization to selectively display this vocabulary in another, highlighted location in project nodes. Theme it, extensively test it, (we all know what's usually happening)...

However, in consideration of the d.o redesign somewhere down the road, I really think these additional steps would be a waste of time and resources now. Instead of always thinking big, we should rather just add necessary information/output to d.o now, and leave the design of a well thought-out, usable, and optimized GUI to graphics design and usability experts in a later step.