Re: [development] adoption for 'abandoned' modules?
-----Original Message----- From: development-bounces@drupal.org [mailto:development- bounces@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.
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@drupal.org [mailto:development- bounces@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.
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
On Jan 19, 2007, at 10:31 PM, Steven Peck wrote:
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?
Of course not. We put the project up for adoption so someone who is willing to be contacted can become the maintainer. The original developer retains full access to the project. The new maintainer should have access to the contact forms of all the developers for the project in order to contact them when necessary.
On 20-Jan-07, at 9:58 PM, Darren Oh wrote:
On Jan 19, 2007, at 10:31 PM, Steven Peck wrote:
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?
Of course not. We put the project up for adoption so someone who is willing to be contacted can become the maintainer. The original developer retains full access to the project. The new maintainer should have access to the contact forms of all the developers for the project in order to contact them when necessary.
Sorry, but I totally disagree with this. Drupal.org provides a built-in means of contacting maintainers to get support: issues tagged "support request" ... responsible maintainers will be watching their issue queues and responding to these. A huge added advantage is that other people can search the issue queue for their same issue. E-mail, on the other hand, goes into a black hole, benefits no one apart from the support requester, and results in the maintainer having to repeat themselves over and over again. We shouldn't be encouraging people to e-mail maintainers. We should be encouraging people to use issue queues, because that's where community development and support happens. I specifically disabled my contact form for this reason. I know other maintainers have as well. -Angie
Angela Byron wrote:
Drupal.org provides a built-in means of contacting maintainers to get support: issues tagged "support request" ... responsible maintainers will be watching their issue queues and responding to these. A huge added advantage is that other people can search the issue queue for their same issue. E-mail, on the other hand, goes into a black hole, benefits no one apart from the support requester, and results in the maintainer having to repeat themselves over and over again.
We shouldn't be encouraging people to e-mail maintainers. We should be encouraging people to use issue queues, because that's where community development and support happens. I specifically disabled my contact form for this reason. I know other maintainers have as well.
+1. The issue queue is an excellent support medium that is currently lacking some amount of visibility and is a little troublesome for newer users because it has a lot of things that aren't relevant to support requests that, with some coding work, could be eliminated. My ideal is to be able to treat support requests like a forum attached to the project.
On Jan 20, 2007, at 10:31 PM, Angela Byron wrote:
We shouldn't be encouraging people to e-mail maintainers. We should be encouraging people to use issue queues, because that's where community development and support happens. I specifically disabled my contact form for this reason. I know other maintainers have as well.
The point is for one person with an active interest in the module to be able to check with developers to see why they are not responding to the issue queue. I've been told several times to check with the module maintainer when a module I was interested seemed to be abandoned. Two modules have been turned over to me when I reported that the maintainer's contact form was disabled. It would have been nice to have been able to ask the former maintainers if they intended to be actively involved in future development.
On Jan 20, 2007, at 10:31 PM, Angela Byron wrote:
Sorry, but I totally disagree with this.
Drupal.org provides a built-in means of contacting maintainers to get support: issues tagged "support request" ... responsible maintainers will be watching their issue queues and responding to these.
Angela Byron is an exceptionally responsive developer. Not all responsible maintainers can constantly monitor their issue queues.
On 21-Jan-07, at 1:02 AM, Darren Oh wrote:
On Jan 20, 2007, at 10:31 PM, Angela Byron wrote:
Sorry, but I totally disagree with this.
Drupal.org provides a built-in means of contacting maintainers to get support: issues tagged "support request" ... responsible maintainers will be watching their issue queues and responding to these.
Angela Byron is an exceptionally responsive developer. Not all responsible maintainers can constantly monitor their issue queues.
I'm not talking about constant monitoring. But issue queues are the main mechanism where features and bug reports are posted. So yes, in order to be a responsible maintainer you _do_ need to be keeping an eye on your queues, or else turn on the feature in project module to get mails sent to them when isues are posted. I'm actually a horribly responsive developer when it comes to my contrib modules. ;) But the second someone posts a, "Hey, looking for a co-maintainer?" issue, I would either promote them, or else respond, "No, I'm just really hitting a busy patch, but if you would care to test some of these patches in the queue and mark them appropriately, I'd really appreciate it." However, if the issue instead languishes for 3 weeks with no response, it would be very easy to make the case that "This maintainer is not taking care of their issue queue," and have one of the Drupal admins make the switch. OTOH, if you send me an e-mail, lots of things could've happened to it: it could've been caught by a spam filter, it could've been an old e-mail address that doesn't get a response anymore, it could've been sent to one of my mail addresses that get filtered as mailing list mails that I only occasionally check, etc. etc. Furthermore, an issue is far preferable, because it could become a single request could grow into a central rallying point for several people who have an interest around a module to collaborate together to take care of it. I've seen this happen with modules from time to time, such as buddylist and privatemsg. So yes, down with e-mail, up with issue queues. :) -Angie
On Jan 21, 2007, at 1:09 PM, Angela Byron wrote:
So yes, down with e-mail, up with issue queues. :)
to add a few more reasons to angie's excellent post: - email makes it impossible for anyone else to help (either co- maintainers or non-maintainers who already know the answer). - you can't track/change the status of an email - you can't assign email to someone else (other than forwarding it) - you can't re-classify an email into a more appropriate issue queue ... so yes, down with email, up with issue queues. ;) cheers, -derek
Darren Oh wrote:
Angela Byron is an exceptionally responsive developer. Not all responsible maintainers can constantly monitor their issue queues.
I disagree. Keeping up with the issue queue is the most important part of being a responsibile maintainer. An inability to keep up with the issue queue is the first sign of the maintainer not being responsible; whehther or not this is due to time constraints or other reasons is immaterial.
On 22 Jan 2007, at 17:24, Earl Miles wrote:
Darren Oh wrote:
Angela Byron is an exceptionally responsive developer. Not all responsible maintainers can constantly monitor their issue queues.
I disagree. Keeping up with the issue queue is the most important part of being a responsibile maintainer. An inability to keep up with the issue queue is the first sign of the maintainer not being responsible; whehther or not this is due to time constraints or other reasons is immaterial.
I have to agree with Earl. Keeping on top of your issue queue is important. -- Dries Buytaert :: http://www.buytaert.net/
participants (7)
-
Angela Byron -
Darren Oh -
Derek Wright -
Dries Buytaert -
Earl Miles -
Jill Elaine -
Steven Peck