adoption for 'abandoned' modules?
Hello Coders, Jeff Eaton's post requesting permission to add himself to the CVS access list for an neglected module brings up the topic of the proper procedure for adoption of modules that have been neglected or abandoned. From this list, I gather that a user can essentially 'take over' a neglected module...or add themselves as a maintainer...by applying for a CVS account and explaining the situation. The documented procedure to update a module (fix a bug, add a feature) is "open an issue" and "submit a patch". But there is no documentation that explains what to do if good, tested patches are never applied to the module and/or the maintainer cannot be contacted. I am on the documentation list and would like to write up something that explains what to do in this situation. As maintainers of modules, what do you think this procedure should be? For instance, with your module, what would you like to see happen if you were 'run over by a truck' and disappeared from the Drupal world? ** What would be a reasonable set of steps so that your module continued to be maintained? ** What is a reasonable length of time to wait for a response from you? ** Who should be contacted if your profile is set to 'no contact'? ** What else needs to be considered here? Thank you so much for your input. jillelaine
On Thu, 11 Jan 2007 06:48:47 -0800, Jill Elaine <jillsemail@bendbroadband.com> wrote:
As maintainers of modules, what do you think this procedure should be?
For instance, with your module, what would you like to see happen if you were 'run over by a truck' and disappeared from the Drupal world? ** What would be a reasonable set of steps so that your module continued to be maintained?
Try to get a hold of me via my contact tab, this list, and/or #Drupal. (Some busy maintainers may mention that they're disappearing for a while but will be back in IRC, and someone may remember that.) Some module readme files also contain contact info that can be used.
** What is a reasonable length of time to wait for a response from you?
Most contact attempts can probably be replied to within a week. I think a month is a not-unreasonable amount of time before someone can be considered "potentially dead".
** Who should be contacted if your profile is set to 'no contact'?
Site admins can contact someone even if they're contact tab is off. That said, I personally think it's irresponsible to have the contact tab off if you are actively maintaining a module.
** What else needs to be considered here?
What lack of contact is considered dead? No contact at all? Just no issue queue progress? What's the difference between vanishing and just vanishing from the issue queue for that module, but not others? Or not from working on core? What about temporary adoption if someone is going to be away for several months for some reason (long vacation, military service, etc.)? --Larry Garfield
Personally, I think that modules should have deputy maintainers or co-maintainers. This should be done by module maintainers just by talking to the other people interested in their work and selecting one to have "emergency" CVS access. Most of my modules have a clear 2nd (and sometimes 3rd) in line. I'll review the rest and find more people for the rest. -Robert Larry Garfield wrote:
On Thu, 11 Jan 2007 06:48:47 -0800, Jill Elaine <jillsemail@bendbroadband.com> wrote:
As maintainers of modules, what do you think this procedure should be?
For instance, with your module, what would you like to see happen if you were 'run over by a truck' and disappeared from the Drupal world? ** What would be a reasonable set of steps so that your module continued to be maintained?
Try to get a hold of me via my contact tab, this list, and/or #Drupal. (Some busy maintainers may mention that they're disappearing for a while but will be back in IRC, and someone may remember that.) Some module readme files also contain contact info that can be used.
** What is a reasonable length of time to wait for a response from you?
Most contact attempts can probably be replied to within a week. I think a month is a not-unreasonable amount of time before someone can be considered "potentially dead".
** Who should be contacted if your profile is set to 'no contact'?
Site admins can contact someone even if they're contact tab is off. That said, I personally think it's irresponsible to have the contact tab off if you are actively maintaining a module.
** What else needs to be considered here?
What lack of contact is considered dead? No contact at all? Just no issue queue progress? What's the difference between vanishing and just vanishing from the issue queue for that module, but not others? Or not from working on core? What about temporary adoption if someone is going to be away for several months for some reason (long vacation, military service, etc.)?
--Larry Garfield
On 1/11/07, Robert Douglass <rob@robshouse.net> wrote:
Personally, I think that modules should have deputy maintainers or co-maintainers. This should be done by module maintainers just by talking to the other people interested in their work and selecting one to have "emergency" CVS access. Most of my modules have a clear 2nd (and sometimes 3rd) in line. I'll review the rest and find more people for the rest.
+1...I don't think it's too onerous of a recommendation to have a 2nd person with CVS commit access. Might not necessarily happen, but perhaps when we get some more time we can institute a review process that scans for inactive (i.e. no commits) projects every quarter. Now, disagreement from the community as a whole about the direction of the module....I'll bring THAT up in a separate issue, because I know of one case where it is currently a huge issue. -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On Thu, 11 Jan 2007 12:50:16 -0800, "Boris Mann" <boris@bryght.com> wrote:
On 1/11/07, Robert Douglass <rob@robshouse.net> wrote:
Personally, I think that modules should have deputy maintainers or co-maintainers. This should be done by module maintainers just by talking to the other people interested in their work and selecting one to have "emergency" CVS access. Most of my modules have a clear 2nd (and sometimes 3rd) in line. I'll review the rest and find more people for the rest.
+1...I don't think it's too onerous of a recommendation to have a 2nd person with CVS commit access. Might not necessarily happen, but perhaps when we get some more time we can institute a review process that scans for inactive (i.e. no commits) projects every quarter.
That seems reasonable to me. Just listing it on the "how to maintain a module in CVS" page in the handbook (or whatever it's called) as a recommended good idea would be helpful and not intrusive. (And if anyone wants to be a back-up on nodereview, googlesearch, or menutree, my contact tab is active and awaiting you... <g>) --Larry Garfield
Getting back to this subject, developers here have suggested that contributed modules should, ideally, have a co-maintainer. Others have suggested max-time-limits for 'ignored' modules before they are allowed to be adopted. Since Drupal is all about flexibility, what about gathering a little more info from developers at the time they request a CVS account? The current CVS app is pretty sparse http://drupal.org/cvs-account Here are some suggested additional questions: * Alternate email address in case your main email is broken. This email address would be visible to only Drupal management. * Drupal usernames and email addresses for your module co-maintainers * How should we proceed if someone not on the list above applies to be a co-maintainer for your module? (radio buttons with options) * How should we proceed if we are not able to contact you within (some time limit) and your module needs attention? (radio buttons with options: possible suggestions below) 1. Put your module up for adoption and remove you as maintainer 2. Allow another person to be added as co-maintainer but keep you as maintainer * What should the time limit be? (radio buttons with options) Comments? Suggestions? Thank you! Jill Elaine ---- discussion below as reference ---- Robert Douglass wrote:
Personally, I think that modules should have deputy maintainers or co-maintainers. This should be done by module maintainers just by talking to the other people interested in their work and selecting one to have "emergency" CVS access. Most of my modules have a clear 2nd (and sometimes 3rd) in line. I'll review the rest and find more people for the rest.
Larry Garfield wrote:
On Thu, 11 Jan 2007 06:48:47 -0800, Jill Elaine <jillsemail@bendbroadband.com> wrote:
As maintainers of modules, what do you think this procedure should be?
For instance, with your module, what would you like to see happen if you were 'run over by a truck' and disappeared from the Drupal world? ** What would be a reasonable set of steps so that your module continued to be maintained?
Try to get a hold of me via my contact tab, this list, and/or #Drupal. (Some busy maintainers may mention that they're disappearing for a while but will be back in IRC, and someone may remember that.) Some module readme files also contain contact info that can be used.
** What is a reasonable length of time to wait for a response from you?
Most contact attempts can probably be replied to within a week. I think a month is a not-unreasonable amount of time before someone can be considered "potentially dead".
** Who should be contacted if your profile is set to 'no contact'?
Site admins can contact someone even if they're contact tab is off. That said, I personally think it's irresponsible to have the contact tab off if you are actively maintaining a module.
** What else needs to be considered here?
What lack of contact is considered dead? No contact at all? Just no issue queue progress? What's the difference between vanishing and just vanishing from the issue queue for that module, but not others? Or not from working on core? What about temporary adoption if someone is going to be away for several months for some reason (long vacation, military service, etc.)?
--Larry Garfield
On 1/19/07, Jill Elaine <jillsemail@bendbroadband.com> wrote:
Getting back to this subject, developers here have suggested that contributed modules should, ideally, have a co-maintainer. Others have suggested max-time-limits for 'ignored' modules before they are allowed to be adopted.
Since Drupal is all about flexibility, what about gathering a little more info from developers at the time they request a CVS account?
The current CVS app is pretty sparse http://drupal.org/cvs-account Here are some suggested additional questions:
<snip> Lots of good stuff. Making the form uber complicated makes us do lots of work in coding (and potentially storing) that information. Let's take a bunch of that stuff and create a second textarea, suggesting that that information get included. Co-maintainer information in particular is a good idea....but I think that is already stored in the project / CVS module. So...good instructions there on adding A field with an alternate email address is probably the other bit we could get as structured data. The project module has an email address field that we could use for this?
Comments? Suggestions?
Gerhard/infrastructure: could we run info that shows us which modules haven't had a commit in 3 months? Trimming and announcing stale modules is something else we can do. Thanks, Jill! -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
On Friday 19 January 2007 07:39, Boris Mann wrote:
Gerhard/infrastructure: could we run info that shows us which modules haven't had a commit in 3 months? Trimming and announcing stale modules is something else we can do.
I think three months is a little short. There are many modules that don't need a whole lot of modification, and if the release cycles are 6-12 months, it would be easy for a module that is maintained to get incorrectly flagged. -- Jason Flatt http://www.oadaeh.net/ Father of Six: http://www.flattfamily.com/ (Joseph, 13; Cramer, 11; Travis, 9; Angela; Harry, 5; and William, 12:04 am, 12-29-2005) Linux User: http://www.sourcemage.org/ Drupal Fanatic: http://drupal.org/
On Jan 19, 2007, at 10:45 AM, Jason Flatt wrote:
There are many modules that don't need a whole lot of modification, and if the release cycles are 6-12 months, it would be easy for a module that is maintained to get incorrectly flagged.
In that case, we should add the following two conditions to determine whether a module is being maintained: 1) Are there active issues more than three months old, and if so, 2) has the maintainer responded to any issues within the last three months?
I agree, no issues = no problems. Give that guy a gold star. -----Original Message----- From: development-bounces@drupal.org [mailto:development-bounces@drupal.org] On Behalf Of Darren Oh Sent: Friday, January 19, 2007 11:03 AM To: development@drupal.org Subject: Re: [development] adoption for 'abandoned' modules? On Jan 19, 2007, at 10:45 AM, Jason Flatt wrote:
There are many modules that don't need a whole lot of modification, and if the release cycles are 6-12 months, it would be easy for a module that is maintained to get incorrectly flagged.
In that case, we should add the following two conditions to determine whether a module is being maintained: 1) Are there active issues more than three months old, and if so, 2) has the maintainer responded to any issues within the last three months? -- No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.432 / Virus Database: 268.17.0/639 - Release Date: 1/18/2007 6:47 PM
As I read the follow-on suggestions for how to detect abandoned modules it strikes me that the structured data initially proposed at the top of this thread makes sense to collect. One of the suggested fields described a module specific inactivity window. I maintain a relatively backwater module, Wishlist. With the exception of last December when once person entered ten or so issues, it goes months without updates or issues as the module is not super complicated. I pretty much touch when Drupal core goes through a rev. Commit and issue inactivity does not imply abandoned in cases like mine. What is the opposition to asking maintainers a few questions about how to contact them in the event that their module is perceived as abandoned and asking for some general 'timeout' values? This would be information that only the d.o admins would see, correct? Collect it as part of the project form so that the maintainers could return to edit over time as the module matures. I'm not suggesting that this be added to project module either - a side module that uses form_alter on the project module's entry screen and stores the data in a dedicated table would keep this nicely separated. Scott Darren Oh wrote:
On Jan 19, 2007, at 10:45 AM, Jason Flatt wrote:
There are many modules that don't need a whole lot of modification, and if the release cycles are 6-12 months, it would be easy for a module that is maintained to get incorrectly flagged.
In that case, we should add the following two conditions to determine whether a module is being maintained: 1) Are there active issues more than three months old, and if so, 2) has the maintainer responded to any issues within the last three months?
Gerhard/infrastructure: could we run info that shows us which modules haven't had a commit in 3 months? Trimming and announcing stale modules is something else we can do.
Some modules may never get "touched" because they just don't need it. What's more important is the number of outstanding issues marked "bug" and how old they are. That's a better indication of how neglected a project is over when was the last commit made. Moving on to Jill's comments, here's mine. 1. In the last patch I did for the cvs.module I improved the admin interface a little. However, what I really wanted was an application timestamp (yes, that's missing!). I intend to supply Derek/Zen a patch for this once the D5 dust has settled, so there's an opportunity for people to chip-in and that CVS request form. 2. Currently it says "Motivation message" and not many people realize that many of these messages read "I want to give back to this kick-ass system". Not very useful in helping to make a decision and almost always leads to a protracted email discussion to get what the applicant is really offering. I'd actually like to see the application form ask for something more formal/detailed. Ideas? 3. The idea of a co-maintainer is a good one and we should update the handbook with a "best practices" section on being a responsible project maintainer. There's a very good handbook section for CVS and maybe this should live there. Also, I see a lot of links to Dries article about being a responsible maintainer. Those words ought to be on d.o somewhere to (aka "best practices guide"). As a side note on this, I recently tried to encourage an (obviously overworked) maintainer to take on co-maintainer and that met with resistance. Why? because the maintainer used the module a lot on his own sites and therefore didn't want a stranger dabbling in the code base (and that was after me explaining that 1 cvs protects you and 2 they won't be strangers for long, unless they cock-up ;) 4. I think offering maintainers some choice as to how long we should wait after they've been buried (after being hit by that truck) is a bad idea and just state "if your bug issue queue goes un-maintained for x weeks without input we reserve the right to appoint a co-maintainer whose offering help". The co-maintainer can then apply at a later stage to take over proper if the original maintainer doesn't return. That's a judgement that's made later by d.o admins. But, appointing a co-maintainer really can't do that much damage, as said, cvs protects you. I think the concept of having lots of options that people can select at application time (or after the fact on a project itself) isn't too good an idea. Follow the guidelines and best practice (to be written) and that'll go along way to straighten out some of these issues. --Andy
On 1/19/07, Jason Flatt <drupal@oadaeh.net> wrote:
On Friday 19 January 2007 07:39, Boris Mann wrote:
Gerhard/infrastructure: could we run info that shows us which modules haven't had a commit in 3 months? Trimming and announcing stale modules is something else we can do.
I think three months is a little short. There are many modules that don't need a whole lot of modification, and if the release cycles are 6-12 months, it would be easy for a module that is maintained to get incorrectly flagged.
I'm not suggesting direct action. I suspect 3 months is a good check to follow up with those module owners and/or have human review. At 6 months with no action, I'm thinking it's definitely abandoned.... -- Boris Mann Vancouver 778-896-2747 San Francisco 415-367-3595 Skype borismann http://www.bryght.com
participants (9)
-
AjK -
Boris Mann -
Darren Oh -
Jason Flatt -
Jill Elaine -
Larry Garfield -
Robert Douglass -
Scott McLewin -
Walt Daniels