[development] adoption for 'abandoned' modules?

Derek Wright drupal at dwwright.net
Sat Jan 20 20:13:46 UTC 2007

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?


> 	-- How does a co-maintainer remove him/herself from co-maintainer  
> status?

good question. ;) i never considered this case.

> * 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  

> * Put names of any co-maintainers on module main page

plus "Developers" link:

> * 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:


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:

on a related topic, i'd love to see the site-wide contact tab be able  
to generate issues, instead of just sending email:


More information about the development mailing list