Automatically degrade maintenance and development status of projects over time

Documentation of the terms is at https://www.drupal.org/node/1066982 →

Maintenance status

• Actively maintained “actively monitors its issue queue”
• Minimally maintained “no fast response is guaranteed”
• Unsupported “no longer being developed”
• algorithms shouldn’t look for maintainers
• algorithms shouldn’t look for maintainers

Development status

• Under active development “New features are still being added”
• Maintenance fixes only “considered feature complete”
• No further development “no longer developed at all”
• algorithms can’t determine deprecation

Things we can measure

• Last commit / dev release update
• Last issue update, either by a maintainer or anyone
• Last tagged release

Correlation between statuses

Number of projects with both terms.

SELECT td_maint.name, sum(td_dev.tid = 9988) 'Under active development', sum(td_dev.tid = 13030) 'Maintenance fixes only', sum(td_dev.tid = 16538) 'No further development' FROM node n INNER JOIN taxonomy_index ti_maint ON ti_maint.nid = n.nid INNER JOIN taxonomy_term_data td_maint ON td_maint.tid = ti_maint.tid AND td_maint.vid = 44 AND td_maint.tid IN (13028,19370,13032) INNER JOIN taxonomy_index ti_dev ON ti_dev.nid = n.nid INNER JOIN taxonomy_term_data td_dev ON td_dev.tid = ti_dev.tid AND td_dev.vid = 46 GROUP BY td_maint.tid ORDER BY td_maint.weight;

Last commit

SELECT td.name, count(1) Total, sum(vo.last_commit > unix_timestamp() - 60*60*24*7*24) '<24wk', sum(vo.last_commit > unix_timestamp() - 60*60*24*7*12) '<12wk', sum(vo.last_commit > unix_timestamp() - 60*60*24*7*4) '<4wk' FROM node n INNER JOIN taxonomy_index ti ON ti.nid = n.nid INNER JOIN taxonomy_term_data td ON td.tid = ti.tid AND td.vid = 44 INNER JOIN versioncontrol_project_projects vpp ON vpp.nid = n.nid LEFT JOIN (SELECT repo_id, max(committer_date) last_commit FROM versioncontrol_operations GROUP BY repo_id) vo ON vo.repo_id = vpp.repo_id GROUP BY td.tid ORDER BY td.weight;

Last issue comment

SELECT td.name, count(1) Total, sum(i.last_issue > unix_timestamp() - 60*60*24*7*24) '<24wk', sum(i.last_issue > unix_timestamp() - 60*60*24*7*12) '<12wk', sum(i.last_issue > unix_timestamp() - 60*60*24*7*4) '<4wk' FROM node n INNER JOIN taxonomy_index ti ON ti.nid = n.nid INNER JOIN taxonomy_term_data td ON td.tid = ti.tid AND td.vid = 44 LEFT JOIN (SELECT fp.field_project_target_id, max(n.changed) last_issue FROM node n INNER JOIN field_data_field_project fp ON fp.entity_id = n.nid GROUP BY fp.field_project_target_id) i ON i.field_project_target_id = n.nid GROUP BY td.tid ORDER BY td.weight;

Correlation between statuses, projects used on >500 sites

Add INNER JOIN project_usage_week_project u ON u.nid = n.nid AND u.timestamp = 1491696000 AND u.count >= 500 to queries.

Last commit, >500 sites

Last issue comment, >500 sites

Original issue summary

Coming from the somehow similar issue #1130786: Mark all releases below 6.x as unsupported → .

...perhaps we should also somehow mark projects with one or more of the bellow criteria as abandoned/obsolete:

- haven't had a commit for more than say... 2 years.
- their issue queue is inactive for more than say... 1 year.
- they have no 6/7/8 release branches.
- they have low or 0 usage stats.

If they actually are active, then I am pretty sure that one of the maintainers will step up and edit the project's status to reflect reality (we can mail them upon auto-flagging their project, so they will be notified for the change). If not that, then perhaps someone will step up and apply to take over the project someday. Till any of the above happens, I think it is pretty safe to consider such projects obsolete and mark them as such.

PS: I happened to be browsing around and came across http://drupal.org/project/flexinode and noticed the above, so I use that as an example case.