wow, great summary elaine, thanks! one general comment about something not included in the summary: co- maintainers are per-project, not per-CVS account, so it makes no sense to ask about co-maintainers stuff when you're applying for a CVS account. i "own" 6 projects, and the co-maintainers for each would-be/are wildly different for each project. all this talk of functionality for co-maintainers belongs in the realm of project nodes, not the CVS account application form. and now, some replies to the summary (mostly, links to the appropriate issues if people want to actually see any of this get done). FYI: i'm going to be AWOL for basically all of february, and have limited time before then, so others will mostly have to "carry the torch" on these efforts until march... On Jan 20, 2007, at 11:37 AM, Jill Elaine wrote:
* Maintainer designates co-maintainer(s). Where?
http://drupal.org/node/69556 http://drupal.org/node/102532
-- How does a co-maintainer remove him/herself from co-maintainer status?
good question. ;) i never considered this case. http://drupal.org/node/111216
* Process for maintainers to pro-actively release their modules for adoption or request co-maintainer.
* Provide a method by which someone can request to be added as a co- maintainer for a module. On the modules main page, under the Development section (at the bottom of the page), add a "Request to be added as a co-maintainer" -> links to a form similar to the "Report a new bug" form, with documentation of process, implications, and responsibilities. Form submits to the maintainer, even if contact form is set to disabled.
seems like a lot of work for practically no gain. a) use the contact tab b) if disabled, create a task issue about it in the issue queue c) if the owner is totally unresponsive, contact the drupal.org CVS admins
* Put names of any co-maintainers on module main page
http://drupal.org/node/69556 http://drupal.org/node/102532 plus "Developers" link: http://drupal.org/project/developers/3281
* Collect secondary email address from maintainers
-> won't fix. ;) seems unnecessary, see above.
* Ping maintainers email address(es) every X months
-> won't fix. ;) i think this would be annoying, and it's a lot of work for IMHO little gain. if there's outcry, and others a) strongly desire this and b) provide the patches, i might grudgingly review, test, commit, and install them, but don't hold your breath. i'd rather see effort put into the other metrics folks have discussed, since those would be handy for everyone to see, too: http://drupal.org/node/79550 having a field in there "hasn't replied to annoying automated ping in X months" wouldn't necessarily tell me much about how responsible this maintainer is. for all i know, their spam filter is eating the spammy pings. ;)
* Provide documentation on User Account > Contact form about appropriate (and inappropriate) use of the form and link to "How to submit an issue" documentation
sure. we should also encourage and facilitate greater use of "support" issues, too: http://drupal.org/node/101292 on a related topic, i'd love to see the site-wide contact tab be able to generate issues, instead of just sending email: http://drupal.org/node/108710 cheers, -derek