Listening to Martin Krafft’s talk at Debconf (related to his PhD) shed some new light on the idea that I expressed last year — I wanted that each maintainer regularly answers a questionnaire so that he has to ask himself whether he does a good enough job with his packages.
When thinking of this idea, I only saw the QA side of ensuring good maintenance on all packages, however I believe that the root problem lies further and this project would not be enough: we are interdependent but we are not equipped to deal with this reality. Martin’s only merit has been to mention that we are interdependent, but it’s worth analyzing a bit.
Our organization is centered around individuals acting as package maintainers, and in theory each package maintainer can work on his corner and all goes well. We know that this model doesn’t hold any more: transitions to testing require coordination of uploads and timely fixes of RC bugs, keeping up with the work frequently requires several volunteers that have to coordinate, etc. More and more of the work requires a level of availability that a single individual can’t offer, yet in our day-to-day work we mainly interact with individuals. Wouldn’t it be better if we could immediately know what we can expect from any Debian developer:
- mean time to reply to Debian mail (reading every day or once a week is not the same);
- amount/periods of time spent on Debian (knowing that they spend up to 4 hours mainly on Saturday can be useful);
- current availability for Debian (if they are currently busy with life, we should be able to know it, if they know when it will end, it would also be good to share);
- best way to get in touch for issues (they might have preference between IRC or mail);
- kind of relationship they have with packages where they are listed in Maintainer/Uploaders (an active maintainer that uses the software daily is not the same than a passive maintainer that only packaged the software because it was a build-dependency for some other software that they care about);
- any other information that the maintainer wants to share (about his habits/constraints/values/goals/whatever).
All this information should be shared by all Debian maintainers (some of it is already available but either not publicly or not in any machine-parseable way) and we should actively use it. Here are some examples of use: for each RC bug report, you could look up if at least one maintainer is available and you could ping him explicitly if needed. When you plan an NMU, you could look up if the maintainer is likely to respond in the next day or not, and possibly adjust the number of days spent in the DELAYED queue. When organizing a large-scale transition, you could extract a list of packages whose maintainers are not available and arrange immediate NMUs.
Furthermore there are many cases where the project’s usual expectation exceed what the maintainer is ready to do. Documenting what part of the job is done (or not) by the maintainer makes it clear for volunteers whether their help is needed and whether they could/would be a better maintainer for a given package.
Designing solutions to all these problems is going to be the scope of the DEP2 that I reserved some time ago. It’s likely to be some sort of dedicated web interface. I would welcome supplementary drivers for this DEP, so if you’re interested, get in touch with me.
My “only merit”, huh? I better work on that… 😉
Anyway, when reading your ideas about a Debian Contributor “time sheet”, I could not help but wonder how regular contributions are. Of course it would be nice if we knew when a Debian contributor is available, and heck, wouldn’t it be nice if we could expect everyone to be available from 9:00 to 18:00, but I doubt this is possible or could possibly reflect reality.
I can give you a rough average of how much time I can spend on Debian every week, but then that’s an average. I can also tell you that I am most active in the early mornings and very little on the weekend, but that doesn’t mean that I will be available every morning, nor that I won’t hop on IRC on a rainy Saturday. My point is that we’re all (hopefully) somewhat spontaneous and our days aren’t routine to the point where free time is always allocated. Mine isn’t, and I wouldn’t want that.
BUt I think it would be great to know how maintainers categorise their own dedication and time availability for the packages they maintain. It’s always questionable how accurate such data would be, but I am tempted to think it’ll be better than what we have now.
Martin, it’s your only merit in this specific story of my life. 🙂 But keep up the good work in general!
I understand that we are not robots and that the data will never be fully accurate, but I believe it would still be useful. DEP2 should precise the kind of accuracy that we’re looking for. At the very least, I would like some official management of the available/busy/not reachable status information so that we don’t wait on people that simply won’t respond currently. For the rest, it’s not about ensuring that someone is available but to have an idea of of how to best interact with him.
Meta-data like this would only be useful if constantly updated, at which point it becomes part of the burden that makes those DD’s who are already struggling to find time start consider retirement.
I had a huge amount of time for Debian and Emdebian until very recently and through ill health I have had to cut that by more than half. When that happened, I was completely unable to even correspond with the majority of people in Debian – I could just about send an email to debian-private but that was just luck that I was somewhere with an internet connection. It was 4 weeks before I had another chance to send email.
Events happen, things go wrong, things outside Debian and over which we have absolutely no control. Please don’t pressurise DD’s in such situations by making them think that this availability data has to be updated even when it is technically impossible due to lack of access. I felt bad enough at the time without that guilt trip.
None of us can forecast the future, just because I *think* I’ll have 10 hours available next week, does not mean that I can promise to reply to email on a daily or weekly basis. It depends on whether that is a single block of 10 hours or 20 slots of 30 minutes. Some emails can take hours to prepare.
Isn’t this just micro-management by another guise? It’s barely a step from expecting every DD to be on twitter 24/7.
I deliberately dropped off IRC because I was fed up with people pestering me when I was trying to do something else. I don’t want the Project nagging me as well.
A better solution here is more teams where even if one member is unexpectedly unavailable, others can step in. There should be less stress on individuals, not more.
Neil, there are several points in what you say.
I agree that updating this information is small work in itself, it is paperwork. It should still be very small fraction of the time you allocate to Debian, most of it should be filled only once and the rest is about informing people that you’re busy or on vacation (this part we already do via debian-private, it would just be done in another way). I certainly don’t want us to announce every week of much time we’re going to spend on Debian the next week, that’s irrealistic. It’s not about forecasts, it’s about habits you have (if you don’t have any, you can also say so of course).
I agree that sometimes things go wrong and you can’t update your information, it’s no big deal, the lack of updates is useful information in itself and we always have the MIA team for this case. We could also let other DD update it for you once they’ve had news through another channel.
In the end, it’s not micro-management, you manage yourself and nobody else does. The infrastructure is just to share some info with other individuals that might have to interact with you sometimes in the future as part of their Debian work.
More teams is good, but teams are not people, you need to know who in the team is currently available if you really want some quick interaction. Sending a mail to the list does not always work, sometimes everyone believes that someone else will reply…