[development] adoption for 'abandoned' modules?

Jill Elaine jillsemail at bendbroadband.com
Sat Jan 20 19:37:37 UTC 2007


Phew! Great discussion on this topic. Thank you.

To summarize the email discussion so far...
(Also, please see this discussion: http://drupal.org/node/99466 )

ADOPTION FOR 'ABANDONED' MODULES
--------------------------------
The discussion pulls in inter-twined subjects...

* What are we trying to accomplish and why?
	Discourage duplication of effort
	More likely to have 'complete' modules with good documentation and help 
files
	Fewer modules overall, easier for users, and less potential for code 
conflicts
	Co-maintenance or adoption of existing module makes it easier for 
newbies to 'get feet wet'
	
* How to 'prevent problems' as well as 'deal with problems'
* What information to collect (if any) and the work required to collect 
and maintain it? Who will do the work?
* What are the potential issues?


SUGGESTED PROCESSES:

VOLUNTARY TRANSFER OR SHARE MAINTAINER ROLE
-------------------------------------------
--first, do what we can to avoid abandoned modules

* Encourage responsible maintainers. How?
	Culture vs Rules?
	'Best practices' documentation (put on Drupal web?), explain why it's 
important
	Teach by example, mailing lists, discussions
	Explain what happens if 'best practices' is not followed (without 
threats or guilt, eh?)

* Maintainer designates co-maintainer(s). Where?
	-- from this page: http://drupal.org/node/63634
"If there is a team of multiple developers working on the same project, 
you can grant CVS access to other users and give them the ability to to 
commit and tag files in your project's directory. You do this by using 
the CVS access tab on your project's home page."
	A co-maintainer is designated when the maintainer gives CVS access.
	-- Add another option?
	Put field on the 'project form'
	May designate more than one co-maintainer
	Maintainer may edit form as needed
	-- How does a co-maintainer remove him/herself from co-maintainer status?

* Process for maintainers to pro-actively release their modules for 
adoption or request co-maintainer.
	Field(s) on 'project form': adopt/co-maintain, date, comment
	Documentation explaining terminology and process
	View to display modules 'up for adoption' (the Orphanage?) or 
'searching for co-maintainer', links on appropriate pages (What pages?), 
mailing lists?


PROVIDE METHODS TO CONTACT AND INTERACT WITH MAINTAINERS
--------------------------------------------------------
--avenues of communication

* 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.
	Person joins developer mailing list and posts interest in maintaining 
module (then what happens 'behind the scenes?)
	Apply for a CVS account and explain situation (then what happens 
'behind the scenes?)
	If maintainers don't respond, then what? Explain to form users what to 
do if maintainer doesn't respond -> the next step: email Drupal admins.

* Put names of any co-maintainers on module main page
	
* Collect secondary email address from maintainers

* Ping maintainers email address(es) every X months
	Request response from maintainer or some consequence?
	Make note of lack of response(s): may be used to assess whether 
maintainers module(s) is/are 'adoptable'

* Provide documentation on User Account > Contact form about appropriate 
(and inappropriate) use of the form and link to "How to submit an issue" 
documentation

* Maintainers can disable their Contact form, but Drupal admins can 
still contact maintainers


ADMINISTRATIVE TRANSFER OR SHARE OF MAINTAINER ROLE
---------------------------------------------------
-- Methods to keep modules alive when the maintainer is not active or 
pro-active

* Process to determine if module is 'abandoned'
	Critical bugs in issues queue but no response from maintainer
	Patches waiting to be committed with no response from maintainer
	Someone files "Request to be added as co-maintainer" but has received 
no response from maintainer for X amount of time
	Note: CVS commits are not necessarily a good way to tell if module is 
abandoned as some modules may rarely need updates.
	Modules that aren't ported to the newer version of drupal will become 
abandoned.
	
* Process for original maintainer to 'get back' module if module is 
transferred or shared 'mistakenly'.
	Contact from original maintainer to Drupal.org explaining situation


POTENTIAL ISSUES
----------------
--Remember that nothing works perfectly for every situation: there will 
always be issues no matter which path is taken.

* Mistakenly forcing an adoption of a module. CVS protects original code 
though, so maintainer can recover code if needed.

* Drupal wants to support and encourage developers. Adding rules and 
regulations, 'or else' clauses may discourage developers.

* Drupal doesn't want to overburden maintainers by asking them to 
respond to all pings, emails, issues in queues, etc. Need to find a 
balance between maintainers' busy lives and Drupal requests for input.


Any comments are appreciated.
Thank you
Jill Elaine


Steven Peck wrote:
> 
>> -----Original Message-----
>> From: development-bounces at drupal.org [mailto:development-
>> bounces at drupal.org] On Behalf Of Darren Oh
>> Subject: Re: [development] adoption for 'abandoned' modules?
>>
>> On Jan 19, 2007, at 11:41 AM, Karen Stevenson wrote:
>>
>>> Also, I would require that anyone listed as a maintainer must have
>>> their contact form enabled, otherwise they get de-listed and their
>>> project gets put up for adoption on a special adoption page. OK,
>>> maybe that last bit is a little strong :-) but whether or not there
>>> is a way to contact the maintainer should be another factor in our
>>> 'gold star' system.
>> Not too strong at all. If a person wants to control a project but
>> doesn't want to be contacted, he should maintain the project on his
>> own computer, not on Drupal. Let people who disable their contact
>> forms have CVS access, but find someone who will actually maintain a
>> project to be the maintainer.
>>
> 
> Um, and those that out of frustration with people using the contact
> forum to mail them directly for support instead of using the issue
> queue?  Do we disable their contrib. modules?  Site admins can use the
> contact form.  We have the email information and can email directly.
> 
> Not to put a fine point on it but I know several active module
> contributors who have disabled their contact modules because of this
> sort of abuse.
> 
> 
> 
> 


More information about the development mailing list