Re: Post-install tests demo at the qa hackathon \o/

[Salve J Nilsen]

Lars Dɪᴇᴄᴋᴏᴡ 迪拉斯 said:


This is great news, I know a few people who wanted this for a long time. I'm 
not coming for this hackathon, so please publish slides and discussion notes 
afterwards.


We didn't do the presentation, but if you're interested in looking at what we 
prepared anyway, have a look at


 



On the scale between proof-of-concept and production-ready, where does your 
code fall?


It's a proof-of-concept, with still some details to flesh out, including 
taking into account the points that were raised in Lancaster. You should be 
able to download it and give it a try right now though. The code is useful 
enough for simple testing. :)




So far, have any considerations been made for packaging, and if yes,
how does it compare with the established Ruby → RPM conventions?



This page says "Paste not found".



Will the code the merged into main M::B? If not, can it be renamed
to ::InstallTests for better discoverability?


I came from Lancaster with the impression that this was something many wanted 
to have into M::B. We're aiming for that. Schwern was also positive to have 
something like this implemented in EU::MM too. But in any case, ::InstallTests 
is probably a good namechange. :)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Perl QA Hackathon 2013 / 2014 transition

[Salve J Nilsen]

Philippe Bruhat (BooK) said:


Hi,

As the main organizer of the next Perl QA Hackathon in Lyon (the venue is 
here: http://goo.gl/maps/mXo15), I would like to collect some feedback on 
the hackathon that we just came back from, in Lancaster.


Great! ^^


I would like to collect your impressions about what worked and what 
didn't, what was missing, what you want for next year (including dates, 
but know it's going to be a Friday-Sunday hackathon). You can reply in 
public or in private. I already wrote down all the things I liked from 
this year, as the team has set the bar quite high already. :-)


Here's my public feedback.

I've been to two QA hackathons, and this one was by far the best one! :)

Here are the good bits (please keep):

 + I loved the food
 + The fact that so many came
 + The discussions and stories and gossip :)
 + Having a working wireless network
 + The consensus sessions
 + Lancaster
 + Good to get an info folder
 + Useful to have phone #'s on the attendee badge
 + The coffee was very enjoyable


Here are the bits that would be nice to improve at the next hackathon:

 - More than one room for hacking? The main room we had was packed.
 - 16h access to venue would be nice (not 10/8h). Hacking at the pub wasn't
   too bad though.
 - Standup-meetings at the end of the day would be nice to have. I would
   have loved to hear what people were up to.
 - An optional hackathon commercial support ticket price would have been
   nice. Some businesses have budgets for training but not sponsorship.


Here are a few ideas maybe worth trying out:

 + Have the hackathon on thu/fri/sat/sun (one additional day), to make it
   easier for attendees who can't spend weekends hacking but would like to
   come anyway.
 + Move hackathon dates to a few weeks earlier, so attendees can submit
   hackathon-relevant talks to YAPC and other conferences before deadlines.
 + Make an effort to invite people for external (non-Perl) communities.
   Examples might include: Distro vendors; Packaging experts; People in the
   TAP community (See the tap-l IETF mailing list).
 + Set one lofty coding-related goal for the hackathon, with intention that
   "everyone" can help make it happen, and with a list of tasks anyone
   (even new attendees) can work on.



The goal is to add a bunch of bullet points to our work document, so that
we can start early on making the next QA hackathon even more productive
and useful.


Hope that my comments help somehow.


- Salve, who enjoyed the hackathon a lot

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Post-install tests demo at the qa hackathon \o/

[Salve J Nilsen]

Hei!

Looking forward to the hackathon this weekend! :)

Just to make it a little more fun/productive, my colleagues and I are bringing 
some code to show you all! :D


We're bringing a functioning post-install test extension for Module::Build. The 
main features are:


 - With it, you can install your CPAN package tests in a standard[1] location,
   either by running './Build installtests' or by setting and environment
   variable that makes './Build install' do the same.
 - If you've chosen to install packages this way, you now get the option to
   run these tests at some later point - like when you're about to upgrade
   a dependency of something you care about. Use the new './Build testrdeps'
   and './Build testinc' actions for this!
 - There examples and tests!

We've also prepared a 30min presentation w/demo if any of you are interested in 
seeing our take on the post-install discussion, and we'd love to give it if 
anyone's interested! \o/


Also, you can see/clone the code right now:

   git clone git://github.com/bannaN/Module-Build-PIT.git

Hope this is a useful addition to the hackathon this weekend! :)


- Salve (Oslo.pm guy)

[1] Pending standarization :)

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Post-install tests demo at the qa hackathon \o/

[Salve J Nilsen]

Hei!

Looking forward to the hackathon this weekend! :)

Just to make it a little more fun/productive, my colleagues and I are bringing 
some code to show you all! :D


We're bringing a functioning post-install test extension for Module::Build. The 
main features are:


 - With it, you can install your CPAN package tests in a standard[1] location,
   either by running './Build installtests' or by setting and environment
   variable that makes './Build install' do the same.
 - If you've chosen to install packages this way, you now get the option to
   run these tests at some later point - like when you're about to upgrade
   a dependency of something you care about. Use the new './Build testrdeps'
   and './Build testinc' actions for this!
 - There examples and tests!

We've also prepared a 30min presentation w/demo if any of you are interested in 
seeing our take on the post-install discussion, and we'd love to give it if 
anyone's interested! \o/


Also, you can see/clone the code right now:

   git clone git://github.com/bannaN/Module-Build-PIT.git

Hope this is a useful addition to the hackathon this weekend! :)


- Salve (Oslo.pm guy)

[1] Pending standarization :)

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: QA hackathon 2012

[Salve J Nilsen]

David Golden said:


FWIW, my wife has now strongly hinted that the March 31st weekend 
would be the best option.  :-)


Just a quick preliminary heads-up (without anything being set in stone 
atm.)


There's a decent chance for a Perl6 hackathon (and related events in 
the days before and after) in Oslo the weekend of march 23-25 - one 
week before David's wife's suggestion :).


I've heard from some of the prospective attendees that they'd love for 
something more to do in .EU around that time, perhaps being a bit 
miffed by the long weeks between that hackathon and the NLPW dates in 
the beginning of march.


So if $organizers would like to have some attention from the Perl6 
crowd (or maybe give the qa/toolchain gang an opportunity to make 
something happen in the Perl6 community) there might be a good time 
for this then. We'd also make life a little easier for some of the 
people who come from faraways. :)



- Salve (Oslo.pm)

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Move Test::More development discussion back to perl-qa?

[Salve J Nilsen]

Michael G Schwern said:


I don't get much response to posts on test-more-users, though I know people
are subscribed.  perl-qa traffic has dropped off quite a bit.  I'm wondering
that if I moved Test::More and Test::Builder2 posts back to perl-qa that there
would be more discussion?

Do people not care?  Is it going over everyone's heads?  Is everyone just
waiting for it to be "done"?  Does it not seem like TB2 is relevant?


FWIW, "Less is More" :)

Whatever you do, keep posting on perl-qa. I'm very happy for any 
updates, but I'm already subscribed to so many mailinglists that I'm 
pretty sure I'm missing out on some useful info.



- Salve, who also suffers from having too many things to pay
 attention to

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: qa.perl.org

[Salve J Nilsen]

James E Keenan said:


I learned a tremendous amount about testing, code coverage and 
writing testable code from the Phalanx project -- knowledge which 
has served me well, particularly in the Parrot project.  The 
approach to 'phalanx'-ing a module can be applied by anyone (and I'm 
happy to mentor people on that).


Would you be interested in putting your experiences into a "Howto" 
form? (preferrably as terse as possible)


I think the Phalanx project is still useful as a concept and as a 
"teaching tool" and if we should repurpose the Phalanx page into 
something more useful than the "mission statement/overview" type page 
we have now, then this would be it. :)


But, to the best of my knowledge, there's no active Phalanx project 
per se at the present time.  So it doesn't need to be quite so 
prominent on qa.perl.org.


I'd instead decide prominence on the _intention_ of activity, not the 
current state or the history of the project. What do we WANT to do is 
more important than what has been done (the point here is to convey 
the fact that the Perl QA has a future, and that it's more important 
than what has been done.)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: qa.perl.org

[Salve J Nilsen]

Hi, Leo :)


A few comments,


Leo Lapworth said:

2010/1/2 James E Keenan 

3) Phalanx

Though in one sense it pains me to say it, Phalanx does not need to 
be a major tab.  It can be demoted to a link somewhere.





I have put it is as a tab on the right called 'old projects'.

I removed the 'Coordination' section and also dropped the link to 'Tasks to
be done'.
I also added 'finished' to the title.


Would you mind changing this to something less "final"? There are a 
few marketing considerations, see:


 Old = inactive | established; # Which one?
 Major tab = Decision about visibility; # What needs more visibility?
 Finished = Nothing more to do; # Sure? Is visibility still useful?

Removing or adding topics/projects from the (any!) frontpage will 
quite likely have a major impact on those projects. Before doing so, I 
ask you to consider a few things:


1) Do the projects have any worthwhile qualities that makes them good 
to keep around (keep visible) even if activity levels are down?


2) To what extent can the webpages be used for recruiting people to 
useful projects? Is it better to "repurpose" a page to make people 
want to join/help instead of demoting the page to "historical value 
only"?


3) What context is the most useful one to promote a project within? 
("Finished"? "Current projects"? "Community efforts"?)



I suggest that the qa.perl.org frontpage does NOT link to "old" 
(which in a software context usually is interpreted as "defunct", 
"bad", "lacking maintainance" or "not updated") projects at all. 
Instead, be REALLY careful about calling something "old" and only 
reserve words like that for projects that we'd like to kill off.


Pick another phrase instead - preferrably something that communicates 
the fact that a project is interesting/worth learning about and 
relevant for the reader in some way.


Also, keep in mind that the page needs to stay around for a long time, 
and that whenever someone reads it, the pages need to convey the 
impression of actuality (updatedness, relevance, that it's "current") 
no matter if the page is read next week or next year. Avoid 
time-related words like "still", "now", "old", "upcoming" etc..


The point here is to make the pages read as "fresh" even if 
qa.perl.org is a volunteer effort where the volunteers by default have 
almost no time to help. (Everyone having jobs/life/family/kids/etc. 
should have as little negative impact as possible on the "updatedness" 
of the page. ;)



Hope this is useful! :)


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: qa.perl.org - anyone interested in updating it?

[Salve J Nilsen]

Hi, Leo! Welcome to perl-qa! :)

Leo Lapworth said:


Hi,

I cleaned up http://qa.perl.org/ but the content needs a complete 
review/update.


Sweet. But does ALL of it need an update? If not, which parts are you 
specifically thinking of?




Is anyone interested in doing this?


Ask me in febuary, after FOSDEM.


I've chatted with several people, but so far not found anyone 
interested.


If no one is interested we'll shut down the site as a lot has 
changed and we now have CPAN Testers as well, which is probably 
where we'd redirect to.


Much better to leave it partly useful than just shutting it down. 
Anyhow, showing everyone that there's a Perl QA group is still useful 
enough to tolerate some stale content.


 [On a side note, threats like "We'll shut down the site if noone
 steps up" is a rather crummy way to introduce yourself to a mailing
 list, don't you think? :)]

Thanks for the cleanup though.


- Salve (Oslo.pm)

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Making TODO Tests Fail

[Salve J Nilsen]

Ovid said:

- Original Message 

From: chromatic 


Add diagnostics to TODO tests and let your test harness do what 
it's supposed to do.  Shoving yet more optional behavior in the 
test process continues to violate the reasons for having separate 
test processes and TAP analyzers.


We have no diagnostics. We've never had diagnostics (the ad-hoc 
things going to STDERR don't count because they can't be synched or 
reliably parsed). Thus, I can't add diagnostics to the TODO tests 
until Schwern puts diagnostics in Test::Builder or accepts a patch. 
That doesn't look like it's going to happen any time soon, so 
telling me to add diagnostics to TODO tests doesn't help :(


Fork/branch Test::Builder and make it work yourself. When it's ready 
and usable, ask Schwern to evaluate, improve and merge.


Code = Conversation. :)


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# 
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

Rick Fisk said:

On Tue, 2008-10-28 at 19:09 +0100, Salve J Nilsen wrote:


Yes, I'd like to avoid ad hominem attacks. This is a basic part of 
making any negative-feedback service into a respectable one.


You appear to be contradicting yourself here. There's no need for a hall 
of shame. As somebody has already pointed out, all one needs is for the 
list to be comprehensive, all-inclusive and paginated.


Yes, a comprehensive, all-inclusive and paginated list would be a good 
solution. Especially if users can reverse the list and filter it by CPAN 
ID. :)




[snip]

Your belief that the list is "motivational" is purely conjecture on your
part. If you have some qualitative measure which tends to support the
idea, I'd find it interesting.


Well. I'm basing my argument mostly on personal experience. I've also met 
several people who appreciate getting relevant negative feedback on their 
work. I've also met people who don't like negative feedback at all, not 
seldom accompanied by a "healthy-sized" sense of self. I'd like to see 
more of the former. :-/



In another email on the subject, you suggested "I'd like to see a world 
that treats volunteers with respect, but doesn't deny them negative 
feedback".


Classifying some module as being lower on the list of 'kwalitee' is in
fact positive feedback if no negative characterizations are added. This
is where I think there is some confusion. "Shame" and intending to heap
it on a specific set of developers is definitely negative. A score is
not negative. It is merely a score.


Good points.

I may have realized something now - that the word "Shame" is a very strong 
and heavy-handed word, on the same level as Quisling and Traitor. Is this 
correct? Sorry to ask this question, English is my second language, and 
although we have the same word in Norwegian - "skam", it's hardly a word 
we put much weight and seriousness into. When we say "skam deg!" ("Shame 
on you!") we do it to kids who have done something nasty (e.g. crapping on 
the lawn instead of in the potty.)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

Andy Lester said:

On Oct 29, 2008, at 6:30 AM, Salve J Nilsen wrote:

Would you ever argue that a cancer drug should be discontinued just 
because "only one in a million" uses it?


Yes, if the cost to the community was too high.


Damn. You ignored the argument and chose to comment on the side note. Oh 
well. :-/




[snip]

Again, Salve, please understand that the vast majority of humans do not 
divorce their feelings from their work, as much as you may see that as a 
"problem."


I think you haven't grasped the points I've tried to make, so I'm guessing 
this part of the discussion is leading into a dead-end. I'll stop here. 
Thanks for your time.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

Andy Lester said:

On Oct 28, 2008, at 1:09 PM, Salve J Nilsen wrote:

Feel free to suggest a better title. (I won't, because I think there's 
a motivational value in keeping it as it is.


[snip]

I have to ask what "motivational value" you see in having a Hall Of 
Shame under any name.  Please describe what scenario you see such that 
this Hall of Shame will have any effect whatsoever on the Kwalitee of 
work generated.


Well, I can start with stating my assumptions. I assume that most people 
have some desire to improve themselves and their work, and I assume that 
they are open to the notion that some of this can happen through critique.


I also assume that we're talking about topical critique, and not personal 
critique (I know some people have problems keeping them apart, but I'm 
willing to assume they at least can _imagine_ how this might work.) The 
topics we're specifically talking about are Kwalitee-metrics. (I 
purposefully ignore evaluating the metrics themselves. That's a discussion 
for another time.)


Furthermore, I assume that authors who publish their code have some form 
of pride of their product - at least enough so they feel comfortable 
placing their name and reputation next to it.


I think these assumptions are pretty safe, but I do know there are 
exceptions to them and that they _are_ after all _assumptions_.


So, how can a "hall of shame" motivate me, given these assumptions? Should 
I find a module of mine in this list, I'd start with searching for what 
this _means_. Are the points raised in the list (the Kwalitee metrics) 
reasonable to me? Can I imagine the relevancy of their critique? If I find 
that the critique is valid, then I feel have to consider how to fix the 
issues raised by the critique (This is the point where I decide to do 
something about it or not.)


If I end up fixing the bugs, then I have been "motivated." And since the 
fix presumably has some value, I think it's not unwarranted to say that 
the motivation leading to the fix also has some value.


All this is of course difficult to measure on anything but a personal 
scale, but we _can_ assume that _less_ bugs will be fixed if we remove 
feedback-mechanisms like the list.



Do you imagine that an author of a low-Kwalitee module is going to 
stumble upon the list and see his or her module on it?  The chances of 
that are miniscule.


This is a side-track of the issue. The issue you raise here is about the 
visibility and/or marketing of the list. Right now, the list is well 
hidden, but with some well-placed words, this can be fixed.



Do you imagine that an author of a low-Kwalitee module, upon seeing his 
or her module on the list, is going to go and modify the distribution? 
The chances of that are miniscule * tiny.


Well. Even if the likelyhood of an author improving their own code is 
tiny, it's better to at least give them the _opportunity_ to do so. 
Shutting down the list entirely doesn't help with this.


On a side note; do you take this position in other arguments too? Would 
you ever argue that a cancer drug should be discontinued just because 
"only one in a million" uses it? Of course you wouldn't. You'd judge the 
drugs on it's merits, not how much it's used. Please, let's talk about the 
merits of the list instead, and how to improve it, make it more visible.



Most of all, what problem are you trying to solve?  I suggest that 
low-Kwalitee modules on the CPAN pose no problem whatsoever.


Maybe they don't today. Maybe we can improve the Kwalitee metrics in such 
a way that low-Kwalitee modules become more of an issue than they are 
today. If we shut down the list, the we lose this opportunity.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

David Cantrell said:

On Mon, Oct 27, 2008 at 01:40:03PM +0100, Salve J Nilsen wrote:


I think _some_ kind of shaming should be allowed. Carrots are good, but
sticks work too when applied in a respectable fashion.


They might, but a "hall of shame" ain't respectable.  If I were on the
list, then it would just make me think "cpants is run by a bunch of
cunts, so i'll just ignore them".


What other list name (that still explains the purpose of the list) would 
you prefer then?



But taking down the hall of shame smells awefully like the chinese 
press rules ("We are only allowed to publish _good_ news about 
ourselves!")


There's plenty of bad things said on CPANTS still - I have angry red 
marks against my name for all sorts of things.  But I don't mind, 
because they're backed up with an explanation.  Saying "DCANTRELL is a 
bad programmer and should be ashamed of himself" will merely make me 
think less of you.  But saying "DCANTRELL didn't include a changelog in 
some of his distributions, we think that's bad because ..." is called 
Constructive Criticism.  Of course, that doesn't mean I'm paying any 
attention, but at least I haven't dismissed CPANTS as the work of 
ill-mannered lunatics.


Yep, this is your option and your freedom, and it's a Good Freedom. You 
(and any other CPAN author) are, and should always be, allowed to ignore 
the recommendations and opinions from others.


Still, let's not remove the negative opinions just because they are 
negative. There are much better ways to improve those than to outright 
censor them.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

chromatic said:

On Tuesday 28 October 2008 10:54:33 Salve J Nilsen wrote:


- Salve, worried that the next step is to paint pink ponies and rainbows
          all over CPAN.


Hey look, a slippery slope argument combined with the false dilemma 
fallacy!


Yes. Good catch! Happy to see someone's caring about logical fallacies. ;)



Salve, there really are more possibilities in the world besides either:

1) Being complete, irredeemable, raging jerks to volunteers
2) Remaking the world of Perl into Hello Kitty Island Adventure: Riding 
Camp: Their Senior Year


Yep. This is my point too. I'd like to see a world that treats volunteers 
with respect, but doesn't deny them negative feedback just because someone 
thinks $negative_feedback == $personal_attack .



You're a smart guy.  I'm sure you can see that there's nuance between 
those two positions, and I'm sure that once you do, you'll see that 
absolutely no one has seriously argued for #2.


I do see several people argue that we must avoid 1) at seemingly any 
cost, with the result that useful services get 404'd for no other reason 
than "politeness".


(Kinda reminds me of the terrorism hyteria going on everywhere, but that's 
a side note. Never mind that. :-P)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

Rick Fisk said:

On Mon, 2008-10-27 at 19:17 +0100, Salve J Nilsen wrote:


We're still talking about a marketing/visibility bug here. Don't you 
agree it's better to fix that instead?


You think that it is important that the CPANTS team makes sure that
everyone knows there is a web page dedicated to shaming developers?


Well. I don't care who does it, just as long there are lists with 
constructive negative feedback. I leave it to the developers themselves to 
learn what it takes to get of the list.



There's nothing random or abusing here, just feedback on Kwalitee 
comparisons between modules. If this feedback hurts your (or anyone 
elses) tender little feelings, then too bad. A psychologist would 
remind you not to equate critique of your writings with critique of 
yourself.


You are entitled to your opinion of course, but one doesn't need a
psychologist to identify ad hominem.


Yes, I'd like to avoid ad hominem attacks. This is a basic part of making 
any negative-feedback service into a respectable one.




Antagonism doesn't breed quality software. If it is really a goal to
increase quality, then a 'hall of shame' is counter-productive, the
feelings of people on either side of the issue notwithstanding.


It's ONLY counter-productive if the list is ad-hominem. It's also 
suprisingly easy to avoid ad-hominem attacks in ANY text. Just focus on 
the facts, the product and/or the argument.



If the hall of shame really is 'Kwalitee comparisons between modules', 
it doesn't require a page title of 'hall of shame' and it would by your 
definition need to include all modules under test rather than a subset 
deemed worthy of shame.


Feel free to suggest a better title. (I won't, because I think there's a 
motivational value in keeping it as it is. The day I end up on the list, 
I probably won't say "meh, it's not important for my reputation".)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

Andy Lester said:

On Oct 27, 2008, at 1:17 PM, Salve J Nilsen wrote:

There's nothing random or abusing here, just feedback on Kwalitee 
comparisons between modules. If this feedback hurts your (or anyone 
elses) tender little feelings, then too bad. A psychologist would 
remind you not to equate critique of your writings with critique of 
yourself.


I understand that that's how you see it, but the vast majority of people 
do not.  Most people would see your attitude towards their "tender 
little feelings" as being an asshole, and not want to deal with you. 
That is not a way to encourage volunteers to work on projects.


Oh, I was talking about the Kwalitee hall of shame, not what goes on in 
this mailing list. I also made a point that the negative feedback on 
the HoS list should be given in a respectable manner.


There are lots of ways to make a list respectable, including removing 
words with negative meaning, making the list only contain module names and 
not authors. Feel free to suggest your own NewSpeak-inspired redoing of 
the page, if you really think it's this important. Just don't remove the 
entire list simply because of the _possibility_ that someone's 
sensibilities might be hurt!


(BTW, do you want to remove ALL halls of shame? What about the one on the 
Perl Foundation wiki? 
<http://www.perlfoundation.org/perl5/index.cgi?hall_of_shame> )



- Salve, worried that the next step is to paint pink ponies and rainbows
 all over CPAN.

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

chromatic wrote:

On Monday 27 October 2008 05:40:03 Salve J Nilsen wrote:


I think _some_ kind of shaming should be allowed. Carrots are good, but
sticks work too when applied in a respectable fashion.



But taking down the hall of shame smells awefully like the chinese press
rules ("We are only allowed to publish _good_ news about ourselves!")


Did you know the Hall of Shame was there?  Several of the people who responded 
to my post didn't know it was there.


Yes, I knew about it, although it could have been made more visible. Let's not 
fix a visibility/marketing bug by removing the list, but instead fix the core 
issue - the lack of visibility.



How would you feel if some of your work were on the list, had been on the list 
for quite some time, and no one ever told you?


I would certainly not blame anyone else than myself, but that's me (I'm also a 
bad example since I'm aware of the list and would at least put a little effort 
in getting further up on the scale.)



Remember, this is not a project designed only to say "This code sucks."  Its 
intent is to encourage people to improve their code.  My code doesn't 
magically get better when someone finds a bug.  It magically gets better when 
someone *fixes* a bug.


One is a prerequisite of the other. You have to have some indication that a bug 
exists before you can fix it (let's ignore "accidental bugfixes" for now.) So 
unless you live in a bubble all by yourself, this list will at the very least 
increase the likelyhood of you learning about (in this case Kwalitee) bugs.


This is a good thing. Especially if the scale we're measuring the code is 
sensible, well thought out and relevant. If your ego gets a bruising, too bad. 
The code Kwalitee is more important.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

chromatic wrote:

On Monday 27 October 2008 10:45:46 Salve J Nilsen wrote:


Remember, this is not a project designed only to say "This code sucks."
Its intent is to encourage people to improve their code.  My code
doesn't magically get better when someone finds a bug.  It magically
gets better when someone *fixes* a bug.


One is a prerequisite of the other. You have to have some indication that
a bug exists before you can fix it (let's ignore "accidental bugfixes" for
now.) So unless you live in a bubble all by yourself, this list will at
the very least increase the likelyhood of you learning about (in this case
Kwalitee) bugs.


A public hall of shame that several people on the Perl-QA mailing list did
not know about has a very marginal effect on increasing the likelihood of 
learning about a problem.  I'm not a statistician, so I can confidently say

that the chance of that occurring is non-zero.  (Randomly stumbling across
several billion web pages will *eventually* get you there.)


We're still talking about a marketing/visibility bug here. Don't you agree it's 
better to fix that instead?



This is a good thing. Especially if the scale we're measuring the code is 
sensible, well thought out and relevant. If your ego gets a bruising, too 
bad. The code Kwalitee is more important.


Heaping random, unsolicited, and public abuse on contributors is a fantastic
way to make sure there are no Kwalitee programs -- in the sense that
abusing contributors is a great way to make sure that there are no more
contributors.


There's nothing random or abusing here, just feedback on Kwalitee comparisons 
between modules. If this feedback hurts your (or anyone elses) tender little 
feelings, then too bad. A psychologist would remind you not to equate critique 
of your writings with critique of yourself.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Public Humiliation and Kwalitee

[Salve J Nilsen]

chromatic wrote:

On Thursday 23 October 2008 11:25:05 Yitzchak Scott-Thoennes wrote:

On Thu, October 23, 2008 10:37 am, chromatic wrote:


http://cpants.perl.org/highscores/hall_of_shame


That looks sorted by kwalitee and author.  If we're shaming people, author
name shouldn't be a factor.  Could it be by kwalitee and most recent
release date instead?


Why should any part of QA include shaming people?


I think _some_ kind of shaming should be allowed. Carrots are good, but sticks 
work too when applied in a respectable fashion.


But having a hall of shame filled with nothing but names of developers 
(nom-de-guerres notwithstanding) does awfully look like ad hominem attacks put 
into system. That's obviously no good. We're quite capable of giving negative 
feedback about modules while staying civil.


But taking down the hall of shame smells awefully like the chinese press rules 
("We are only allowed to publish _good_ news about ourselves!")



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: IETF

[Salve J Nilsen]

Aristotle Pagaltzis said:

* Ovid <[EMAIL PROTECTED]> [2008-08-18 15:30]:


Schwern, I can't tell from reading the references you provide whether 
or what you're saying is correct, but I *think* so.


I think your initial mail was misleading and Schwern promptly 
misunderstood you. What Salve brought up is not that the *working group* 
needs to attend IETF meetings thrice yearly, but *the chairman* of the 
WG does.


We’re talking about one person, the chair, not about the entire 
working group.


As I see it, The purpose of the IETF meetings are to give WG members 
well-planned and regular opportunities for high-bandwidth discussions 
about their issues. I haven't seen any requirements that WG Chairs MUST 
attend these, but according to RFC 2418 section 6.1, it's the Chair's 
responsibility to help the discussions move forward, including by 
arranging BOFs at IETF meetings.


There are lots of details here I don't know about, so I propose we wait a 
little with this discussion until we have the WG mailing list up and 
running, where Lisa Dusseault and Chris Newman can answer questions like 
these.


I've sent in the request for setting up the list now, and everyone who 
voted +1 for list creation has been added already. :)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: CPAN Ratings and the problem of choice

[Salve J Nilsen]

Jonathan Rockway said:

* On Mon, Jun 30 2008, Greg Sabino Mullane wrote:
Why are people not rating modules, and how can we encourage people to 
do so?


Probably for the same reasons they don't read this mailing list, 
contribute to perlmonks, attend YAPC, upload their own modules, etc.


I don't know exactly what this reason is, but I have a feeling it's "who 
cares" or "why should I bother".


My current theory on this includes

 - "I have something more important to do,"
 - "I don't see how this helps me now,"
 - "Giving feedback requires too many hoops to jump through" and
 - "I don't think I have anything to contribute."


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: CPAN Ratings and the problem of choice (was Re: About tidying up Kwalitee metrics)

[Salve J Nilsen]

Paul Fenwick said:

Jonathan Rockway wrote:

The same could be said for CPAN Ratings also.  Why should my module 
have 1 star next to it because any goof with a web browser can write a 
review?  Why is the opinion of someone with no ties to the community 
considered relevant enough to show in the search.cpan search results?


I'm a big supporter of CPAN Ratings, because I view them as solving one 
of the biggest problems facing the CPAN today.  Choice overload.


CPAN is suffering from its own success.  One of the most common 
questions I get asked is "Which CPAN module should I use?  There's like 
300 that cover my problem".  The worst thing is, faced with too many 
choices, typical humans are more likely to choose *none* of them, 
compared with if they were only offered one or two[1].


Thank you for making this point. I've had this problem too, many times, 
and I'd love to see something that helps me manage it.


Let's assume I'm in hurry to buy a present to someone I don't know (or any 
other situation where I'm forced to make a low-info, low-context 
decision.) I have to make the best out of the situation with the 
information that I have. Sometimes the only solution is just to ask the 
clerk "what toy would you give as a birthday present to a 5 year-old 
friend of your nephew?". The clerk would at least be able to give _some_ 
useful info, like "this is popular amongst the pre-schoolers" or "this toy 
got a prize for being the most educational in 2007" or "we are getting 
lots of these toys in return, so don't buy it until the problems are fixed 
upstream"...


The criteria for choosing software are of course a bit different. I'd 
argue the major one is that WE can also choose to improve the software we 
select (at least when it comes to OSS.)


So when we're discussing Kwalitee metrics or the CPANTS game, we're in 
fact discussing new datapoints for people to use when they choose. We make 
information available. We're "communicating".


But as with all other kinds of communication, we have both transmitters of 
information (the CPANTS website, metrics, explanations, reviews etc.) and 
a receiver (the individual end users, the distro authors), and as with all 
other kinds of communication, there's always a danger for the recipient to 
interpret the info wrong.


There's a tradition in the marketing and sales professions that if a 
message doesn't "land" well, then one should assume something is wrong 
with the message, and not the recipient. This may be well and true in most 
cases, but it doesn't take much to imagine situations where this 
assumption is wrong - or at least not precise enough.


But for our purposes I think this tradition would apply well. If people 
are actually annoyed about getting in the "hall of shame", we shouldn't 
remove the hall, but instead give them useful info on how to get out of 
it. If authors add useless "workarounds" just to get on the top of the 
CPANTS game, we shouldn't remove the game, but instead find ways to make 
this tactic useless.



It's extremely telling when one of the most popular parts of Perl 
Training Australia's courses is showing students the Phalanx 100 as a 
short-list. Even though the list is quite some years old, there's almost 
palpable relief when the students realise they can just pick XML::Parser 
from the Phalanx top 10, rather than having to examine the multitude of 
choices on the CPAN.


So, why do ratings make a difference here?

Well, ratings provide at least a partial way for the community to solve 
the choice overload problem.  If a search reveals a 4.5 star module with 
eight reviews, one doesn't feel compelled to look at the other options; 
the choice becomes clear.


Let's look at one assumption I think we're making... Who are actually the 
information "recipients" in this matter? Here's my take on it:


 * End users of CPAN modules
 * CPAN module authors
 x People who are in a "learning" mode
 x People who are in a "getting things done" mode

So, who should we tailor the messages for? Here's how I would rank the 
message recipients:


 1. End users of CPAN modules who are in a "getting things done" mode
(help users choose, because this makes CPAN into Perl's killer app)
 2. CPAN module authors who are in a "learning" mode
(help authors make better modules, because we want less than 90% crap)
 3. End users of CPAN modules who are in a "learning" mode
(help users become authors, because this is how the community grows)
 4. CPAN module authors who are in a "getting things done" mode.
(help authors work efficiently/without "annoyances")

If we can agree on this, I think it'll be a lot easier to decide of ways 
and means to move CPAN forward, and even make some good decisions.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&

About tidying up Kwalitee metrics

[Salve J Nilsen]

Hello, folks

I propose to split the current "main" and "optional" kwalitee scales into 
topical ones, so we can allow for richer set of metrics while allowing everyone 
that care mostly about certain types of metric access to "untainted" versions.


Let's remove the "optional" type, and instead create the following metrics 
where we can place the existing tests:


Disto Kwalitee
 (most of the original test should go here)
Security Kwalitee
 (checks for taint-mode or other security-related issues go here)
Community Support Kwalitee
 (checks for supplied mailing list address, bugtracker, archives, etc. go here)
Community Trust Kwalitee
 (analysis of external acceptance of the module, including Debian use go here)

Thoughts?


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Wanted: Hackathon topic introductions

[Salve J Nilsen]

To everyone planning on showing up at the hackathon:

Thomas Klausner said:


Hi!

On Mon, Mar 31, 2008 at 10:58:39AM -0400, David Golden wrote:


For those attending the Oslo hackathon, please see the new schedule 
page:


Are there any plans on short talks introducing people to the various 
topics? I could prepare a short intro to CPANTS, and list my 'Testing 
Best Practices' questions (which are also CPANTS related..)


I think that short intro talks would be nice to help attendees decide 
what they want to hack on. Longer, more in-depth talks introducing 
people to each topic would also be nice, but are maybe to much work to 
prepare.


What do you think?


I agree. :)

If you want to lead some specific topics at the hackathon, please prepare 
a short intro about each topic!


 * One introduction to each topic
 * 3-4 minutes max (but we'll accept longer one if you _must_)
 * Tell us what you'd like to work on, and...
   * ..why the topic it is important
   * ..how the topic might relate to other tasks
   * ..what you think needs to be done
   * ..who probably would be affected by a successful outcome
   * ..and a rough ballpark estimate on how much effort it would take
 * Please keep it short and to the point.

We'll have the topic presentations on saturday morning (before we start 
assembling the hackathon schedule,) so that everyone gets an opportunity 
to recruit lackeys/choose their masters :)


Remember we have a limited amount of rooms available, so do try to sell 
your topics well, or you might end up without a room to work in (!!).



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Oslo Hackathon schedule page

[Salve J Nilsen]

Important info about the schedule:

David Golden said:


For those attending the Oslo hackathon, please see the new schedule 
page:


http://perl-qa.hexten.net/wiki/index.php/Oslo_QA_Hackathon_2008_:_Schedule

As we start making plans (hacking or social), please add them to the 
page.  You may also want to add the page to your watchlist and set your 
preferences to notify you when anything on your watchlist changes.


Please note, that my first intention is that the entire schedule will be 
decided _onsite_ by the people who actually _meet up_. This page will 
therefore have to be a _secondary_ source for scheduling information, but 
if people want to keep it uptodate with the authoritative one at the 
venue, then that's awesome. :)


I repeat: Only the people who meet up _physically_ at the venue get to 
decide the actual schedule. The authoritative schedule will hang on the 
wall at the venue, and will probably be updated as needed.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Friday afternoon^Wevening in Oslo

[Salve J Nilsen]

David Golden said:


I'll be getting into Oslo Friday mid-morning.  Assuming no mishaps 
finding the hotel, I'll be up for touring around Oslo on Friday 
afternoon.  If anyone from the hackathon has similar plans and is 
interested in meeting up, please email and let me know.  (And if any 
locals want to play tour guide, that's great too!)


On a related note, we'll have a pre-hackathon pub meetup at The Shamrock 
at Grünerløkka from about 18-ish on friday. They have good pubgrub and 
drink, and aren't overly expensive. It's also within acceptable walking 
distance from the Anker hotel, and if you take the last tram, it'll bring 
you back to your hotel in just a few minutes. :)


  Place:   The Shamrock (10 minutes tram ride from Anker hotel)
  Time:Friday, April 4th, from 18-ish and onward
  URL: http://shamrock.no//index.php?LangId=3
  Food:Pub grub, not too expensive

More details later on the wiki...


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

TODO: Registering for the Oslo QA Hackathon

[Salve J Nilsen]

Hey, guys!

Just want to remind you to register for the QA hackathon in good time 
before the event. It you intend to show up, of course. :)


http://perl-qa.hexten.net/wiki/index.php/Oslo_QA_Hackathon_2008_:_Topics

 1. Add your name and some words about yourself (including contact info if
you're coming from abroad.)

 2. Write what you'd like to work on, and what you're interested in.
Concrete tasks are good, but feel free to suggest anything
appropriate.

 3. Give othe relevant details if necessary (e.g. documentation,
repository URLs or links to archived discussions)


Also, if you have special dietary needs, tell about it on the food wiki 
page.


http://perl-qa.hexten.net/wiki/index.php/Oslo_QA_Hackathon_2008_:_Food

See you soon in Oslo! :-D


- Salve (Oslo.pm guy)

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Hackathon logistics

[Salve J Nilsen]

Michael G Schwern said:

David Golden wrote:


I'm curious to try git, if anyone is up for teaching it.


I had the same thoughts.  My concern is that we'll be spending time 
futzing with git rather than hacking on QA stuff.


I approve of this message.

On a related note, do we (the hackathon attendees collectively) have the 
necessary commit bits for all the QA-related projects we'd like to futz 
around with?



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Hackathon logistics

[Salve J Nilsen]

Gabor Szabo said:

On Wed, Mar 26, 2008 at 6:38 AM, Salve J Nilsen <[EMAIL PROTECTED]> wrote:

> *) Whiteboards, markers & erasers.
>
> Lots of whiteboards for taking notes.  At least one whiteboard just 
> for projects being worked on, the "grid" at BarCamps is an example.


We'll have at least 5 rooms with whiteboards, in addition to lots of 
space to set up brownboards. We'll also have a dedicated area for 
managing and discussing schedule-related stuff and one or two quiet 
areas for those who need a break.


If we can use the projectors in the classes we can hook up one of the 
computers and use the wiki as our white board.


The rooms with whiteboards have projectors and screens, so that's 
definitely an option. :)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Hackathon logistics

[Salve J Nilsen]

Michael G Schwern said:


*) Access for wirelessless laptops?


There'll definitely be wireless for everyone, but I'll look into this too 
(it shouldn't be much of a problem.)




*) Whiteboards, markers & erasers.

Lots of whiteboards for taking notes.  At least one whiteboard just for 
projects being worked on, the "grid" at BarCamps is an example.


We'll have at least 5 rooms with whiteboards, in addition to lots of space 
to set up brownboards. We'll also have a dedicated area for managing and 
discussing schedule-related stuff and one or two quiet areas for those who 
need a break.




*) Index cards & pens

Both for taking notes and for anyone wanting to do XP.


Good point. I'll look into this.



*) Real-time comms.

We have #perl-qa on irc.perl.org.  It might make sense to have a twitter 
account for broadcasts and cell phone messaging.


In addition, I'll add my contact info on the main hackathon wiki page (at 
the bottom), including cell phone number.




*) Caffeine and snacks

"Snacks" covering both the junk food and non-junk food kind.  The latter 
being anything not covered in sugar and salt. :)  Worse comes to worse, 
some sort of trail mix that's not covered in sugar and salt.


There's a coffee machine and a soft-drink box at the venue with free tea 
and coffe/hot chocolate. Not sure about the softdrinks, but they shouldn't 
be too expensive.




*) Food plans

A short list of convenient places to order food from.  Also easy to get 
to places that can accommodate all of us.  They must deal with varied 
dietary requirements (veggie, no-dairy?, no-wheat?, kosher? etc...). 
Have at least pizza and chinese as everyone knows how to deal with that.


There's at least three take-outs within walking distance (Pizza & 
Chinese, another Pizza place and a tiny Vietnamese place which I order a 
lot at). All have decent food, but only the Vietnamese one is "cheap".


Also, Linpro will be ordering food for all of us (pizza) on at least one 
of the days. We'll also have access to the company lunch cantina which 
they'll keep open especially for us on saturday and sunday.



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: My Perl QA Hackathon Wishlist

[Salve J Nilsen]

James E Keenan said:


1.  A "canned" training session, "Learn Test::Harness 3.0," that would 
provide the user with a guided tour of T::H 3+ and have him/her actually 
type and run examples of the new functionality.  "Canned" in the sense 
that at a local Perlmongers meeting everyone could download a tarball 
and work through the exercises together, without the need for someone to 
have become an expert on all the new features.


2.  Release of Test::Harness 3.11, with the corrections to 'prove' and 
App::Prove I submitted to Andy Armstrong.  Needed so I can push forward 
with selling a new testing approach to the Parrot project.


3.  Anyone to step forward and volunteer to co-lead a lab session on 
T::H 3+ with me at YAPC::NA::2008 in Chicago in mid-June.  Such a lab 
session would include, but not be limited to, (1) above.


Feel free to show up! Those who do get to decide what to do. ;-)


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Update 3 on the QA Hackathon in Oslo

[Salve J Nilsen]

Hello again!

Here's the 3rd update on the Oslo QA hackathon. If you got this mail, it 
means you're either on the  mailing list, or explicitly 
mentioned on the hackathon wiki page (most likely because someone wants to 
see you in Oslo.)


  http://perl-qa.hexten.net/wiki/index.php/OsloQAWorkshop2008

In short: Hackathon April 5-7th 2008 in Oslo, Norway. Also, there's an 
open source conference called "Go Open" in Oslo, April 8-9th. And an IEEE 
conference on testing after that, for those especially interested.


This is the current state of affairs:

 0. If you can't come, or want to come - and the wiki doesn't reflect
this, then please update the wiki page! If I haven't heard that you'd
like to come, you won't get a stab at the sponsorship. :-(

 1. Oslo.pm's cooperation with the "Go Open" conference has been fruitful.
Some of you will get a mail with an invitation to give a talk (and
with that comes a trip to Oslo and the hackathon. :) More details
coming later in the week.

 2. We now have funds for 4 people: 2 unspecified, 1 for Ovid and 1 for
Merjin. Thanks BBC and Procura.nl! :-D Two people have also committed
to come anyway. :) The "unspecified" ones will go out soon, if you
want to have a say in who'll come, see #5.

 3. And btw, more sponsors are in the pipe.

 4. We're working on deals with hotels. Hopefully we'll have some
reasonable accomodation offers soon (before feb. 1st, I hope.)

 5. Who would you like to meet if you come to Oslo? Send me a mail with
your top 7 wishlist, and we'll see what we can do. (And those who
give me a list automatically also vote for themselves.)

 6. If you feel someone is missing in the invitee list, please add them!
And remember to vote them in. ;-)

 7. If you want to come, and don't want to bother with the sponsorship
hassle (it'll go atleast a month before we have all sponsor deals
done), please send me a mail. If your $employer pays your trip, that
counts as sponsorship.)

That's it for now. Feel free to mail me if you have questions.


Kind regards,

- Kirill Miazine (Oslo.pm board member)
- Salve (Oslo.pm head nutcase)

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: The spewing problem.

[Salve J Nilsen]

Ovid said:

--- Salve J Nilsen <[EMAIL PROTECTED]> wrote:


Ok, a shot in the dark...

1. Redirect test output to a temporary log file (which should get
   cleaned up during "make clean" &al.)
2. Let the harness be "aware" of this log file, and "tail(1)" it as
   things get written to it, printing whatever's relevant/asked for to 
   the terminal.

3. If there's an error detected, write a warning at the end of the
   test run, pointing to the log file (and perhaps line number in it.)


How is this simpler than 'bail on fail' or 'die on fail'?


Perhaps it's not easier to implement, no. But the user gets at least 
access to the entire set of errors and warnings while still getting the 
high-level test report in the terminal.


If the goal here is to reduce the amount of "pointless" tests run because 
of some failure in an earlier test (DIE_ON_FAILURE=1), then this 
suggestion may be a bit off the mark. But if the goal is to get access to 
the first failing diagnostics, then just keeping them around in a file 
ought to be enough (and that would also give you the option to do 
something with the test output you might not otherwise, e.g. post-test 
analysis or statistics gathering.)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: The spewing problem.

[Salve J Nilsen]

Michael G Schwern said:


The problem I'm hearing over and over again is "Test::Builder is spewing 
crap all over my screen and obscuring the first, real failure".  So now 
that the problem is clearly stated, how do we solve it without making 
all that spew (which can be useful) totally unavailable?


Ok, a shot in the dark...

1. Redirect test output to a temporary log file (which should get cleaned
   up during "make clean" &al.)
2. Let the harness be "aware" of this log file, and "tail(1)" it as things
   get written to it, printing whatever's relevant/asked for to the
   terminal.
3. If there's an error detected, write a warning at the end of the test
   run, pointing to the log file (and perhaps line number in it.)


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Call for Speakers: Perl QA Hackathon in Oslo (important update)

[Salve J Nilsen]

A friendly reminder...

Salve J Nilsen said:

Salve J Nilsen said:


Hey guys.

Oslo.pm is planning a Perl QA Workshop/Hackathon in Oslo, Saturday April 
4th to Monday April 7th, 2008.


 http://perl-qa.hexten.net/wiki/index.php/OsloQAWorkshop2008


We're about to get a significant amount of funding from the friprog.no in 
exchange for helping with talks for the "Go Open" conference they're 
arranging April 8th-9th 2008.


If you'd like to come to the QA workshop/hackathon but can't afford it, AND 
have some good talks you'd like to offer in exchange of funding the trip, 
then READ THIS MAIL CAREFULLY, because this is your chance.



[snip]


 Sunday 2008-01-13, 00:00 UTC: Complete talk proposals in the QA wiki.


I see 4 full talk proposals (from Barbie, rjbs, Schwern and Gabor). Anyone 
else who want a stab at a sponsored trip to Oslo? :)



- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Call for Speakers: Perl QA Hackathon in Oslo (important update)

[Salve J Nilsen]

A quick update...

Salve J Nilsen said:


Hey guys.

Oslo.pm is planning a Perl QA Workshop/Hackathon in Oslo, Saturday April 
4th to Monday April 7th, 2008.


 http://perl-qa.hexten.net/wiki/index.php/OsloQAWorkshop2008


We're about to get a significant amount of funding from the friprog.no in 
exchange for helping with talks for the "Go Open" conference they're 
arranging April 8th-9th 2008.


If you'd like to come to the QA workshop/hackathon but can't afford it, 
AND have some good talks you'd like to offer in exchange of funding the 
trip, then READ THIS MAIL CAREFULLY, because this is your chance.


If you're interested, I need the following from you (formatted as shown 
below), for each talk you'd like to submit. First, find your name on the 
wiki page (or add it, if you feel you have something to contribute), then 
tell us:


 1. Name of the talk
 2. A short (50-80 words) description of the topic, suitable for readers
who not necessarily know any Perl.
 3. A few words about yourself, what you do and any experience you have
that may be relevant.
 4. What kind of audience the talk is intended for (techical level, degree
of previous Perl knowledge, degree of programming knowledge, etc.) and
if the talk can be tailored for different audiences.
 5. Any other info that may be useful, including links to slides,
descriptions or video, if available. Please tell if you've given this
talk somewhere else before.
 6. If you are available to be in Oslo, Norway between April 4th/5th and
April 10th. If you get funded what's the likelyhood that you can come?
(100% = There's nothing that can stop me from showing, 0% = FOAD.)
 7. Where in the world you are, so we can determine flight expenses.
 8. Details about any special requests/needs you have for us.

Remember, this goes into the wiki page!

  http://perl-qa.hexten.net/wiki/index.php/OsloQAWorkshop2008

About the conference so you know what to expect: It will be called "Go 
Open", and be a conference about Free and Open Source software. There will 
be four tracks: OpenOffice, Public Sector, Business and Technical. We're 
primarily looking for technical tracks, but if you can give talks on the 
other tracks too, that'll be considered a plus. The primary audience will 
probably come from the public sector (Municipalities and other local 
government institutions, but really anyting. Free Software has a large and 
growing mindshare in Norway today :). The conference IS open for anyone to 
join so you can also expect business and management types, technologists, 
developers and students. Perl people will probably be in the minority.


There are 14 talk slots available, each about 45 minutes long. Each 
speaker will get _one_ slot on the technical track. It's still possible to 
get a slot in one of the other tracks though, so don't hold back the less 
technical talks - you may qualify for the others too :). Furthermore we'll 
be competing with a pretty interesting set of speakers from all kinds of 
Free Software projects, so take care to give a good impression of what you 
can offer ;-D.


D(ecision)-day is January 16th 2008 (next week!), so any suggestions not 
in by sunday night will most likely be ignored. Monday's for preparing the 
schedule proposal, tuesday for making the decision.


The decision criteria will most likely be:

 1. Relevance and topic of your conference talk
 2. What you'd like to/can add to the QA workshop
 3. Expenses

I'm probably not qualified to judge much about #2, so I'll be asking 
feedback about that later in a separate mail.


My goal is to get half of the available slots filled by you guys, and with 
that make the QA hackathon just a tad more interesting ;).


Oh, and a few parting tips: If you see someone who is offering a similar 
talk as you, try to differentiate yourself. Talks that can play on 
eachother's topics, or complement other talks, may be interesting and a 
Good Thing. If your talk can tell something about "[Something] we can 
learn from the (Free Software|Perl|CPAN|QA) community", that's even 
better.


Finally, this is the deadline you should remember:

  Sunday 2008-01-13, 00:00 UTC: Complete talk proposals in the QA wiki.


Carpe Diem, guys!


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Call for Attention: Perl QA Hackathon in Oslo

[Salve J Nilsen]

Salve J Nilsen said:


Oslo.pm is planning a Perl QA Workshop/Hackathon in Oslo, Saturday April 
4th to Monday April 7th, 2008.


Just to make things more interesting, IEEE will have a conference on 
software testing nearby (in Lillehammer, Norway), just a few days after 
the workshop/hackathon.


  http://www.cs.colostate.edu/icst2008/


- Salve

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Call for Attention: Perl QA Hackathon in Oslo

[Salve J Nilsen]

Hey guys.

Oslo.pm is planning a Perl QA Workshop/Hackathon in Oslo, Saturday April 
4th to Monday April 7th, 2008. This is the official "Call for Attention" 
mail. If you care about general Perl QA issues, please direct your browser 
to the following page:


  http://perl-qa.hexten.net/wiki/index.php/OsloQAWorkshop2008


We (Oslo.om) would like feedback from anyone interested in this! Please 
update the wiki page, or reply to this message on the perl-qa mailing 
list:


 - Will you come?
 - Who should be invited formally, and why?
 - What tasks should be worked on?
 - Where can we look for additional funding?

We already have funding for 2 people, and are likely to get a few more. 
Our goal is to fund the round-trip to Oslo plus lodging for at least 7, 
preferably 10-14 people (yeah, yeah, we're aiming high, let's see how it 
goes.) And no, this hackathon is NOT for invited people only.


As of Jan 7th, the hackathon is _very_likely_ to happen - especially if 
our other sponsor leads decide to join the gig.


Questions/comments are welcome! Either as replies to this mail, or on the 
wiki talk page at:


  http://perl-qa.hexten.net/wiki/index.php/Talk:OsloQAWorkshop2008


kind regards,

- Salve J. Nilsen (leader, Oslo.pm)

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: Providing command-line arguments to tests run via 'prove'

[Salve J Nilsen]

Smylers said:


The convention of using '--' to mean 'that's the end of my own
arguments' neatly avoids all of these issues.


FWIW, I'm with Smylers here. '--' has been around for many years as a 
command-line convention for "signifying the end of options." (from 
bash(1)).


/me likes gentle learning curves, and would like to see command-line 
interface consistency; not just within the Perl sphere, but in general.



- Salve, who thinks command-line options deserve the same amount of
 attention as programming API's and over-the-wire protocols.

--
#!/usr/bin/perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print#  Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':4@,$'.# <[EMAIL 
PROTECTED]>
'2!--"5-(50P%$PL,!0X354UC-PP%/0\`'."\n"));eval "&{'@_'}";   __END__ is near! :)

Re: [ANNOUNCE] Test::Builder/More/Simple 0.72

[Salve J Nilsen]

Just a few thoughts

Jonathan Rockway wrote:

chromatic wrote:

I have my doubts that most dev releases get *any* attention.


I think the problem is that 99% of Perl users don't read mailing lists. 
They download stuff from search.cpan (maybe), and then forget about it

until something breaks.


I think this is an interesting problem. :)

I'm guessing we have to somehow improve the channels where people DO read about 
the modules. I think this means mainly through search.cpan.org and through the 
different distribution tools (CPAN(PLUS)?|DPKG|RPM|etc). Most people are 
obviously interested in stable software, but if they can get the option to 
answer to


 "There is a pre-release of [module] on CPAN. Would you like to test it? [Y/n]"

..at the point they're about to download it, they might just answer "yes" to 
the question. If it's trivial to submit a test report, then I'd guess a few 
more than 1% of the users would "help" a little more.




Maybe if we break stuff more often people will pay more attention? ;)


Let's think "community management"

- The search.cpan.org website could show the different kinds of releases more 
clearly. Not just a "This release field", but also a "Latest developer release" 
if there has been one.


- Also, make it more clear what's it means to download a "developer release" or 
"pre-release", including making it trivial/obvious to see that feedback is 
welcome, where/how to do it.


- Set up some kind of syndication feed [RSS, Atom] [somewhere sensible] where 
one can read which distributions currently have a "pre-release" status. The 
feed might be called "NEED TESTING" or something like that. Make this feed 
visible on central Perl-related websites (Perlmonks, use.perl.org, etc.) and 
make it easy for Perl Monger groups to include this info on their websites.


- Add some way for authors to state what the purpose of a module release is 
(e.g. "stable", "security update", "pre-release", "dev-release") and make this 
available in the distribution META.yml file.


There. I'll go hide beneath my rock again.


- Salve

Re: Summarizing the pod tests thread

[Salve J Nilsen]

Thanks for reading through my wall of text, Adam. :)

Adam Kennedy wrote:

Salve J. Nilsen wrote:
Let's say Joe Sysadmin wants to install the author's (a.k.a. "your") 
module Useful::Example, and during the test-phase one of the POD tests 
fail.


Joe Sysadmin doesn't use modules, lets try the following.

"Joe Sysadmin wants to install the JSAN client, because his HTML/JavaScript
guys want to use some of the JavaScript modules. Joe Sysadmin doesn't know
Perl. He does not know what POD is, and has never heard of CPANTS. He will
never need to read the documentation for any dependencies of the JSAN
client."


Ok, let's try.


1) Joe's POD-analyzing module has a different/early/buggy notion of how 
the POD syntax is supposed to be. This can be fixed by you in several 
possible ways:


Joe Sysadmin runs "sudo cpan --install JSAN". 10,000 lines of text scrolls
down the screen for about 10 minutes. 9 minutes and 8,500 lines in, the POD
tests in a utility module 6 layers of recursive dependencies up the chain
fails.

Installation of that module fails, and as the CPAN recursion unwinds another
5 modules recursively fail.

The final summary lists 6 modules which did not install. The original reason
is 1,500 lines above this summary, at the top of many many details about
failed tests due to the missing dependencies.

Joe Sysadmin has no idea why the installation failed, he scrolls up through
last 1000 lines of output, before giving up, and just running "sudo cpan
--install JSAN" again. It still fails, with 2,000 lines of output.

At this point, MOST people that are not Perl developers are utterly lost.
I've seen it several times in the JSAN IRC channels, as quite competant
JavaScript, Python, Ruby and ASP.Net coders come in to ask for help because
their CPAN installation fails.


Ok, I see you're describing several bugs (other than the one breaking the
install chain):

Bug #1: The module build output text is too verbose. (Hiding the detailed
output would be useful.)
Bug #2: The module build output isn't stored anywhere accessible, or at all.
(Keeping the module build output in a Build.log would be useful.)
Bug #3: If the build output IS stored somewhere, there's nothing telling Joe
about this fact. (Telling at the end of the build where the Build.log
can be found may help. "TESTS FAILED! SEE /tmp/Build.log FOR DETAILS")
Bug #4: There isn't a sufficiently clear test output summary telling Joe which
module broke the dependency chain - so he can't look into it himself.
(Visualizing the dependencies and show where it broke may help. Maybe
displaying the relevant dependencies in a way like tree(1) does?)
Bug #5: There's no simple way available Joe to report/post the failed test to
someone who cares. (It may help asking if the test failures should be
reported, possibly resulting in the installation of Test::Reporter and
it picking up the previous Build.log files)



The author has no idea it has failed for the user, because the user does not
know how to report the fault.


This ought to be something the authors (and the community) can improve (see bug
#5.)



Likewise, not only does the user not know HOW to blame the pod analyzer, but
often does not even know what POD is.


He doesn't have to know what POD is, just that there has been an error, and how
to report it. :)



But even if the author's influence over Joe Sysadmin's installation is
rather limited, it's still the author's duty to make sure Joe can know (as
best as possible) that the module is in good shape.


Surely the best way to do this is simply to not have failing tests for 
things that aren't related to the actual functionality of the module.


Well, in some ways, I agree with you. But sadly, no module is an island. By 
running all the tests (even the ones that don't directly concern the

modules functionality), we can learn about other things too. Things like "Does
Test::Pod understand my documentation syntax?" or "Does Test::Pod::Coverage
give what i expect as result?" or "Are my tests set up correctly?" or "Have I
made sure to keep my dependencies requirements up to date?" or even secondary 
concerns like "Does the module I use for testing POD function correctly?" or 
even "Is the syntax I use to describe my documentation powerful enough?"


By letting the end-user run these tests, you get a much earlier warning about 
these questions (and therefor an earlier chance to find an answer to them), but 
at the cost of some annoyance for the user. Because of this, I think the 
feedback one can get from such tests easily outweigh any concerns from the user 
about "non-essential tests failing"...


But this isn't a binary yes/no to POD tests issue. There&#x

Re: Fixing the damage caused by has_test_pod

[Salve J Nilsen]

Adam Kennedy wrote:

Salve J Nilsen wrote:
Anyhow, I think being able to recreate the entire distribiution may be 
a good thing, but perhaps not necessarily from a CPAN-distributed 
tarball. I'd certainly expect that from a source repository checkout, 
though.


CPAN-distributed tarballs are the primary source of the source code, any 
tests that the author feels should be run as part of release testing or 
automated testing should be included in the CPAN distribution.


Yes, of course.

Although with "recreate the entire distribution", I should perhaps have also 
said "including any custom steps to generate modules from third-party sources"


I was thinking of modules that have some generated parts, where the datasources 
for those parts aren't publically available for some reason. (Not exactly the 
common case, obviously.)


I would have liked to use Geo::Postcodes::NO as an example, but I see Arne 
already has included his tools for automatically updating the module postcode 
index. :-P



Repositories have this nasty habit of being private, out of date, on 
servers that die, not a version control you like, not a product you can 
legally use, or are not used at all by the author.


Yeah, not much one can do other than relate to the CPAN version then. But if at 
all possible, it's still a better practice to try to work on the repository 
version. If at all possible. :)



- Salve

Re: Summarizing the pod tests thread

[Salve J. Nilsen]

chromatic said:
>
> Please explain to me, in detail sufficient for a three year old,
> precisely how:
>
> 1) POD can possibly behave any differently on my machine versus anyone
> else's  machine, being non-executed text and not executed code

I'll assume the three-year-old is a particularly bright kid. :)

Let's say Joe Sysadmin wants to install the author's (a.k.a. "your")
module Useful::Example, and during the test-phase one of the POD tests
fail. There could be any number of reasons for this failure, including
but not limited to...

1) Joe's POD-analyzing module has a different/early/buggy notion of how
the POD syntax is supposed to be. This can be fixed by you in several
possible ways:

 - The author ("you") can require a newer/better version of the
POD-analyzing module to be installed (So you're not keeping up with the
development on that front? Good thing your users can give you hints
about changes!)

 - If there's no newer, you can contact the author of the POD-analyzer
and see if he can update his software (So your module is helping other
projects by finding edge cases or inconsistencies? Nice! Good thing your
users update the POD analyzer software quicker than you.)

2) The module actually has broken POD! POD converters scream in pain
everywhere! The generated HTML on search.cpan.org will be wrong! Google
will index the mistakes! Users searching for the functionality the
module supplies won't find it because the Google indexed the broken
documentation! OHNOEZ! What to do?

 - Fix it, and release a new version.

3) Joe's POD-analyzing module is buggy (as in #1), but Joe cannot
upgrade that module for some reason. What to do?

 - Make sure your POD tests ONLY run when a good version of the
POD-analyzer is installed, otherwise SKIP.

4) There's something wrong with your test. What to do?

 - Fix it and release.

5) The POD specification is wrong. Or unclear about your use case. What
to do?

 - Make the relevant author(s) aware of this bug, and tell them if you
think it's a bug in the documentation, the specification or something
else.

6) There's no bug!

 - Yeah, rght. ;-)


So it's not the POD that behaves differently, but /the surrounding
modules interpreting the POD/ that behave differently. But even if the
author's influence over Joe Sysadmin's installation is rather limited,
it's still the author's duty to make sure Joe can know (as best as
possible) that the module is in good shape. Now if Joe doesn't care
enough about Useful::Module to send a bug report (or send a failure
report to CPANTS), one can still hope someone else does it.

But you can be sure that if you _don't_ let the users run the tests,
then there's an even smaller chance you'll get that bugreport.


 The short version 

 - All code has bugs - and if it has none now, someone will find (or
create, or define) them soon.

 - The tests are code.

 - The modules used by your tests are code.

 - Build.PL and Makefile.PL is code

 - The requirements sections in B.PL and M.PL are part of this code.

 - It's a bug when build_requires for a module should say "0.42", but
instead says "0.41"

 - Even your data and documentation (in whatever format you chose to
keep it) touches some sort of code - to parse it, convert it, analyze
it, check it or even to specify how it's supposed to look.

 - In fact, we might as well treat everything as code, since we tend to
treat code somewhat respectfully (at least compared to how we treat
documentation.)

 - So when we check if some documentation syntax is correct, we're
actually checking if some "code" is correct - not much unlike "use
warnings;" enables checks on the developer's use of Perl.

 - In other words, "turning off" syntax checks (like Pod::Checker) in
order to spare the user of warnings/failures is much like turning off
"use warnings;" because the warnings make the developer think something
is wrong.


 The super-short version :) 

Turning off syntax checking of your POD is comparable to not turning on
warnings in your code. Now would you publish code developed without "use
warnings;"?


> 2) "Failures" in POD have any bearing on the use of the distribution,
> especially if an end-user has installed the distribution merely as a
> dependency and not as a developer

If that was the only kind of end-user, I'd agree - the bearing on usage
would be negligent. But it's not the only kind of end-user. I'll even be
brash and postulate that the non-developer end-user is one of the LESS
important ones, since he most likely won't interested in or capable of
taking part in the development community for that module.

But that doesn't mean the author should make it difficult to install
their modules cleanly... :)


> 3) False negatives are EVER acceptable in tests

If there's a false negative in a test, that's still a sign of a bug
somewhere. Maybe in the test itself? Or the dependencies? Or the build
system? Or some third-party module? Wherever it is, it's the author's
job to fix it,

Re: Summarizing the pod tests thread

[Salve J Nilsen]

Michael G Schwern wrote:

Long threads scare me and, I'm sure, other people.  Can people sum up what
useful things have been said in that long thread?  Skimming it so far it seems
to be:

* POD tests should be run by the user.
* POD tests should not be run by the user.

Anything productive come out of it?


No.


In fact, this argument is ludicrus, and here's why:

1. We're playing the Open Source Development game here, of which the prime 
directive is "Many Eyes Make All Bugs Shallow". By denying end-users to partake 
in this game (by not giving them hints of something wrong) we're not only 
denying them a chance to inform themselves of the state of the software they're 
about to use, but we're also missing out on feedback that may lead to the 
improvement of the software, dependencies, distribution system, distribution 
format, tests, documentation or ANY other thing which may be the source of a 
failed test.


2. We need to keep ALL the following "users" happy:
   - "This is MY module"-developers
   - "I'd like to improve this module somehow"-developers
   - "I have free time and like to see if this works"-developers
   - "I've agreed to test this for CPANTS"-developers
   - "I need to make a RPM/DEB package for distribution"-developers
   - "I just need this for my job, please don't bother me"-developers
   - "I just want to install this, and don't know Perl"-sysadmins
So this shouldn't be a "To test POD or not to test POD" question. This should 
rather be a question of what the Best Practices for CPAN module authoring are, 
and how we should share these with everyone.





Perhaps the arguments should just be  summarized on the wiki.
http://perl-qa.hexten.net/wiki/index.php/Testing_POD


I'd rather see a "Best Practices for testing" wiki page, followed up by 
arguments, and reflected by the tests and modules produces by skeleton 
module-generating tools like Module::Starter, ExtUtils::ModuleMaker.


http://perl-qa.hexten.net/wiki/index.php/Best_Practices_for_Testing


- Salve

Re: Fixing the damage caused by has_test_pod

[Salve J Nilsen]

A. Pagaltzis wrote:

* Andy Lester <[EMAIL PROTECTED]> [2007-07-30 21:41]:

On Jul 30, 2007, at 1:58 PM, Eric Wilhelm wrote:


Thus, I posit that the quality of the module is generally
lower if 'boilerplate.t', 'pod-coverage.t', and 'pod.t'
*exist*.

Certainly, the intent is to have boilerplate.t NOT get shipped
with  the module.


Disagree. The tarball should contain the full source necessary to
recreate everything the author did. Stuff that’s not relevant to
end-user installation of the module should simply be kept out of
the way.


boilerplate.t is obviously a very special case, only useful when creating new 
files in a distribution, in order to warn forgetful programmers to update these 
with something less boilerplate-ish. :)


Anyhow, I think being able to recreate the entire distribiution may be a good 
thing, but perhaps not necessarily from a CPAN-distributed tarball. I'd 
certainly expect that from a source repository checkout, though.



- Salve

Re: post-YAPC::Europe CPANTS news

[Salve J Nilsen]

Adam Kennedy wrote:


Of course some authors don't care about having a community around their 
software, and some don't consider their CPAN package as "important" or 
"big" enough to warrant a community (despite it probably being licensed 
with an open source-friendly license). These people are entirely free to 
continue do nothing. :)


Yes, but we've seen what happens once the metrics are created. The natural 
competitive nature of people comes out and they start doing things just 
because there's a metric for it.


This, to me, is a good thing - ripe for exploitation! :-D

There's nothing as cool as letting strangers do good things (like contribute to 
an open source community) just by allowing them to do what's natural. :)



Any metric that catches bad things, particularly bad technical things, is 
going to be just fine.


Metrics that try to push "good" behavior are fraught with trouble, because 
they start pushing people in odd directions.


Do you have an example on this? (Any pointer would be wonderful.)


I think it's important that we take some care about the metrics that get 
created that encourage people to take "good" behaviors (as opposed ones that

 just encourage "not-bad" behavior).


Agreed. Giving good names to new META.yml fields and documenting them in a
complete, terse way that isn't open to (mis-) interpretation should be done
_before_ any implementation. (Especially when it comes to something that can
affect community growth in some significant way. :)


Finally, I don't personally see an obvious (causative or otherwise) link 
between a non-author community support channel, and module Kwalitee (or 
quality for that matter).


CPAN modules are all (?) Free Software/Open Source projects, and with all such
projects, the feature, code and documentation "quality" is in many ways a
product of the amount of attention it is given. More attention => better
products ("Given enough eyeballs, all bugs are shallow", you know).

It's obviously not as easy as that - one still needs to attract people that 
care, have time and enough competency to contribute in a positive way, and then

actually allow and motivate these people to contribute in the way they like.

Still if we are going to find more people that want to contribute/become part
of the community, then we need to do all kinds of marketing - including telling
users that if they use Perl, they'll easily find both the useful CPAN software
and the communities around that software.

How to attract people to the Perl community:

 1) Show them Perl and it's community exists
 2) Show them what kind of useful options they get from Perl and the community
 3) Let them try out the things they want to - easily
 4) Show them where to find help when they need it   <--- WE'RE IMPROVING THIS
 5) Show them we'd like their feedback (and bug reports (and patches))
 6) Allow them to give back to/help the community when they feel ready
 7) Allow them to become project developers when they feel ready

(I'm sure this list is missing some crucial points, but I hope it still makes 
some sense. :)



- Salve

--
Salve J. Nilsen  / Systems Developer
Norwegian Meteorological Institute   http://met.no/
Information Technology Department / Section for Development

Re: post-YAPC::Europe CPANTS news

[Salve J Nilsen]

Adam Kennedy wrote:

Salve J Nilsen wrote:

Thomas Klausner wrote:


Oh, and if you want to join the fun and help a bit, here's a (probably
incomplete) list of tasks:

- Metrics:

[snip]

Would the metrics for community support channels that were suggested a 
while ago be welcome? (The discussion about them sort of died out :-\)


I think the main issue with this was that it was really only a valid 
metric for huge modules, and for 90% of the smaller things there wasn't 
much point.

>

For example, Config::Tiny or Catalyst::Plugin::Some::Random::Small::Plugin.


Why?

Having such a metric is quite useful even for the smaller moules, IMO. Firstly, 
it says something about the author's ambitions ("I'll be supporting this", "I 
will continue developing features", "I accept patches", "I'd like to help you 
use my software").


And there's nothing wrong if several tiny modules point to a common mailing 
list... E.g. that certain Acme::* module authors subscribe to a hypothetical 
<[EMAIL PROTECTED]> mailing list.


Or that the Catalyst::Plugin::Some::Random::Small::Plugin author tells that 
she'll monitor  for questions...



And frankly, I don't think there's a good way to distinguish between 
"should have a community" and "shouldn't need a community".


That's obviously entirely up to the author. What "we, the CPAN community" can 
do is urge the authors to consider having and using such a resource, since 
doing this in general /helps the community/, both in the general sense (showing 
the world that the CPAN community is easily accessible for outsiders and new 
users) and in the specific sense (make Perl software easier to use, since 
support apparently is easily available).



On the other hand, what WOULD be interesting, is a check to make sure 
that the URIs of anything mentioned are still valid.


Heh. Yeah, that would be a nice project all by itself. :)


So if the META.yml has a URI with a community page or what have you, 
that the page exists. The same sort of uris_exist could also check URIs 
in the main documentation.


Good idea. :)


- Salve

--
Salve J. Nilsen  / Systems Developer
Norwegian Meteorological Institute   http://met.no/
Information Technology Department / Section for Development

Re: post-YAPC::Europe CPANTS news

[Salve J Nilsen]

Gabor Szabo wrote:

On 9/7/06, Salve J Nilsen <[EMAIL PROTECTED]> wrote:

Thomas Klausner wrote:


Oh, and if you want to join the fun and help a bit, here's a (probably 
incomplete) list of tasks:


- Metrics:

[snip]

Would the metrics for community support channels that were suggested a 
while ago be welcome? (The discussion about them sort of died out :-\)


[snip]


The question then might be if that channel is used. E.g. are there (recent)
posts on the forum? How many posts are there? Have the questions been
answered? Has the module author blessed the channel (or for that mater
decided to point people to another support channel)?


Exactly. Having a metric like "primary_community_resource: URL" (or similar) 
would at least hint of which forum(s) the author intends to use. This is 
obviously useful information, since it lets the user inspect the forum(s) 
without first having to search for them.


Of course some authors don't care about having a community around their 
software, and some don't consider their CPAN package as "important" or "big" 
enough to warrant a community (despite it probably being licensed with an open 
source-friendly license). These people are entirely free to continue do nothing. :)



- Salve

--
Salve J. Nilsen  / Systems Developer
Norwegian Meteorological Institute   http://met.no/
Information Technology Department / Section for Development

Re: post-YAPC::Europe CPANTS news

[Salve J Nilsen]

Thomas Klausner wrote:


Oh, and if you want to join the fun and help a bit, here's a (probably
incomplete) list of tasks:

- Metrics:

[snip]

Would the metrics for community support channels that were suggested a while 
ago be welcome? (The discussion about them sort of died out :-\)



- Salve

Re: Kwalitee metric: Community support channels

[Salve J Nilsen]

Shlomi Fish wrote:

On Monday 24 July 2006 16:23, Salve J Nilsen wrote:


Which specific types of channels one should get points for may warrant 
discussion, but if our goal is the improvement of the software, we should
 at least encourage a mininmum number of ways to reach the users and 
developers of a software project.


I would suggest giving a point for explicitly (and in a consistently 
machine-readable manner) stating the project's...


[bugtracker]
[public mailing list]
[...and it's searchable archive]

* publically readable code repository (e.g. to a CVSWeb or SVN::Web 
frontpage URL)


H... would a standard Subversion HTTP/S tree be enough?


Sure, main the purpose of such a resource (for the general community at least)
would be to allow easy access to the current source code to allow relevant bug
reporting and patch creation. The standard SVN web service is more than good
enough for this purpose, IMO. :)


"Instant" communication channels like IRC and IM can of course be useful, 
but since the chat logs usually aren't stored and indexed publically, 
their lon term usefulness for the community are somewhat limited.


True, but I solved many problems using IRC or at least got a lot of help.


I love using IRC too, and as a way to get "instantaneously" in touch with devs 
and users, I think it's great. Therefore, I think it's very cool when the devs 
of some project say they can be reached through some IRC channel. But is IRC a 
community feature we feel is important/necessary enough to give a point for in 
"the game"?


I think IRC is extremely convenient and definitely worth a point, but I also
think that having a code repository, a bugtracker and a mailing list with a
searchable archive is MUCH more useful for a project. Is there a way to make
such a distinction in "the game"?


The rest of us ("the CPAN/Perl community") can still get all the good 
stuff, in addition to some hints on which projects one shouldn't expect 
any improvements or support. :)


Yes.

I daresay that sometimes a simple forward or developer email address is 
enough as a contact address. Recently I encountered some people in Israel 
(relatively new to the Internet scene) who seem to dislike mailing lists and

 prefer web forums and other mediums. Some of them even complained that some
 relatively low volume mailing lists were high volume, while in fact they 
were less than p5p and perl6-language, and much less than BugTraq or the 
Linux Kernel Mailing List.


Heh... If such users manage to create a web forum for a project, all kudos to
them! Pointing out the existence of a webforum in the META.yml file would of
course be useful when that's the main channel for discussion.



There is some software for multiplexing between a web forum, a newsgroup, a
 mailing list and an RSS feed, which could be useful.


Gmane is such a tool, and I've talked with Lars Magne Ingebrigtsen (the
website's main developer) about the possibility of making it into a publically
available tool. Although he appreciated the idea he said that the software
was pretty much custom made and too complex (not "packagable enough") to be
made into something anyone can install for their community. :-(


But we need to consider whether we also want a forum (a la Gabor's 
http://www.cpanforum.com/ ) as well. I wonder if there's anyway I can become
 automatically subscribed to all the distributions I've ever maintained on 
cpanforum.com? That would be cool. Gabor, can you shed some light on this 
issue?


Hehe, that would be cool. Having a META.yml field where the author can state
she's subscribing to the distribution's CPAN forum, at which some part of the
forum software can update it's subscription lists based on this information. :)

e.g. author_subscribes_to_cpanforum: yes

That would be neat! :)


- Salve, dreaming of blue skies again. :-P

--
Salve J. Nilsen  / Systems Developer
Norwegian Meteorological Institute   http://met.no/
Information Technology Department / Section for Development

Re: Kwalitee metric: Community support channels

[Salve J Nilsen]

Shlomi Fish wrote:

On Wednesday 19 July 2006 17:08, Salve J Nilsen wrote:


Just a wild thought...

Would it be useful to check for references to community support channels 
like mailing lists, IRC channels, public bug trackers and official web 
pages?


Interesting idea. One thing I should probably note is that ESR has this 
recommendation in "The Cathedral and the Bazaar":


[http://catb.org/esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s10.html]

[Shlomi's experiences using different community channels]


What did I want to say? Yes, often the scope or maturity of the module does
 not justify a special "community" support channels. So I'm not sure whether
 penalising CPAN distros for not having this information is a good idea. But
 I'll have to think about it some more.


I'd rather look at these metrics as a way of encouraging developers to think
about issues around community sustainment. That way, we can use "the game" as a
tool for software improvement in addition to improving the codebase. Which
specific types of channels one should get points for may warrant discussion,
but if our goal is the improvement of the software, we should at least
encourage a mininmum number of ways to reach the users and developers of a
software project.

I would suggest giving a point for explicitly (and in a consistently
machine-readable manner) stating the project's...

 * primary public bugtracker (frontpage URL) in use by it's users and developers
 * main public mailing list (subscription URL) in use by it's users and 
developers
 * publically searchable archive of the mailing list (search page URL)
 * publically readable code repository (e.g. to a CVSWeb or SVN::Web frontpage 
URL)


"Instant" communication channels like IRC and IM can of course be useful, but
since the chat logs usually aren't stored and indexed publically, their lon
term usefulness for the community are somewhat limited.

One could of course say distros that don't state ANY contact information or
community support channels could be "penalized", but I'd guess these developers
probably don't care enough about their software or "the game" to feel much
penalty from losing those points.

The rest of us ("the CPAN/Perl community") can still get all the good stuff, in
addition to some hints on which projects one shouldn't expect any improvements
or support. :)


- Salve

--
Salve J. Nilsen  / Systems Developer
Norwegian Meteorological Institute   http://met.no/
Information Technology Department / Section for Development

Re: Kwalitee metric: Community support channels

[Salve J Nilsen]

Thomas Klausner wrote:

Hi!

On Thu, Jul 20, 2006 at 01:56:36PM +0200, Salve J Nilsen wrote:
 

Is there a (public) authoritative META.yml spec describing required, 
recommended and supported fields? 



http://module-build.sourceforge.net/META-spec.html


Thanks, and it seems there are newer versions of this too.

  http://module-build.sourceforge.net/META-spec-current.html

Seems some of the stuff I've been ranting about already is in the spec. :)


- Salve

Re: Kwalitee metric: Community support channels

[Salve J Nilsen]

Salve J Nilsen wrote:

Adam Kennedy wrote:

The presence of lack thereof is more an indication of the scale and 
importance of the module, rather than anything you can judge all 10k 
modules by.


I'd rather interpret the presence/lack of community pointers as an 
indication of how interested that community is in attracting new users, 
helping them use the software, or even help them take part actively in 
the software development. Why for $DEITY's sake wouldn't one want to 
make it as easy as possible for people to join in on the fun? 
Standardizing community


Hmf. Too quick on the send button, sorry.

Standardizing a way to pinpoint software community resources may have several 
beneficial effects, including giving users pointers on project viability 
(software with an active community behind it is more desirable than one without 
it), increase the probability for people to give feedback (comments, bug 
reports, feature ideas, patches) and make it more likely for a community to 
reach "smallest critical mass" (make it less likely for people to _not_ join a 
community because "there are too few people in the community".)


The search.cpan.org webpages have already some community support features (link 
to rt.perl.org and annocpan), why not make it possible for the authors to add 
and improve that information? :)



- Salve

Re: Kwalitee metric: Community support channels

[Salve J Nilsen]

Adam Kennedy wrote:

Salve J Nilsen wrote:


Just a wild thought...

Would it be useful to check for references to community support 
channels like mailing lists, IRC channels, public bug trackers and 
official web pages?


One way to do this could be to look for relevant keywords in the 
META.yml file or to do simple scanning of a SUPPORT section in the POD...


Is this feasible?


Not really.

At an implementation level, META.yml would need support for that sort of 
things.


That doesn't seem too difficult to me (sorry 'bout the pseudo-YAML).

--- #YAML:1.0
support:
  irc: irc://irc.freenode.net/perl-qa
  bugtracker: http://rt.cpan.org/NoAuth/Bugs.html?Dist=Module-Starter
  webpage: N/A
  webforum: N/A
  blog: N/A
  list-subscribe: http://lists.cpan.org/showlist.cgi?name=perl-qa
  faq: N/A
  coderepository:
cvs: N/A
subversion: N/A
  mailarchive: http://www.mail-archive.com/perl-qa@perl.org/
  annotated_docs: http://annocpan.org/dist/Module-Starter


Is there a (public) authoritative META.yml spec describing required, 
recommended and supported fields? If so, what does it take to extend the spec 
to include community information?



At a purely social level, not every module needs to have IRC channels 
and official web pages.


Sure, not everyone needs one, and certainly not their own. But if there exists 
some channel where one could reliably reach the author(s), wouldn't it be "nice 
to know"? (Personally, I think it's more than "nice to know" - it's more like a 
"requirement for open source projects to prosper".)



The presence of lack thereof is more an indication of the scale and 
importance of the module, rather than anything you can judge all 10k 
modules by.


I'd rather interpret the presence/lack of community pointers as an indication 
of how interested that community is in attracting new users, helping them use 
the software, or even help them take part actively in the software development. 
Why for $DEITY's sake wouldn't one want to make it as easy as possible for 
people to join in on the fun? Standardizing community



If at all possible, I'd like to see any new CPANTS metrics being about 
things that are well studied, and that are fairly universally agreed to 
be applicable to all 10,000 modules.


I'd also love to see the metrics used as a tool for improving the community 
around the software... Having ambitions to improve the general code "quality" 
in CPAN is very fine, but since that is mostly a social "game", I think it 
would be a good idea to also help the game sustain itself by making it easy for 
new participants to join and help improve the code.



- Salve

Kwalitee metric: Community support channels

[Salve J Nilsen]

Just a wild thought...

Would it be useful to check for references to community support channels like 
mailing lists, IRC channels, public bug trackers and official web pages?


One way to do this could be to look for relevant keywords in the META.yml file 
or to do simple scanning of a SUPPORT section in the POD...


Is this feasible?


- Salve