Re: Self-assessment of the quality of the maintenance work
On Sat, 20 Dec 2008, Raphael Hertzog wrote: I would like to formalize the idea a bit more and we could use the DEP process for this. I would be willing to work on the implementation once we agree on the process. It looks like enough people think it might be worth experimenting. Is someone interested to help me drive a DEP process to flesh out the design ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Fri, Jan 23, 2009 at 09:31:02PM +0100, Raphael Hertzog wrote:
It looks like enough people think it might be worth experimenting.
Can you please back this?
I've just re-read about a half of the posts in these thread and most
of them don't like at least some aspects of your proposal.
Don't take me wrong, I don't think that that should inhibit drafting a
DEP and having discussions about your idea elsewhere, it is simply
that I'm surprised by the different perception of the received
feedback between me and you.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Self-assessment of the quality of the maintenance work
On Fri, 23 Jan 2009, Stefano Zacchiroli wrote: On Fri, Jan 23, 2009 at 09:31:02PM +0100, Raphael Hertzog wrote: It looks like enough people think it might be worth experimenting. Can you please back this? I've just re-read about a half of the posts in these thread and most of them don't like at least some aspects of your proposal. But most of them also have discussed ways to solve their concerns and we had some ideas already to overcome those concerns. The goal of the DEP is to collect all the concerns and design the system to avoid as many of the pitfalls as possible. Except Sune, I have not seen strong opposition stating that it's completely unreasonable. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sun, 21 Dec 2008, Mark Brown wrote: On Sat, Dec 20, 2008 at 06:19:26PM +0100, Raphael Hertzog wrote: The collation of all those data will give us a better view on the maintenance status of each package and it could be displayed on the PTS. We could also use those info to direct new contributors to help in existing packages instead of packaging new stuff. What do you think of the idea ? I'm not sure that the e-mail bit of this really adds anything - the I don't understand why you say that: - email is the primary way to get in touch with a maintainer - making sure that the maintainer responds to an email query is the traditional way used by the MIA team/DAM to see if a maintainer is still active - it's also indirectly a way to authenticate him for the web form because we can put a cookie in the link (unfortunately, we don't have any officially endorsed web authentication method that works well to identify debian contributors) information reported is only going to be as good as the people filling it in make it and there's little motiviation to make much effort with the data. Can you expand ? Something that used existing metrics to try to determine if the package was actively maintained before sending the mail might be more useful there and would avoid making work for people who are clearly active. I wish to collect more information than active/not active so I think that the answers of the active ones are as interesting than those of the less-active ones. And as already said, active/not active is really specific to each package and someone with more than a few packages is likely to be active on some packages and less-active on some others. What would you suggest in this case ? The web application side of it does sound like a good idea, though: the existing WNPP has some issues arising from the use of the BTS as the back end (like making sure e-mails get seen by the right people, for example). Indeed, in the long term, I wish we could have a recruiting team that tried to find new maintainers for packages. The goal would be to have the maximum of packages with active maintainers. In the same spirit, it's easier to get a new maintainer rolling while the package still has a passive one that is willing to sponsor and give advice to him. Once it's orphaned, you have to find an interested sponsor and it's not always easy. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
Hi Raphaël, I like your proposal in principle, but I see some problem with group maintenance. While I'm in principle a supporter of group maintenance I do not see how it should work with your proposal. Who in the group will be addressed by your proposal? You are talking about a passive maintainer in the case of the Perl maintainers group. How do you obtain whether a group or a passive maintainer is working? Do you just want to parse the list of Maintainer / Uploaders and leave out generic group addresses? Or how should this work? The problem in non-working teams is that every member trusts all the others and finally nothing will be done in case a problem occures. How do you want to address this problem? BTW, when writing this an idea comes up which might be also able to measure responsiveness of maintainers: How long does it take until a bug deserves at least an answer from one of the maintainers. Most probably this needs some clever interpretation of the answers to a bug. IMHO any bug deserves an answer in a short time span - even the submitter of a wishlist bug deserves a notice if the maintainer thinks that this bug will not fixed in the next couple of monthes and give some reasons why. IMHO bug #432350 is a good example for a non-working team. There is not a single response from team members - but finally the team got new blood now and there is some hope. IMHO this bug report would have deserved a response like: We are not able to fix this problem because we are completely occupied with other tasks. Please help. and setting the help tag. This answer would perhaps have brought the fresh blood the team gets now some monthes earlier. Considering this example - I'm sure there are much more - leads me to the opinion that watching BTS for unanswered bug reports might enable us to detect MIA maintainers. Kind regards Andreas. -- http://fam-tille.de
Re: Self-assessment of the quality of the maintenance work
On Mon, 22 Dec 2008, Andreas Tille wrote: Do you just want to parse the list of Maintainer / Uploaders and leave out generic group addresses? Yes, only real people are important and able to work. :) You are talking about a passive maintainer in the case of the Perl maintainers group. No. I said that some packages can be considered to be well-maintained even if they have only a passive maintainer because the amount of work generated is very low. And I gave the example of a perl module. How do you obtain whether a group or a passive maintainer is working? There's no evaluation at the group level, only individual developers can be evaluated, passive maintainer are no different from any other developers in the way that they are evaluated, just the expectation might be different. Anyway to respond to your question, that's to be defined but a combination of mutiple data is to be expected: - new upstream version available and not packaged since X days - number of open bugreports increasing of X% per month in average over the last 6 months - some metric with lintian warnings - standards-version not up-to-date - number of release goals bugs open - any other criteria that might count - number of uploads in the X last months - … Or how should this work? The problem in non-working teams is that every member trusts all the others and finally nothing will be done in case a problem occures. How do you want to address this problem? If everybody answers that they are not responsible for a given package (ie they state that they are backups maintainers), you know that you have a problem with this package because nobody feels responsible for it. At least with this system the problem is known, how to fix it is another matter of course. Considering this example - I'm sure there are much more - leads me to the opinion that watching BTS for unanswered bug reports might enable us to detect MIA maintainers. It's certainly one possible metric but not the easiest to retrieve and far from something that can be generalized. Not all packages are equal and you can't set the same expectations in terms of BTS answers for everybody. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
Hello, The basic idea is quite simple, we want to ensure that each package is maintained as well as possible and for this we need to ensure that it has one or more active maintainer(s). What do you think of the idea ? I think this is a great idea and should be implemented. Jeremiah -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Mon, Dec 22, 2008 at 09:25:32AM +0100, Raphael Hertzog wrote: On Sun, 21 Dec 2008, Mark Brown wrote: I'm not sure that the e-mail bit of this really adds anything - the I don't understand why you say that: - email is the primary way to get in touch with a maintainer - making sure that the maintainer responds to an email query is the traditional way used by the MIA team/DAM to see if a maintainer is still active Right, but on the other hand the MIA and DAM teams tend to be careful to try to avoid making work for people who are clearly actively doing things. My concern with sending out the e-mails to all and sundry is that it's taking things too far in the initial stages of the process and that adding that further down the line when the system is established would be a better approach. information reported is only going to be as good as the people filling it in make it and there's little motiviation to make much effort with the data. Can you expand ? The data being entered on the form has pretty much no utility for the person filling in the form which means that a lot of people are just going to fill it in as quickly as possible. This will degrade the quality of information produced, particularly when people are resubmitting the second time around (since repetitiveness reduces the amount of thought required). If people don't feel that there's some importance beyond the act of filling in the form then there's a real possibility that many of them are only going to care about the fact the form has been submitted, not what was on it. More targetted, human generated, requests tend not to have this problem so much since the human part of it provides a cue that the data will be used. That may change once there is a reasonable data set and people come up with good ways to use it which show the value of the information being collected but before that has happened it might be safer to start off with a combination of opt in and more targetted mails. This would avoid starting off by irritating people and should help increase the quality of the data for people to analyse. Speaking personally, if I saw such an e-mail there would be a very good chance that I would just delete it without even filling in the form (or probably even reading the mail properly) since it sounds very much like the sort of questions you get in the why do you participate in free software things that social science students are fond of sending round from time to time. I've seen enough of those for mass-mailed surveys to tend to loose my attention rapidly. Something that used existing metrics to try to determine if the package was actively maintained before sending the mail might be more useful there and would avoid making work for people who are clearly active. I wish to collect more information than active/not active so I think that the answers of the active ones are as interesting than those of the less-active ones. It's not that much more information than that, really. And as already said, active/not active is really specific to each package and someone with more than a few packages is likely to be active on some packages and less-active on some others. What would you suggest in this case ? I was thinking of per-package metrics here, though there may possibly be some interesting cross-package metrics which could provide a good guess about the role someone has on each of their packages. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On 20/12/08 at 18:19 +0100, Raphael Hertzog wrote: Hello, I would like to propose something new that would partially supersede the work done by the MIA team and that would also generate new information somehow related to the topic of WNPP. The basic idea is quite simple, we want to ensure that each package is maintained as well as possible and for this we need to ensure that it has one or more active maintainer(s). Hence every X months, each maintainer receives a mail with a link to a web form where he'll have a list of all the packages that he maintains/co-maintains and for each package he has to answer several questions that explain his relationship with the package (the answer are preseeded with the values he selected the previous time so that he can quickly skim over it if nothing has changed): - what kind of maintainer he is - active (responding quickly, forwarding bugs, …) - passive (responds only to major problems) - backup (not doing anything unless solicited) - if the package needs an active maintainer or not (most perl modules are well maintained with a single passive maintainer) - if the package needs help from another volunteer We could integrate various heuristics/data in the process to help the maintainer recognize that he's (not) keeping up and that he needs help or maybe that he's no more active but only passive. If the maintainer doesn't respond, he automatically enters the MIA process and the package is quickly marked as needing help/attention from someone else. The collation of all those data will give us a better view on the maintenance status of each package and it could be displayed on the PTS. We could also use those info to direct new contributors to help in existing packages instead of packaging new stuff. What do you think of the idea ? I don't really like it. Your main goal is to improve our detection of packages that need attention. (it would also help detect inactive maintainers, but even that has the goal of improving the quality of our packages). However, I have the impression that currently, we do pretty well at detecting packages that need attention. What we don't do very well, is taking care of those: we have tons of orphaned packages, and tons of packages that need investigation according to Bapase. So that's probably where we should put more work. Also, I think that the usefulness/noise ratio of your system would be quite low. Maybe such a system could still be useful, but it would be needed to filter the list of packages first. There are tons of packages where there's no doubt that they receive enough attention. -- | Lucas Nussbaum | lu...@lucas-nussbaum.net http://www.lucas-nussbaum.net/ | | jabber: lu...@nussbaum.fr GPG: 1024D/023B3F4F | -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Mon, 22 Dec 2008, Mark Brown wrote: things. My concern with sending out the e-mails to all and sundry is that it's taking things too far in the initial stages of the process and that adding that further down the line when the system is established would be a better approach. Ok. Looks like a fairly reasonable request. information reported is only going to be as good as the people filling it in make it and there's little motiviation to make much effort with the data. Can you expand ? The data being entered on the form has pretty much no utility for the person filling in the form which means that a lot of people are just going to fill it in as quickly as possible. Ok, I understand this point but note that your remark applies equally to the creation of the Description: field in debian/control. Yet we have people who care about good description fields. It's a matter of understanding why it's important to do the work (like you suggest later in your mail). This will degrade the quality of information produced, particularly when people are resubmitting the second time around (since repetitiveness reduces the amount of thought required). If people don't feel that there's some importance beyond the act of filling in the form then there's a real possibility that many of them are only going to care about the fact the form has been submitted, not what was on it. More targetted, human generated, requests tend not to have this problem so much since the human part of it provides a cue that the data will be used. Yes, that's true. That's why every time that the user has to submit it again, the form must be presented in a way so that it highlights the cases where the expectations (as defined by his own self-assessment) are not met in practice. Ideally those differences should even be reported in the mail itself (it would help reduce the impression of a useless automatic mail). Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Mon, 22 Dec 2008, Lucas Nussbaum wrote: Your main goal is to improve our detection of packages that need attention. (it would also help detect inactive maintainers, but even that has the goal of improving the quality of our packages). Not only. One of the aspects that I like most in this proposal is that it will be possible to have a list of packages that are not orphaned but that have only a passive maintainer who would be happy to find an active maintainer (and possibly sponsor him if needed). For new maintainers, it would contain more interesting packages than the set of orphaned ones (where important packages get adopted fast and that tend to contain mostly marginal software). I know that it is similar to the RFH/RFA that we have in WNPP but that system is IMO not working because: - too few maintainers are using it, thus looking for packages to help there is not really interesting (not enough choice) and thus the system is not very efficient - the maintainers need to be aware of the system and must convince himself that it will be useful to make the effort to report the bug against WNPP Of course, those problems will only be solved for the new system if participation is very large (and hence will probably be better only if participation gets mandatory at some later point). The second point is that such a system should bring maintainers to give away their packages as soon as they realize that they are not active anymore (hopefully no later than 6 months after they stopped taking care of it) and not years later (after the package accumulated bugs, and that it got detected by our current rules). However, I have the impression that currently, we do pretty well at detecting packages that need attention. I don't know if we do well, but I agree that it's easy to identify a large set of packages that need attention and that we most certainly have a backlog to start with… What we don't do very well, is taking care of those: we have tons of orphaned packages, and tons of packages that need investigation according to Bapase. So that's probably where we should put more work. Would some part of the need investigation be solved/solvable with some specific questions added to the form that I try to describe ? Otherwise I agree that we should do better at handling those already identified but except for the recruiting team I have no specific idea to help solve this problem. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
Raphael Hertzog hert...@debian.org writes: I know that it is similar to the RFH/RFA that we have in WNPP but that system is IMO not working because: - too few maintainers are using it, thus looking for packages to help there is not really interesting (not enough choice) and thus the system is not very efficient Well, I, for one, have been discouraged from using the RFH system because I don't think I've ever seen any package come *off* of that list. At some level, just about every package in Debian could use help, in the sense that there's always a to-do list and things that haven't been done yet. It feels like this is what the RFH system is currently devolving into, and when large packages have long-term listings there that don't seem likely to ever go away (and which aren't closed when people join the package teams), I have to wonder if it's really accomplishing anything to add to the list. If it were more dynamic and pointed only to packages with critical shortfalls of resources, I think it would work better. RFA I think does work reasonably well. It just has a higher bar. (And it makes sense to me that things would sit in RFA for some time, since often they're listed there because the DD is no longer personally using the package, often for reasons that mean the package is being used less in general.) -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sat, 20 Dec 2008, Enrico Zini wrote: I quite liked the idea of allowing to set such attributes in the control file because, rather than looking like someone putting their nose on how one maintains packages, they are a handy way to document the maintainer's intentions with the package, providing a service to the maintainer: for example, if I mark a package dead-upstream, then people posting wishlist bugs will hopefully take that into account (and reportbug may remind them about it). People adopting a fringe package for heavy production will have been warned and hopefully will do some extra testing, and so on. Both approachs are probably complementary. Using the control file works fine for things which are specific to the package (dead-upstream) or when there is only one maintainer but when you have a package with multiple maintainers, the active/passive classification is really different for each maintainer. The goal is also to discover cases where we have several co-maintainers where everyone thinks that they are backup maintainers and that it's the duty of someone else to handle this bug. For this, debian/control is not suited at all. And when creating the debtags data, we need to have some rules to merge the views of each co-maintainer in a global coherent view. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sun, 21 Dec 2008, Filippo Giunchedi wrote: I like the general idea, here are a few points/questions: Have a procedure to not receive the mail in the future (perhaps making it possible to (manually, via email?) re-enable at some later time) The best results are achieved if everyone participates so I'd rather find ways to make it painless for everybody first. But knowing how diverse the opinions are, we will probably have to do something like this. In that case, if someone opts-out, it might be interesting to have heuristics to replace the missing data. If the maintainer doesn't respond, he automatically enters the MIA process and the package is quickly marked as needing help/attention from someone else. How long is the time span after the maintainer enters MIA? Perhaps after X unanswered mails? No idea, that's up for discussions. The system would try to not send emails when someone is in VAC. But yes, “a ping every X weeks and if Y pings are left unanswered then he enters the MIA process” could be ok. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sat, 20 Dec 2008, Russ Allbery wrote: Raphael Hertzog hert...@debian.org writes: The basic idea is quite simple, we want to ensure that each package is maintained as well as possible and for this we need to ensure that it has one or more active maintainer(s). Hence every X months, each maintainer receives a mail with a link to a web form where he'll have a list of all the packages that he maintains/co-maintains and for each package he has to answer several questions that explain his relationship with the package (the answer are preseeded with the values he selected the previous time so that he can quickly skim over it if nothing has changed): That's going to be a lot of fairly mindless paperwork for someone who's the member of a large, active team with a lot of packages. For example, I feel for Gregor Herrmann (253 packages) or Gunnar Wolf (187 packages) having to fill this out for every package they uploaded for pkg-perl. Agreed. I'm not sure what's the best way to handle this. Maybe the form should make it easy to give the same answers to all packages that are maintained by a given team ? We could use easily identify the team by finding out an email that matches @lists\. in either the Maintainer: field or the Uploaders: field. Another answer might be to hide all packages which are fine under the current norms (to be defined: no bugs (or less than X bugs), no lintian errors, …) and use some predefined answers in those cases. The form would focus on packages with problems (or that are getting worse over time). Do you see any other approach ? Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sat, Dec 20, 2008 at 06:19:26PM +0100, Raphael Hertzog wrote:
I would like to propose something new that would partially supersede
the work done by the MIA team and that would also generate new
information somehow related to the topic of WNPP.
Well, I like the principle (who having a feeling of QA problems in
Debian wouldn't?) but I don't think the mechanism you are proposing
would work at all.
- the first time you'll ask people to fill the forms the mechanism
will suck up a lot of time to everybody. As the benefits for the
filler are not clear (at least not yet) they wouldn't be motivated
to spend the required time
- the fear of getting bothered/pinged periodically via mail is
something which is real among maintainers (remember all the fuss
about DDPO via email? I think the fuss was inappropriate, but still
it was there). This is another ingredient which will contribute bad
marketing to such an initiative.
Unfortunately, I have the feeling that your proposal will work
properly only if an amount of people close to everybody will take part
in it, otherwise it won't be that useful, because most likely only the
active people will take part in it.
Alternative proposal
If the goal is cleaning up the maintainer/uploaders field I've an
alternative proposal which is, IMO of course, more likely to work
properly and do not require active work from the single maintainer. It
boils down to automatically filling the Uploaders field on the basis
of debian/changelog. (The idea is shamelessly copied from the GNOME
team.)
That would be an inherent, always up to date wrt contributions measure
of who worked on a given package recently. The outcome wouldn't be as
fine-grained as yours (passive / backup / ...), but it would be
automated.
What it would be needed (warning: braindump ahead) is:
- implementing it in some low-level tool, because we can't rely on
CDBS class, it should (if agreed upon via something like a DEP) be
fully automatica
- decide the thresholds for being listed in Uploaders
Orthogonal problems
---
After writing the above, I realized there are two orthogonal
problems. One is cleaning up Uploaders, which I believe would be
addressed by the above approach.
The other is identifying de facto orphaned packages. For that you can
indeed ping, but it can be way easier than what you propose. Just send
an email (with no web link whatsover), at most once per year, and only
mentioning packages which have not been touched by the maintainer for
more than 1 year. The reply can be formatted enabling the maintainer
to mention which packages she still maintains.
No reply = orphaned package.
Actually, your proposal mentions MIA, I don't get why. A maintainer
can have de facto orphaned some packages and still be active on
others.
Cheers.
--
Stefano Zacchiroli -o- PhD in Computer Science \ PostDoc @ Univ. Paris 7
z...@{upsilon.cc,pps.jussieu.fr,debian.org} -- http://upsilon.cc/zack/
Dietro un grande uomo c'è ..| . |. Et ne m'en veux pas si je te tutoie
sempre uno zaino ...| ..: | Je dis tu à tous ceux que j'aime
signature.asc
Description: Digital signature
Re: Self-assessment of the quality of the maintenance work
Raphael Hertzog hert...@debian.org writes: Agreed. I'm not sure what's the best way to handle this. Maybe the form should make it easy to give the same answers to all packages that are maintained by a given team ? We could use easily identify the team by finding out an email that matches @lists\. in either the Maintainer: field or the Uploaders: field. That would do it for me. That's a good idea. I think if I could set a default answer for all packages in a given team and then go back and tweak the ones that are special for some reason, it would make that case relatively fast. I'm not sure that lack of response should be taken as a definitive indication of anything, but I'm not sure that it would need to be to still gather useful information from this sort of thing. I'd be happy to fill out such a survey every six months or so, and I'd be curious to see the results. Maybe, similar to low-threshold-NMU, it would work best if it started as an opt-in system? -- Russ Allbery (r...@debian.org) http://www.eyrie.org/~eagle/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sun, 21 Dec 2008 11:28:17 +0100, Raphael Hertzog wrote:
That's going to be a lot of fairly mindless paperwork for someone who's
the member of a large, active team with a lot of packages.
Agreed. I'm not sure what's the best way to handle this.
Maybe the form should make it easy to give the same answers to all
packages that are maintained by a given team ?
An option for setting values for all packages would be nice (and
maybe not only for team-maintained packages).
Another answer might be to hide all packages which are fine under the
current norms (to be defined: no bugs (or less than X bugs), no lintian
errors, ???) and use some predefined answers in those cases. The form would
focus on packages with problems (or that are getting worse over time).
I think hiding kind of defeats the purpose of the idea :)
But setting sane default values based on some metrics would make it
easier indeed.
Cheers,
gregor
--
.''`. Home: http://info.comodo.priv.at/{,blog/} / GPG Key ID: 0x00F3CFE4
: :' : Debian GNU/Linux user, admin, developer - http://www.debian.org/
`. `' Member of VIBE!AT, SPI Inc., fellow of FSFE | http://got.to/quote/
`-NP: Paul Simon: The Obvious Child
signature.asc
Description: Digital signature
Re: Self-assessment of the quality of the maintenance work
On Sun, Dec 21, 2008 at 11:16:28AM +0100, Raphael Hertzog wrote: The best results are achieved if everyone participates so I'd rather find ways to make it painless for everybody first. But knowing how diverse the opinions are, we will probably have to do something like this. There's no way this is going to be painless for everyone: you're going to be sending mails that make work for people that require them to do something that they wouldn't otherwise have to do. -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sat, Dec 20, 2008 at 06:19:26PM +0100, Raphael Hertzog wrote: The collation of all those data will give us a better view on the maintenance status of each package and it could be displayed on the PTS. We could also use those info to direct new contributors to help in existing packages instead of packaging new stuff. What do you think of the idea ? I'm not sure that the e-mail bit of this really adds anything - the information reported is only going to be as good as the people filling it in make it and there's little motiviation to make much effort with the data. Something that used existing metrics to try to determine if the package was actively maintained before sending the mail might be more useful there and would avoid making work for people who are clearly active. The web application side of it does sound like a good idea, though: the existing WNPP has some issues arising from the use of the BTS as the back end (like making sure e-mails get seen by the right people, for example). -- You grabbed my hand and we fell into it, like a daydream - or a fever. -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Self-assessment of the quality of the maintenance work
Hello, I would like to propose something new that would partially supersede the work done by the MIA team and that would also generate new information somehow related to the topic of WNPP. The basic idea is quite simple, we want to ensure that each package is maintained as well as possible and for this we need to ensure that it has one or more active maintainer(s). Hence every X months, each maintainer receives a mail with a link to a web form where he'll have a list of all the packages that he maintains/co-maintains and for each package he has to answer several questions that explain his relationship with the package (the answer are preseeded with the values he selected the previous time so that he can quickly skim over it if nothing has changed): - what kind of maintainer he is - active (responding quickly, forwarding bugs, …) - passive (responds only to major problems) - backup (not doing anything unless solicited) - if the package needs an active maintainer or not (most perl modules are well maintained with a single passive maintainer) - if the package needs help from another volunteer We could integrate various heuristics/data in the process to help the maintainer recognize that he's (not) keeping up and that he needs help or maybe that he's no more active but only passive. If the maintainer doesn't respond, he automatically enters the MIA process and the package is quickly marked as needing help/attention from someone else. The collation of all those data will give us a better view on the maintenance status of each package and it could be displayed on the PTS. We could also use those info to direct new contributors to help in existing packages instead of packaging new stuff. What do you think of the idea ? I would like to formalize the idea a bit more and we could use the DEP process for this. I would be willing to work on the implementation once we agree on the process. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sat, 20 Dec 2008, Sune Vuorela wrote: On 2008-12-20, Raphael Hertzog hert...@debian.org wrote: maintainer receives a mail with a link to a web form where he'll have a list of all the packages that he maintains/co-maintains and for each package he has to answer several questions that explain his relationship with the package (the answer are preseeded with the values he selected the previous time so that he can quickly skim over it if nothing has changed): - what kind of maintainer he is - active (responding quickly, forwarding bugs, ???) - passive (responds only to major problems) - backup (not doing anything unless solicited) - if the package needs an active maintainer or not (most perl modules are well maintained with a single passive maintainer) - if the package needs help from another volunteer We could integrate various heuristics/data in the process to help the maintainer recognize that he's (not) keeping up and that he needs help or maybe that he's no more active but only passive. If the maintainer doesn't respond, he automatically enters the MIA process and the package is quickly marked as needing help/attention from someone else. I'd rather spend my time on fixing my packages than on filling web forms with bureaucratic bullshit. Thanks for your constructive comments… and the nice vocabulary. It might take some time the first time that you submit but it's good to step back a few seconds to think about the maintenance status of the packages that you maintain (do I need help? do I maintain it actively or would I let the package go if someone more involved in the upstream project showed up?). Later on the bureaucratic work takes a couple of seconds, not much more than the time you spent to write you nice reply. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
Responding to myself to share other details related to this idea that I didn't want to include in the initial mail. On Sat, 20 Dec 2008, Raphael Hertzog wrote: The basic idea is quite simple, we want to ensure that each package is maintained as well as possible and for this we need to ensure that it has one or more active maintainer(s). Hence every X months, each maintainer receives a mail with a link to a web form where he'll have a list of all the packages that he maintains/co-maintains and for each package he has to answer several questions that explain his relationship with the package (the answer are preseeded with the values he selected the previous time so that he can quickly skim over it if nothing has changed): One of the side-effects is that we would encourage maintainers to remove themselves from the Uploaders field if they are no more maintaining the package. - what kind of maintainer he is - active (responding quickly, forwarding bugs, …) - passive (responds only to major problems) - backup (not doing anything unless solicited) - if the package needs an active maintainer or not (most perl modules are well maintained with a single passive maintainer) - if the package needs help from another volunteer If you find the idea interesting, I'd appreciate your input on the different categorization of maintenance type that we should propose and what are the main characteristics of each category. I have been rather superficial in the description above but it matches at least part of my view on maintenance work: there are packages that I care a lot about and where I will do my best and there are packages that I packaged only because they are dependencies of other stuff that I needed and where I'm not following upstream developement at all. I tend to do the minimum for those (handle only RC-bugs in a timely fashion, package new upstream versions often several months after its publication, …) and I would be glad to let someone more involved take over those packages. The collation of all those data will give us a better view on the maintenance status of each package and it could be displayed on the PTS. It could also be used to create a new maintenance facet in debtags. maint::orphaned, maint::active, maint::passive, maint::help-needed, maint::need-active-maint Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sat, 20 Dec 2008, Luk Claes wrote: I don't think sending active maintainers questionaires is very helpful. I don't think the active/not active criteria is so easy to find out. I can be active on dpkg while being not active on my others packages. At some point I must recognize that I've lost interest in the other packages and retire from the co-maintainers and/or update my status. But I certainly agree that we should strive to make this as painless as possible in general and we can certainly find ways to attract the attention of each maintainer only when we have hints that something is going wrong. Though I'm not a priori against such a self-assessment, I think it should at least only be sent to people when needed (not in case of VAC, not when clearly active on all packages, not when all packages are orphaned ...). Agreed, the purpose of the DEP would be to spell out all the cases and precise how the thing should behave in every situation. Cheers, -- Raphaël Hertzog Le best-seller français mis à jour pour Debian Etch : http://www.ouaza.com/livre/admin-debian/ -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
* Raphael Hertzog: - what kind of maintainer he is - active (responding quickly, forwarding bugs, …) - passive (responds only to major problems) - backup (not doing anything unless solicited) - if the package needs an active maintainer or not (most perl modules are well maintained with a single passive maintainer) - if the package needs help from another volunteer I'd rather see ways to commit to commit to certain packages and kinds of maintenance. For instance, I will provide security support for etch and lenny for exim4. This would be some form of self-assessment, and we could cross-correlate open bug reports with the self-assessment to check if it is realistic. -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Re: Self-assessment of the quality of the maintenance work
On Sat, Dec 20, 2008 at 07:32:01PM +0100, Raphael Hertzog wrote: It could also be used to create a new maintenance facet in debtags. maint::orphaned, maint::active, maint::passive, maint::help-needed, maint::need-active-maint I've been thinking about such a maintenance facet for quite a while, and indeed it's one of the first thing that came to my mind when you posted about the self-assessment. I have been pondering about some self-assessment as well, to feed such a facet. My idea was mainly to allow maintainers to write in debian/control whether they consider the package to be a fringe package, or dead-upstream. active/passive maintenance is an interesting concept that could be documented in the same place as well. help-needed and need-active-maint probably wouldn't fit there, as it isn't worth to make a new upload just to document that; also, they're likely to be attributes on which the view of users or other developers is probably more accurate than that of the maintainer. I quite liked the idea of allowing to set such attributes in the control file because, rather than looking like someone putting their nose on how one maintains packages, they are a handy way to document the maintainer's intentions with the package, providing a service to the maintainer: for example, if I mark a package dead-upstream, then people posting wishlist bugs will hopefully take that into account (and reportbug may remind them about it). People adopting a fringe package for heavy production will have been warned and hopefully will do some extra testing, and so on. How about something like this? It has the advantage of being fully voluntary, of being a possible value added for the developer, and of not feeling like you're busy doing your best and then someone shows up and instead of offering help asks you to stop and spend time assessing yourself. Ciao, Enrico -- GPG key: 1024D/797EBFAB 2000-12-05 Enrico Zini enr...@debian.org signature.asc Description: Digital signature
Re: Self-assessment of the quality of the maintenance work
Hi, On Sat, Dec 20, 2008 at 06:19:26PM +0100, Raphael Hertzog wrote: The basic idea is quite simple, we want to ensure that each package is maintained as well as possible and for this we need to ensure that it has one or more active maintainer(s). Hence every X months, each maintainer receives a mail with a link to a web form where he'll have a list of all the packages that he maintains/co-maintains and for each package he has to answer several questions that explain his relationship with the package (the answer are preseeded with the values he selected the previous time so that he can quickly skim over it if nothing has changed): - what kind of maintainer he is - active (responding quickly, forwarding bugs, …) - passive (responds only to major problems) - backup (not doing anything unless solicited) - if the package needs an active maintainer or not (most perl modules are well maintained with a single passive maintainer) - if the package needs help from another volunteer I like the general idea, here are a few points/questions: Have a procedure to not receive the mail in the future (perhaps making it possible to (manually, via email?) re-enable at some later time) We could integrate various heuristics/data in the process to help the maintainer recognize that he's (not) keeping up and that he needs help or maybe that he's no more active but only passive. If the maintainer doesn't respond, he automatically enters the MIA process and the package is quickly marked as needing help/attention from someone else. How long is the time span after the maintainer enters MIA? Perhaps after X unanswered mails? Also, it would help to clarify that enters the MIA process is not the same as the maintainer is MIA which might be confusing. filippo -- Filippo Giunchedi - http://esaurito.net PGP key: 0x6B79D401 random quote follows: Endian little hate we -- Anonymous (?) -- To UNSUBSCRIBE, email to debian-qa-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
