[development] adoption for 'abandoned' modules?
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
Fewer modules overall, easier for users, and less potential for code
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?
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
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?),
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"
* 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
* 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
* Process for original maintainer to 'get back' module if module is
transferred or shared 'mistakenly'.
Contact from original maintainer to Drupal.org explaining situation
--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.
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