cpanvote: dist/module & yea/nay/meh
Olaf Alders
Thought I'd break this up into a new email so as not to bring up too many issues in the same thread.
A couple of things which I wanted to go over with you.
A) As far as yea/nea/meh goes, what is the actual significance of meh? I can think of a few things:
i) I don't have an opinion dist
ii) I'm not familiar with this dist
iii) I'm trying to negate an accidental yes/no vote I cast initially
I can see the use for it as a way to negate a miscast vote, but I would also think that a vote in the other direction could serve the same purpose:
Accidental click to upvote -> following downvote removes the initial upvote -> second downvote then casts an actual downvote
I'm not even sure if that's a good workflow, but I guess I'm wondering where the value is in tracking the "meh" votes. I'm curious to hear what you had in mind.
(On a purely pedantic note, I believe it's nay rather than nea: http://en.wikipedia.org/wiki/Nay)
B) I have a couple of comments on dists. First off, let me just say the Twitter auth works beautifully on this. I *really* love how easy the whole authentication process is. :)
Now, on CPAN itself, I see the voting on a page like this:
http://search.cpan.org/dist/HTML-Restrict-0.06/
However, in practice, I rarely see that URL pattern. Where I do end up is:
http://search.cpan.org/~oalders/HTML-Restrict-0.06/
So, I think it would be helpful to add that URL naming scheme for dists as well
C) This brings up a related point about whether voting should apply to dists or to releases/versioned dists. I think the version of the dist is largely irrelevant. If you downvote a dist now, but a later release makes you fall in love, you can change your vote. No need to track votes based on exactly when the vote was cast. That would be my feeling anyway, but it's something that could be debated
D) Modules vs Dists
In our initial conversations in Toronto, it became evident pretty early on that even folks who spend a lot of time on CPAN are not clear on the difference between a module and a dist. I don't blame them, because it's not that clear at all. Which brings me to ask whether we want upvoting strictly for modules, strictly for dists or for some combination of the two.
Maybe you really want to upvote DBIx::Class::Manual::Cookbook, which is part of DBIx::Class. That's your way of saying, "this is an important module in this dist" or this documentation is better than some of the other DBIC docs. Is this something we should support? Or is it a use case which is better taken care of with module bookmarking?
Bookmarking could function in a similar way, but it allows me to distinguish between modules I like and modules I need to find easily at some later date.
I think that's enough questions for tonight. :) Your hard work is paying off very nicely. If you're OK with a move to the cloud, let me know and I'll set you up on the server and contact you offlist with login details etc.
Best,
Olaf
Yanick Champoux
On 11-01-29 12:30 AM, Olaf Alders wrote:
> A) As far as yea/nea/meh goes, what is the actual significance of meh? I can think of a few things:
>
> i) I don't have an opinion dist
> ii) I'm not familiar with this dist
> iii) I'm trying to negate an accidental yes/no vote I cast initially
>
> I can see the use for it as a way to negate a miscast vote, but I
would also think that a vote in the other direction could serve the same
purpose:
>
but I guess I'm
> wondering
where the value is in tracking the "meh" votes. I'm curious to hear what
you had in mind.
Good discussion point, as I'm myself not sure if 'meh' is a brilliant
idea or an example of over-engineering. :-)
My original rational was pretty much along the lines of (i) and (iii).
Basically, it's a state to distinguish "I never voted on that
distribution" and "I voted on this distribution, but can't
recommend/discourage the use of that dist". I see it being useful for
two things:
* with a neutral vote, we cover the case where someone first voted
for/against a module, but then changed their mind, but not enough to
swing to the other side (e.g., the case where I voted on a dist I don't
know by accident).
* knowing what peeps already voted on or not would easy up the creation
of voting widgets. That's something that would help populate our
database. Bored? Go to cpanvote.org/random and discover 10 new
distributions.
> Accidental click to upvote -> following downvote removes the initial
upvote -> second downvote then casts an actual downvote
>
> I'm not even sure if that's a good workflow,
Hmm... I'm not sure either. The thing, if it's done like that, votes
are no longer stateless (a downvote can now results in a score of 0 or
-1), and it doesn't remove the '0' score out of the equation
(internally, the state is still there). If we want to do without the
'meh', I'd say let's make the choice "yea or nay" -- once you spoke up,
you're committed to have an opinion. :-)
> (On a purely pedantic note, I believe it's nay rather than nea: http://en.wikipedia.org/wiki/Nay)
Darn. And the silliest thing is, I checked as I first spelled them
"yeah" and "neah". Darned be that French accent. ;-)
Btw, internally the scores are kept in a more calculation-savvy
"-1/0/1". For the REST interface/UI I've switched to yea/nay/meh
because it looks a little funnier. As everything else, it's open for
debate. We could even be a little bit whimsical and accept a few synonyms:
http://cpanvote/dist/Foo-Bar/vote/nay
http://cpanvote/dist/Foo-Bar/vote/-1
http://cpanvote/dist/Foo-Bar/vote/no
http://cpanvote/dist/Foo-Bar/vote/do-not-want
;-)
> B) I have a couple of comments on dists. First off, let me just say
> the Twitter auth works beautifully on this. I *really* love how easy the
> whole authentication process is. :)
Thank you. :-) Once you get your head wrapped around the ping-pong
game between the application, the service and the browser, it works
quite elegantly. Of course, those who really deserve to be praised are
the authors of Net::Twitter and Catalyst::Auth::Twitter who take care of
the nitty gritty details.
> Now, on CPAN itself, I see the voting on a page like this:
>
> http://search.cpan.org/dist/HTML-Restrict-0.06/
>
> However, in practice, I rarely see that URL pattern. Where I do end up is:
>
> http://search.cpan.org/~oalders/HTML-Restrict-0.06/
>
> So, I think it would be helpful to add that URL naming scheme for dists as well
Totally agree. The GM script only acts on the first variant only
because it was the easiest one to go for to get the prototype working.
Detecting the second variant is not very hard. In fact, I think I
already do it in other CPAN GM scripts. I'll have a peek and update the
script to extend its power. :-)
> C) This brings up a related point about whether voting should apply
> to
>dists or to releases/versioned dists. I think the version of the dist is
>largely irrelevant. If you downvote a dist now, but a later release
>makes you fall in love, you can change your vote. No need to track votes
>based on exactly when the vote was cast. That would be my feeling
>anyway, but it's something that could be debated
Yup, my own sentiments go in the same direction. The important part is
the distribution. We could add a "version" field to the votes as an
improvement, but I propose that, if we do, for a given user we'll only
keep track of the latest vote, as I don't think the added complexity of
having to deal with multiple dist votes for any given user is really
worth it. As Olaf said, if you are in love with version 1.27 of
Foo::Bar, there's not a lot of value in knowing that you hated version
0.05 back then.
> D) Modules vs Dists
>
> In our initial conversations in Toronto, it became evident pretty
> early on that even folks who spend a lot of time on CPAN are not clear
> on the difference between a module and a dist. I don't blame them,
> because it's not that clear at all.
Very good point. And I wouldn't be the one to throw the first stone.
> Which brings me to ask whether we
> want upvoting strictly for modules, strictly for dists or for some
> combination of the two.
>
> Maybe you really want to upvote DBIx::Class::Manual::Cookbook, which
> is part of DBIx::Class. That's your way of saying, "this is an important
> module in this dist" or this documentation is better than some of the
> other DBIC docs. Is this something we should support? Or is it a use
> case which is better taken care of with module bookmarking?
> Bookmarking could function in a similar way, but it allows me to
> distinguish between modules I like and modules I need to find easily
> at some later date.
I'd say that votes should be distribution-wide, as the distributions
are the units of functionality. Ultimately, I think the problem voting
try to solve is answering the question "I want to do [something], which
one should I use, [dist A] or [dist B]?" In that light, it makes little
sense to say "I fully recommend that you use XML::LibXML::Node and
XML::LibXML::Element, but by all means, stay away from XML::LibXML::Text".
From your description, I think that the per-module ear-marking is
indeed more of a bookmarking functionality. Which is also a useful
service, but I see it as orthogonal to the votes. I can easily see cases
where you'd bookmark modules that you are forced to work with, but
wouldn't recommend to your worst enemy. ;-)
And this being said, I think it's a good idea to make the cpanvote web
service dist-based, but smart enough to map modules to their dists, just
like 'cpan', 'cpanp' and 'cpanm' do. It's a little bit of DWIM fairy
dust that will simplify things for everybody. :-)
> If you're OK with a move to the cloud, let me know and I'll set
> you up on the server and contact you offlist with login details etc.
I'm totally OK with it. Hit me with the credentials. :-)
Joy,
`/anick
Olaf Alders
On 2011-01-29, at 3:08 PM, Yanick Champoux wrote:
> Good discussion point, as I'm myself not sure if 'meh' is a brilliant idea or an example of over-engineering. :-)
>
> My original rational was pretty much along the lines of (i) and (iii). Basically, it's a state to distinguish "I never voted on that distribution" and "I voted on this distribution, but can't recommend/discourage the use of that dist". I see it being useful for two things:
>
> * with a neutral vote, we cover the case where someone first voted for/against a module, but then changed their mind, but not enough to swing to the other side (e.g., the case where I voted on a dist I don't know by accident).
>
> * knowing what peeps already voted on or not would easy up the creation of voting widgets. That's something that would help populate our database. Bored? Go to cpanvote.org/random and discover 10 new distributions.
Good point. I think that would be helpful info to have.
>
> > Accidental click to upvote -> following downvote removes the initial
> upvote -> second downvote then casts an actual downvote
> >
> > I'm not even sure if that's a good workflow,
>
> Hmm... I'm not sure either. The thing, if it's done like that, votes are no longer stateless (a downvote can now results in a score of 0 or -1), and it doesn't remove the '0' score out of the equation (internally, the state is still there). If we want to do without the 'meh', I'd say let's make the choice "yea or nay" -- once you spoke up, you're committed to have an opinion. :-)
OK. So that leaves us with options. Or even options for whoever does an implementation. Some could choose to allow the neutral vote, others not. At any rate, I'm sure it will be a point of discussion at some point again.
>
>> (On a purely pedantic note, I believe it's nay rather than nea: http://en.wikipedia.org/wiki/Nay)
>
> Darn. And the silliest thing is, I checked as I first spelled them "yeah" and "neah". Darned be that French accent. ;-)
>
> Btw, internally the scores are kept in a more calculation-savvy "-1/0/1". For the REST interface/UI I've switched to yea/nay/meh because it looks a little funnier. As everything else, it's open for debate. We could even be a little bit whimsical and accept a few synonyms:
>
> http://cpanvote/dist/Foo-Bar/vote/nay
> http://cpanvote/dist/Foo-Bar/vote/-1
> http://cpanvote/dist/Foo-Bar/vote/no
> http://cpanvote/dist/Foo-Bar/vote/do-not-want
I'm all for whimsy!
> Now, on CPAN itself, I see the voting on a page like this:
>>
>> http://search.cpan.org/dist/HTML-Restrict-0.06/
>>
>> However, in practice, I rarely see that URL pattern. Where I do end up is:
>>
>> http://search.cpan.org/~oalders/HTML-Restrict-0.06/
>>
>> So, I think it would be helpful to add that URL naming scheme for dists as well
>
>
> Totally agree. The GM script only acts on the first variant only because it was the easiest one to go for to get the prototype working. Detecting the second variant is not very hard. In fact, I think I already do it in other CPAN GM scripts. I'll have a peek and update the script to extend its power. :-)
I thought it might be something like that!
>
>> C) This brings up a related point about whether voting should apply
>> to
>> dists or to releases/versioned dists. I think the version of the dist is
>> largely irrelevant. If you downvote a dist now, but a later release
>> makes you fall in love, you can change your vote. No need to track votes
>> based on exactly when the vote was cast. That would be my feeling
>> anyway, but it's something that could be debated
>
> Yup, my own sentiments go in the same direction. The important part is the distribution. We could add a "version" field to the votes as an improvement, but I propose that, if we do, for a given user we'll only keep track of the latest vote, as I don't think the added complexity of having to deal with multiple dist votes for any given user is really worth it. As Olaf said, if you are in love with version 1.27 of Foo::Bar, there's not a lot of value in knowing that you hated version 0.05 back then.
I'm with you 100%.
> I'd say that votes should be distribution-wide, as the distributions are the units of functionality. Ultimately, I think the problem voting try to solve is answering the question "I want to do [something], which one should I use, [dist A] or [dist B]?" In that light, it makes little sense to say "I fully recommend that you use XML::LibXML::Node and XML::LibXML::Element, but by all means, stay away from XML::LibXML::Text".
For sure. This makes sense.
>
> From your description, I think that the per-module ear-marking is indeed more of a bookmarking functionality. Which is also a useful service, but I see it as orthogonal to the votes. I can easily see cases where you'd bookmark modules that you are forced to work with, but wouldn't recommend to your worst enemy. ;-)
Exactly. It still has a lot of value, though, as it would be interesting to see what people choose to bookmark.
>
> And this being said, I think it's a good idea to make the cpanvote web service dist-based, but smart enough to map modules to their dists, just like 'cpan', 'cpanp' and 'cpanm' do. It's a little bit of DWIM fairy dust that will simplify things for everybody. :-)
I had not thought of that, but that too, will be very helpful.
>
>
>> If you're OK with a move to the cloud, let me know and I'll set
> > you up on the server and contact you offlist with login details etc.
>
>
> I'm totally OK with it. Hit me with the credentials. :-)
Excellent! Can you send me a public SSH key off-list?
Best,
Olaf