Add maintenance status for projects

Good idea.

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

how about simply

"seeking maintainer"

and

"obsolete"?

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.

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.

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.

Over at #197186-38: Update.module doesn't warn sites when their current release has been unpublished., I introduced code into all versions of the Update status module so that we could potentially mark entire projects as "Unsupported" or "Insecure" when they were being abandoned, instead of simply unpublishing them. If we just unpublish we get lots of problems, for example #345177: Can't access Friend project page. That said, I think the drupal.org D6 upgrade is more important, so I don't want to spend time on this right now, but I wanted to point this out as the discussion around #356002 flails...

So, this seems rather an interesting discussion and since I am the one who created this #345177: Can't access Friend project page , I'll add some salt.

Of course, there is a couple of basic features that would be nice to add:
-Keeping a page available for information but maybe not the downloads if there is a risk for example
-A way to search/list for unmaintained modules (for devs?)

If information is the only thing that matters, like the Dries images, can't this be put manually in the description?
Of course, if you want some stats, that's another matter.

I created some little images just for fun, and hope this can inspire :) Our imagination combine with the energy we have to put on this is the limit! :)

The images are a combination of status (manual work) with automatization (changing the status, changes the presentation of the project). But there could be way more in combination with stats, action module, workflow, or other ways to change the status after, let's say a year of inactivity.

Thoughts:

• Four statuses:
  • Active
  • Seeking co-maintainer(s)
  • Seeking new maintainer
  • Obsolete

There would need to also be a simple way to query this and/or add static pages (/project/by_status/active, project/by-status/co-maintainer, etc) so people could look up a project to help with. To make it prettier it could be displayed on the project homepage across from the title with an icon to indicate the status (a green drupalicon for Active, a yellow for Co-Maintainers, a red for New Maintainer, and grey for Obsolete).

I think merlinofchaos is right that a simple selectable list has its own value. Project metrics based on commits, issues life, number of maintainers, are useful but it doesn't give the same simple power as a maintainer being able to say "Hey I need help." or "Hey I'm committed to this module and I'm not leaving it anytime soon." Many drupal insiders have had a bit of this insight for a long time by just listening to the mailing lists, IRC or the issue queues but this would bring it to the rest of our users in a very visible way.

Also, the Drupal community isn't going to let views, token or pathauto just die because a maintainer walks of even if there was only one. Grouping this basic status switch with the usage stats that we have already added to project pages should give at least a basic idea of the stability of a project.

That said, the only other thing I tend to use when choosing modules is code quality/complexity and I don't think we're going to be able to put that on the project page. ;)

I'm not really sure on what would be the best options for this or UI at the end of the day but that's at least my feeling on where we should start.

Is there any news about this feature?

One good thing that's happened in the meanwhile is that all the project browsing pages are now powered by Solr. So, it should be incredibly easy to add another facet block for this taxonomy on the project browsing pages.

I think a separate vocab is the way to go. I'll implement this early next week unless there are any (viable, compelling) objections...

I added a vocabulary Maintenance status with the terms suggested by DamienMcKenna, which is associated with project nodes.

I forgot to report the link to the vocabulary edit page: http://drupal.org/admin/content/taxonomy/44.

Cool, thanks! So much for "I'll implement this early next week..." ;)

Next step is we need some UI help on the project nodes. This term is in fact buried as "a small taxonomy URL somewhere in the corner of a page in the middle of a bunch of other taxonomy links" (to quote Dries from #10). See attached screenshot.

Of course, the d.o redesign is under way, so maybe this should just wait until the first redesign deployment. But, either way, we're going to have to figure out how we want this to look on project pages and do something special with these terms.

We should also add a solr facet for this on all the project browsing pages (either as a block for now, or as form elements once #425986: Convert project browsing facet blocks to a navigation form lands).

Another question after trying to use this: what's the accurate term for these two projects:

http://drupal.org/project/user_status
http://drupal.org/project/update_status

?? Both are 5.x-only modules, since I managed to move their functionality into core for D6. So, for D6 and beyond, they're "obsolete". However, for D5, they're "active". Now what? ;)

@dww: I'd assign them to our Abandoned Modules user, disable the issue queue, and be done with it. http://drupal.org/project/upgrade_status may do the rest for people that care.

@sun: But they're not abandoned at all. I just recently had to release a new version of update_status, for example...

I think adding a solr facet is the important part here (besides tagging the actual modules). It would allow us to not show obsoleted modules in the default results when browsing for modules.

Would be more taxonomy terms useful?
So far, the existing terms would allow to filter out not active projects, including the ones for which current maintainer is looking for a new maintainer.

I'd say mark them as active. They don't have any 6.x releases, and the project pages clearly state that they are in Drupal 6's core. So they are actively maintained, and should thus be "Active". As soon as you discontinue them, they should be marked so.

I'd like more terms to give an indication of how actively a project is being maintained:

- being actively developed: new stuff is in the pipeline.
- being actively maintained: bug reports will looked at, requested features may be implemented.
- being basically maintained: bug reports will be looked at, and that's about it. If patches for features are posted, they will be looked at.
- dormant / badlands / code'n'run / whatever you call it: this was a one-shot module for a client that's been posted here in the hope someone else will find it useful and take it forward. Here be dragons.
- totally abandoned.

(closing #687580: Add a vocabulary to modules to indicate maintainership status that I filed on the Redesign component as a duplicate).

subscribe

tagging

@joachim: That means to add two more terms: maintained, and basically maintained. I take that active should be understood as actively developed.

This isn't essential to the drupal.org redesign. Feel free to launch any time before or after the redesign, or not.

I added two terms more as per #42.

I just do not found what is the difference between active and actively maintained. Would be nice to have a basic documentation explaining what each status means, like this page does for issues status http://drupal.org/node/156119

Yes definitely -- I was just thinking the other day there should be a page that explains in detail what these statuses mean, both for users seeking clarification (maybe link the term output to the page?) and for maintainers to be singing from the same hymn sheet.

I think what I mean with "being actively developed: new stuff is in the pipeline" was the way that a module that only has dev releases rather than stable releases can be said to be 'under active development' -- expect it to change a lot and possibly stabilise, or then again, blow up ;)

Module builder, I would say, is under active development. There will probably never be a stable release, and while I'm maintaining it I'll be occasionally tinkering with it.

Active was first reported in comment #26, and the following comments were not against its introduction.
Clearly, having both active and actively maintained is redundant. Actively maintained was introduced to specify the degree of the maintenance status; a project could be maintained, but the current maintainer simply apply patch suggested by other users, when s/he thinks the patch introduces a desired feature, or effectively fixes an existing issue.

The terms should be probably reviewed, and verified one by one.

Renamed "Active" to "Under active development". Let's add more doc now :)

Should then actively maintained be removed, or does it make sense to have both under active development and actively maintained?

I think that whatever taxonomy terms we adopt, there should be a page that explains what the meaning of the single terms is; it's rather difficult the single terms are self-explaining (especially for users whose first language is not English), and terms don't use more than 2-3 words.

Also, as I raised at #935106: Split out project taxonomy terms from the generic "Tags" into vocabulary-specific display I'm wondering if when these terms are printed on project nodes should they link to a handbook page explaining what the status means or to a listing of other projects from the same status? Seems better to link to a handbook page. I guess that page needs to get written, first. ;)

Tagging for redesign, since this is more visible now that #935106 is live.

Should we change actively maintained with moderately maintained?

In this way we would have:

• Under active development
• Moderately maintained
• Basically maintained
• Seeking new co-maintainer(s)
• Seeking new maintainer

I apologize for the cross-posting.

As I understand the point of "Under active development" it means "things are changing rapidly, probably not a great idea for your stable website", but that's not self-evident from the name.

But this is turning into a mess, like d.o tends to like apparently. What started as a relatively simple issue is being overly complicated by lots of people coming in with other edge cases they'd like to see supported (I've contributed to this problem, in fact). Lest this turn into another mammoth bikeshed like we've had many times for issue status values (I won't even bother linking those threads) I'd like to appeal for everyone to try to keep this as simple as possible.

"Under active development" shouldn't mean "not a great idea for your stable website", it should be "people are actually paying attention to this and actively working to improve it.

IMHO Kiam's list is too long, the following would be sufficient:

• Under active development
• Maintenance only
• Seeking new co-maintainer(s)
• Seeking new maintainer

The key is having separation for "the maintainer(s) are actively working on it" vs "the maintainers only do bugfix/security fix releases", IMHO that's what people are really concerned about, not some sliding scale that gives a rating the ratio of commits vs releases vs issues closed (include_once('./crazy_logic.inc');).

If there was a way for this to be automatically updated after X months of project inactivity that would be awesome too ;-)

Also, part of the problem may be that many modules sit in alpha/beta/dev state perpetually and never have a "stable" release, despite being used by thousands of sites world-wide, so when someone goes to decide whether to use it they can't tell if the module will work or they should expect their site to be blown up. So, rather than trying to cope with every possible permutation of developer activity vs module stability vs functional completeness, just having some simple "status" categories (as listed above) and trying to encourage developers to keep their project summaries accurate regarding the module's status would be a better route.

The list in #56 makes sense, to me; the first two terms should be enough to make a distinction between a project were the maintainer is developing nee features (or refactoring the code), and a project were the maintainer is only applying patches proposed by others (in other words, between an active development, and a passive development).

I disagree. I see there are two levels of maintenance of stable modules:

- a) Maintainer(s) have time to implement your feature requests and will fix your bugs
- b) Maintainer(s) will fix the criticals; anything else will be met with a comment of 'If you post a patch I'll review it'.

I might even split b) up into 'will fix bugs' and 'will only fix criticals'.

It could also be said that 'seeking' statuses are orthogonal to this. A module in *any* state of maintenance may be seeking new blood.

The previous WTF was "What's the difference between 'Active' and 'Actively maintained'?!"

Now the WTF is "What's the difference between 'Under active development' and 'Actively maintained'?!"

Just renaming 'Basically maintained' to 'Maintenance only' leaves the WTF unsolved, and is basically an irrelevant, orthogonal change.

I also think #60 is over-complicating this, so -1 to that and #61.

However, I agree that the 'seeking' status values are a bit out of place. Either we should make this a multi-select (probably a terrible idea) or split those two off into a separate vocab. Something like "Maintainer requests" that'd be an optional multi-select, with the two current seeking choices, plus any others that seem really useful and important to be able to facet projects on. At least we now have a very good place in the project UI (and drupalorg_project code) to handle the display of these other vocabs, so that's basically a solved problem (in fact, it will probably require 0 work -- the code already should automatically do the right thing). This would only appear in the "Project information" block/pane on project pages if any of the terms were selected. But, it'd be a well-defined place for maintainers to make requests so that needs and resources can be more effectively matched. I really don't want to over-complicate things. But, saying "just put a note in the body of your project description" won't really be easily searched/filtered in the project browsing pages. There are currently 268 projects seeking a co-maintainer, and 143 seeking a new maintainer, so these aren't obscure edge-case status values that we should completely ignore. At the same time, I have no idea how often someone thinks "I'd like to adopt a new module, lemme search for the ones seeking a maintainer". It's a bit hard to quantify that.

Anyway, regarding the WTF at the top of my comment, I support #59 -- collapse "Actively maintained" and "Basically maintained" into "Maintenance only".

p.s. Ideally, we'd run a query to automatically move everything from 'Actively maintained' into 'Under active development', remove 'Actively maintained' and rename 'Basically maintained' to 'Maintenance only'. I think that's going to make the least work for maintainers to re-re-reset these terms on all their projects.

Keep in mind we won't ever capture everything in a few taxonomy terms. We already have the body text field and are working to include more quantitative information, like commits and issues over time.

Sorry, #65 was an x-post followup to #62...

@webchick #63: I like that a lot. The only question is where to put "Obsolete".

@webchick #64: I totally agree. I was trying to make it clear I support retaining this info. I was just acknowledging that I don't have hard data to support how useful it is to be able to search on these. But your anecdotal evidence is most welcome. Apologies if it wasn't clear.

Regardless of how we clean this up, we need to do this:

#950972: Use Maintenance & Development status on project browsing pages

I split that out into a separate issue so it doesn't get lost in here.

@drumm #66: Yes, but as I said, if it's just in the body, you can't have facets that let you filter on this stuff, and I think everything in #63 is valuable to search on.

Yeah, I agree. So, "final" proposal:

- Development status
  - Under active development
  - Maintenance fixes only
  - No further development
  - Obsolete

- Maintenance status
  - Actively maintained
  - Seeking co-maintainers
  - Seeking new maintainer
  - Abandoned

+1 for @dww's list in #69.

#69 sounds good. I also want to go on record as being super happy to see the word "orthogonal" used several times in this thread in such a short time. :-)

Here's a patch to do most of the work for us automatically. Forgot there was some special-case handling of the maintenance vocab in the project info block, so this patch fixes all that, too. I don't want to commit/deploy this right before going to bed, but I'll do so tomorrow unless there are any compelling objections.

Committed #72, deployed live, ran the update.

I'll see anyone who's interested over at #950972: Use Maintenance & Development status on project browsing pages.

Cheers,
-Derek

p.s. Just committed (but haven't yet deployed) a follow-up fix to only display the warning about an "Unknown" development status on projects that have a CVS directory configured...

Sorry to be a pain, but I'm still not happy with the range of terms.

I'm editing my projects to set the terms up, and I'm faced with a choice between:

- under active development
- maintenance fixes only

The first makes it sound like I'll leap in and supply ponies to users requesting them. The second makes it sound like there's no point in a user contributing a patch for a feature because I won't even bother looking at it. There's ground in between the two!

Nothing concrete, no.

I can tell you what I said above, which is that for my own modules, I tend to think of them as falling into:

- Ongoing development: means this module has a roadmap for future development, I intend to add features to it when I get spare time (!), will review patches for features and bugs.
- Normal maintenance: means I care about this module and I'm trying to stay on top of the issue queue. If a bug is filed, I will look into fixing it myself, though obviously a patch would be nice. Support requests will get at least an initial reply. If you post a feature request, don't expect me to work on it (unless, exceptionally, my curiosity is piqued), but I will review patches for features and when they're ready, commit them and make releases.
- Graveyard maintained / code 'n' run: issue queue is full of tumbleweed, but criticals will get attention. Often in my case these are one-shot modules for a client that have heaps of hardcoded settings but if someone else takes up the baton and writes an admin UI they'd be pretty useful. Usually corresponds to 'co-maintainers needed'.

Obviously that's just my take on my own modules. I think it would be useful to hear from other contrib maintainers...

I'd just like to echo what drumm said in #66. We'll never capture all the nuance of all of this stuff in a few terms. The goal here is not to perfectly have the terms map to every possible maintainer intention/scenario. The goal is to help communicate the basic expectations and make it easy to filter/search by projects matching the kinds of expectations you can handle. I'm hesitant to further complicate the choices here, but I guess if there's 1 additional term that really helps clarify intentions, I'd be open to adding it. But frankly, I think "features + bugs" vs. "just bugs" vs. "not touching the code anymore" pretty much sums up the possible choices for what kind of development a given project is undergoing.

I think it's just the wording. We currently have:

Development status:
- Under active development
- Maintenance fixes only
- No further development
- Obsolete

Compare:

Development status:
- Active
- Passive
- Stopped
- Obsolete

Not really sure what the actual difference between "No further development" and "Obsolete" is. In both cases, it sounds like the code won't be change anymore.

"Obsolete" would be for e.g. functionality moved into core, made redundant by another module or maybe it was based on a 3rd party service that went belly-up - there are lots of possibilities. "No further development" would probably best go hand-in-hand with the maintenance statuses of "Seeking co-maintainer(s)", "Seeking new maintainer" and "Abandoned" in that they have value left but the developer is no longer putting / has time to put effort into it.

Do we need a nice 4x4 grid with different scenarios written out? =)

As an outsider (one of the primary audiences for this stuff) I'd have no idea what "Passive development" means. I'd rather the terms remained a bit more verbose so as to be self-documenting. It'd be nice if they made sense even if they weren't links to handbook pages. ;)

My question is this: Who is applying these terms?

* If they are self-applied, one person's "active" is another person's "passive".
* If they are applied by others, you have a loaded situation. "What do you mean I'm not actively maintaining x?!"

Whatever the answer, these flags then should be identified to the end user. Who's saying that this module is not maintained?

@laura s: the maintainer is selecting these terms herself. if you have a suggestion of how to make that obvious on the project node UI where the terms are displayed (under the "Project information" header), I'm all ears.

> I'd just like to echo what drumm said in #66. We'll never capture all the nuance of all of this stuff in a few terms.

True, but the current list is very limited.

How about we look at it from the point of view of a user investigating a module?

They may want to know:

- will a support request be answered?
- will a feature request be considered?
- will a feature patch be reviewed?
- will a bug report be fixed?
- will a bug patch be applied?
- will a critical bug report be fixed?

Deployed