Stories
Slash Boxes
Comments
NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.

All the Perl that's Practical to Extract and Report

use Perl Log In

Log In

[ Create a new account ]

Alias (5735)

Alias
  (email not shown publicly)
http://ali.as/

Journal of Alias (5735)

Sunday July 12, 2009
11:02 PM

Is it right to auto-notify authors, if there aren't many?

[ #39271 ]

Dear LazyWeb.

The FAIL 100 list has been working reasonably well, but one crucial downside at the moment is the need for people to actively monitor it (both those that are aware that it exists, and those that don't know it exists).

While I certainly agree that it is a bad idea to spam authors in general (I'm certainly for opt-in CPAN Testers summaries and emails) does this still hold true when you are identifying only a small number of authors.

Would it be ok to auto-email the Top 10 positions on the FAIL 100 list, say, each week to let them know their module is considered to be important to fix quickly?

What if it's just the first time it appears, and on subsequent sequential appearances we don't email you.

What if it was the top 5? Or the top 2? Or top 1? Or only if you met a certain threshhold of FAILure score? Or it was at a wider interval, say, monthly?

When is it ok for a whole-CPAN process to judge that an author needs to be nudged?

The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
 Full
 Abbreviated
 Hidden
More | Login | Reply
Loading... please wait.
  • FAIL100 is a really nice tool to indicate that something might be important but it's not suited to prove that something is important.

    • Is there any way at all that is suitable to proving that something is important?

      • Is this a rhetorical question? Human judgement of course, on a case by case basis. When you send the automatically generated emails all to yourself and read them and do the best of all possible efforts to judge the situation and only then forward those manually that have passed all possible filters. I mean permanently adjusting filters according to gained insights during the review process. Then you will still find people who disagree with you but that's just fair because you have done your very best effor

  • Unhelpful answer: if you personally write each email, and it's not automated, then I don't think of it as spam, because there's a built in scale limit.

    Helpful answer: CPAN Testers has a preferences website: https://prefs.cpantesters.org/ [cpantesters.org] I would suggest talking to Barbie about how you can hook into that and find author contact preferences. Since FAIL 100 is really CPAN Testers data weighted by a dependency graph, it would make sense to use the same set of contact preferences.

    Bonus: authors who complained

    • And if I hardcoded in the scale limit to the automated system? (being, say, only 10 modules)

  • Especially if we're talking about only a few. Emailing 100 people that their distros are immensely used and still fail quite a lot sounds reasonable, but I think it's more than fair to email 10 people.

    FAIL 100 can really help us focus efforts on bug resolution. Imagine a group in the community (composed of the community) that helps weave out bugs in CPAN/DarkPAN/whatever. Now, if they could only know which distros need the most hand... oh wait! Now they do!

    At any case, how hard can it be to email back and s

    • At any case, how hard can it be to email back....

      You don't get to decide that for other people receiving automated bulk mail.

      • True. I don't get to decide it, but I can reply to Adam's request for anyone's opinion, and per my opinion, I think that receiving one little measly email that you can just press the "Reply" button and say "no more for me" isn't the worst thing.

        I thought we're talking about some heavy-weight programmers (in a matter of skill, not body weight) that can write extremely useful modules. I would like to think that they can read an email and that they probably have some program that has a "reply" function or can

        • There is no general purpose agreement that by uploading something to PAUSE you grant permission for anyone with spare time and the desire to analyze what you uploaded has the right to send you automated e-mail as he or she sees fit.

          That fails the categorical imperative test. You may not be a Kantian (I'm not), but it's still a useful gauge for behavior.

          • There is no general purpose agreement that by uploading something to PAUSE you grant permission for anyone with spare time and the desire to analyze what you uploaded has the right to send you automated e-mail as he or she sees fit.

            Can we agree that uploading to CPAN is an act of publishing, ie. that it means that the author expects other people to take notice of the existence of the code, at a bare minimum? Can we further agree that reasonable people who upload code to CPAN will expect that other people m

            • [You] could upload your code with a disclaimer saying that no one should use it and you should not expected to conform to the common implications of the act of uploading code to the CPAN.

              There are two problems with this reasoning.

              First, I've chosen a license which already disclaims any express or implied warranties of merchantability and fitness for a particular purpose. (The Artistic License in /usr/share/apps/LICENSES/ARTISTIC misspells "merchantability".)

              Second, we're discussing a so-called "common im

              • We’re discussing a so-called “common implication” that came into existence only recently.

                That is news to me. You mean until only recently, the CPAN was regarded as a place were you upload backup copies of your code for your personal use?

                I think the idea of the CPAN from the very beginning was that it was a place where you could publish code for others if you felt like it. And I dare say it would be a sensible assumption to make that every author is perfectly well aware of and shares this

                • You mean until only recently, the CPAN was regarded as a place were you upload backup copies of your code for your personal use?

                  The context of this discussion is automated bulk emails regarding a specific external analysis of CPAN uploads which did not exist in 2000 when I uploaded my first distribution to the PAUSE. How do you generalize from the fact that in no way could I have agreed to a very specific case of receiving automated bulk email from a tool that would not exist for eight years that I objec

                  • Just don’t tell me that I agreed to them implicitly in 2000

                    You never put a “please don’t use this” sign on your code (which is not the same as an “I’m not making any promises about what the code does” sign AKA the licence). By the act of uploading itself, you implicitly declared that your intent was in fact the opposite of such a sign. If it were forbidden to attempt a reasonable non-literal interpretation of the extent of what such an intent might allow for, and i

                    • You never put a “please don’t use this” sign on your code...

                      Why do you persist in attempting to equate allowing the use of code I've uploaded under a DFSG-compatible license with implicit permission to send me unsolicited, automated email?

                      One important difference is that your use of code I have written consumes no resources on systems under my control. Unsolicted, automated email consumes resources on my mail server. This is not the only difference, but it is a stark difference.

                      By the

                    • I take that (implied subjunctive) litotes as agreement that it is robot-generated mail.

                      I was going to propose a thought experiment here, but as per below I’m not going to bother.

                      Why do you persist in attempting to equate allowing the use of code I’ve uploaded under a DFSG-compatible license with implicit permission to send me unsolicited, automated email?

                      I’m not. The situation has far more qualifying circumstances than your narrow (in my view) portrayal would suggest, and either I am una

          • There is likewise no agreement that by uploading something to PAUSE you grant permission for non-automated emails either. Or to judge your code, or to index it for searching, or to do anything else.

            I don't have the fancy book learning, so I had to look up most of your second paragraph on wikipedia, but I think it's total hyperbole to suggest my proposal imposes some kind of categorical imperative.

            I've suggest nothing of the kind.

            • The idea of the Categorical Imperative is essentially to guide your actions by asking the question, “would/could I want the action I’m going to take next to be raised to a universal law?” (ie. everyone has to do it all the time). So the question in your case would be, would/could you want everyone to constantly invent email notification services such as the one you are about to build? As in, how would that affect you, your inbox, and your email address?

              And in this case, if these notificati

  • send out a message to the top 100 cpan module authors, explaining that this module is used by a number of other cpan modules. ask if they'll opt in to receive error reports via email. if they do not opt in, they may track the reports via the web page at the link provided.

    also, you may suggest that authors (especially of these modules) write and release a release policy and a support policy to clarify what (if any) structure there is to the module release process and what (if any) support is available by t

  • "If they have agreed to receive this communication" is the right one, and the one that the answer is "yes" to.

    -- Douglas Hunter

  • I'd say make it monthly. Especially if their module isn't failing, but you didn't make it clear if you meant always or just when it was failing.
    --
    --fREW
    http://blog.afoolishmanifesto.com
  • It's fine to email the top few every so often, but only *ever* email a given author *once*. The first email is enough to notify them of the existence of the service and I'd leave it up to them to follow it themselves afterwards.
    • And yet if the entire purpose of the service is to notify you of situations you may have missed because you weren't paying attention.

      Should we expect authors to be continuously monitoring the monitoring system?

      For typical monitoring systems like Nagios, the reverse is the normal situation.

      • Maybe a per-author RSS feed would be useful then. That way, my computer keeps an eye on it for me, and emails me any changes, but it's my choice to receive those emails so you won't get whining little gits calling you a spammer.