Re: [development] adoption for 'abandoned' modules?
Re the issue of co-maintainers: 1) Asking at the time a person is first applying for cvs access is way too early. What if they are just getting ready to submit a module that actually never even goes anywhere? We don't need a co-maintainer for that. We need co-maintainers much later in the process -- after a module has been out and become adopted and established and important enough that it needs some looking after. 2) One feature for the project system that would help this process along would be a way to show a link to co-maintainer(s) on the project page. Currently you see a link only to the primary maintainer. You can look at commits and try to guess who a co-maintainer might be, but you might get that completely wrong. If we had a link there: a) You would know there is a co-maintainer b) You would have an easy way to get in contact with him/her This would be useful not just to site maintainers, but to anyone who is having a problem and not getting a response from the primary maintainer. 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. Karen
1) Asking at the time a person is first applying for cvs access is way too early. What if they are just getting ready to submit a module that actually never even goes anywhere? We don't need a co-maintainer for that. We need co-maintainers much later in the process -- after a module has been out and become adopted and established and important enough that it needs some looking after.
Sorry, that's a mis-understanding. I want the time as a CVS admin so I can sort the incoming, queued and pending tables by date. Currently they are a jumble for us CVS admins and we can't sort the table by date because there is no date. Storing the date/time of application has nothing to do with the thread. None of you people actually see that. I only mentioned it to demo that I will be working on the code soon so now is a good time to get feature requests in. --Andy
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.
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.
Another possible option is something that is used at my university for mailing list owners. Once a year I get an e-mail saying that I have to "renew" it (i.e. basically, acknowledge that I still exist and have a need for it) within some window of time or it gets disabled. I'm obviously not suggesting projects be removed or disabled, but such an infrequent maintainer ping like this could be helpful. I.e. once a year you get an e-mail saying, click this link within the next 2 months to confirm your desire to continue as owner of the following modules. The destination page could have checkboxes for the projects you currently maintain. Anything you don't renew goes up for adoption. One attractive feature of this approach is that it ensures that a maintainer is actually still reachable at their contact address. -- Ray Zimmerman Senior Research Associate 428-B Phillips Hall, Cornell University, Ithaca, NY 14853 phone: (607) 255-9645
On 1/19/07, Ray Zimmerman <rz10@cornell.edu> wrote:
Another possible option is something that is used at my university for mailing list owners. Once a year I get an e-mail saying that I have to "renew" it (i.e. basically, acknowledge that I still exist and have a need for it) within some window of time or it gets disabled.
I'm obviously not suggesting projects be removed or disabled, but such an infrequent maintainer ping like this could be helpful. I.e. once a year you get an e-mail saying, click this link within the next 2 months to confirm your desire to continue as owner of the following modules. The destination page could have checkboxes for the projects you currently maintain. Anything you don't renew goes up for adoption.
One attractive feature of this approach is that it ensures that a maintainer is actually still reachable at their contact address.
I think this is the best idea proposed so far. A regular email ping and a method for maintainers to specifically abandon a module sounds great.
On Jan 19, 2007, at 11:50 AM, andrew morton wrote:
On 1/19/07, Ray Zimmerman <rz10@cornell.edu> wrote:
Another possible option is something that is used at my university for mailing list owners. Once a year I get an e-mail saying that I have to "renew" it (i.e. basically, acknowledge that I still exist and have a need for it) within some window of time or it gets disabled.
I think this is the best idea proposed so far. A regular email ping and a method for maintainers to specifically abandon a module sounds great.
This is already occurring in the form of Drupal releases. Allie Micka pajunas interactive, inc. http://www.pajunas.com scalable web hosting and open source strategies
On 1/19/07, Allie Micka <allie@pajunas.com> wrote:
I think this is the best idea proposed so far. A regular email ping and a method for maintainers to specifically abandon a module sounds great.
This is already occurring in the form of Drupal releases.
I'm not sure quite what you mean. By specifically abandon, I meant that a module maintainer could flag a module as abandoned more programatic manner than just adding "I'm no longer updating this module" in the project body. Perhaps just a taxonomy for projects so the maintainer could select the status. andrew
On 19-Jan-07, at 12:59 PM, andrew morton wrote:
I'm not sure quite what you mean. By specifically abandon, I meant that a module maintainer could flag a module as abandoned more programatic manner than just adding "I'm no longer updating this module" in the project body. Perhaps just a taxonomy for projects so the maintainer could select the status.
I have a feature request for this here: http://drupal.org/node/99466 Any site maintainer want to take a look and see what you think?
Another possible option is something that is used at my university for mailing list owners. Once a year I get an e-mail saying that I have to "renew" it (i.e. basically, acknowledge that I still exist and have a need for it) within some window of time or it gets disabled.
As above, there were plans to introduce a cron job into the CVS module that "disabled" cvs accounts (and an appropriate e-mail was to be sent) that hadn't witnessed any activity for X months. Any projects that were associated with disabled accounts were to be deemed abandoned. This tackles the issue more from a "target absconding maintainers" rather than "target unmaintained projects" perspective. This also keeps things uncomplicated and minimises drupal.org related code in the module. -K
On Jan 19, 2007, at 12:52 PM, Karthik wrote:
As above, there were plans to introduce a cron job into the CVS module that "disabled" cvs accounts (and an appropriate e-mail was to be sent) that hadn't witnessed any activity for X months. Any projects that were associated with disabled accounts were to be deemed abandoned. This tackles the issue more from a "target absconding maintainers" rather than "target unmaintained projects" perspective. This also keeps things uncomplicated and minimises drupal.org related code in the module.
CVS commits don't provide a good measure of a developer's commitment to a project. Developers who contribute well-written modules may not need to make CVS commits on a regular basis. I know a couple of developers who lost their ability to maintain projects because their CVS accounts were arbitrarily (or mistakenly) disabled.
+1 on the adoption page. I'm in the process of learning to be a better drupal dev. I'm active in the drupal-dojo, been reading the dev list for over a year now, and am active on IRC. That said, I haven't the faintest idea on where to start, and being able to 'adopt' something simple would be a great way to wet my feet before diving in and trying to maintain a module I started from scratch. +1 on co-maintainers for the same reason. The more 'paths to enlightenment' that can be offered to new devs, the less workload you all will have 6 months - 1 year from now (well, maybe ;)
participants (9)
-
AjK -
Allie Micka -
andrew morton -
Angela Byron -
Darren Oh -
Karen Stevenson -
Karthik -
Ray Zimmerman -
Sam Tresler