On Mon, 29 Jun 2009 13:19:18 +0200 Sjors Gielen mailinglist@dazjorz.com wrote:
Ken Sharp wrote:
Dan Kegel wrote:
- Eight days is way too quick to remove an inactive maintainer. Six
months is more like it.
That is far too long. After two weeks there are 100 test results waiting in the queue. Six months wouldn't help the users out at all. Their test results would disappear into a black hole.
But he could be temporarily away. What about sending him a mail after 8 days, sending him an urgent mail after two/three weeks saying "please remove yourself if you know you're not going to handle these" and only remove him a few weeks later. Maintainers are volunteers, they can't be expected to spend *all* their time on appdb, they have time now and then; unless they are, for example, on a holiday.
That would still leave the test results sitting there unprocessed for weeks, which leaves a pretty bad impression on the users who submitted them. Test results for apps without maintainers get processed by the admins within 24 hours.
But you are right about temporary absences. It would be useful if there were some sort of "out of the office" flag that maintainers could check to notify admins that they'll be gone for a time, and we should process the tests reports for their apps.
I also think booting the maintainer on a first offense is a bit extreme. I'd prefer a "three strikes and you're out" approach--the first two times admins have to process a maintainer's tests (after sitting there for a week) they get warnings; the third time, they're removed as maintainer, and not allowed back. But there would need to be an automatic mechanism to keep track of repeat offenders. I'm not sure how difficult that would be.
BTW, nowhere on the maintainer guidelines page does it say that maintainers have to process test reports within a certain amount of time. In fact, nowhere does it say anything about them having to process test reports at all, nor does it say anything about being removed as a maintainer if they fail to fulfill their duties (which are so vague as to be unenforceable anyway). This really needs to be rectified.