[ccan] What do we mean by "judging code"

[Adam Kennedy]

I thought I should clear up just exactly what is meant by "judging code".

One of the principles from the CPAN that has been extremely positive is 
the idea of a low barrier to entry.

That is, people should be free to upload anything they like, and we 
should make it as easy as possible for them.

This has a downside of course, much of what gets uploaded to CPAN is 
shit, even from big companies.

The first upload of the official eBay Perl API by the eBay internal 
development group exploded horribly, and they had to do a second release 
immediately to upload one that worked.

However, acceptance of shit is ultimately positive, as it gets those 
modules "into the community" quickly. Those initially crap modules get 
processed by various bits of the CPAN "cloud". They get build and tested 
on multiple environments, they get torn apart by the "Kwalitee" system 
and scanned for positive and negative flags, they get their bug tracking 
queues and "One to five stars" review site entries created, and so on.

A good number of the initially crap uploads get hammered into shape 
AFTER the intial uploads into something positive. Sometimes it takes the 
original author "dissapearing" and a new author taking over to achieve this.

So INITIALLY I think we should be as permissive as possible when people 
are uploading files.

The difference then is what happens after the upload.

There needs to be a clear boundary between what gets initially uploaded 
to CCAN and what actually appears in the CCAN index.

So if someone says "install rusty:some_module" it WON'T get resolved to 
the http://mirrorname.com/ccan/authors/R/RUSTY/some_module-1.23.tgz 
unless that module meets appropriate criteria, and "install some_module" 
won't get resolved to "install rusty:some_module" unless the module has 
both passed the automated criteria, AND has potentially passed through a 
human review process of some sort.

For an idea of what this process can look like, here's a link to my 
author page in the CPAN Kwalitee ( "Kwalitee is not Quality, but it's 
similar" ).

http://cpants.perl.org/author/ADAMK

That page also shows the pitfall of judging systems, which is that they 
fall prey to the preferences of the person writing the judging system.

For example, that big vertical red bar is a judgement test for 
documentation coverage. I strongly oppose that test because of both the 
way it is implemented, and the process it wants you to use to test for 
coverage, which I consider a security flaw.

So it's important that in judging code we be extremely careful about 
WHAT we judge, as we throw up potentially aggressive and devisive barriers.

But the basics like "Is it a tarball, does it have an _info.c file, etc" 
I would certainly consider to be a reasonable minimum threshold to 
uploading at all.

Adam K

Nicolas Greffard wrote:
> Hi folks,
> I am a French student studying in Scotland and I am really interested 
> by one of the project ideas you proposed for the google summer of 
> code. I am currently doing my Bsc honors in computer science at 
> HeriotWatt University.
> The project I am talking about is the "judging code" one. I have some 
> ideas about how I would deal with this project but I need to clear 
> them up. I am going to go through the different modules the repository 
> contains so that I can identify the patterns describing what the code 
> should look like.
> Anyway if some documentation exists about these patterns, I would be 
> really pleased if one of you guys could send it to me.
>
> Faithfully,
>
> Nicolas Greffard aka "Ngreff" on IRC
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> ccan mailing list
> ccan at ozlabs.org
> https://ozlabs.org/mailman/listinfo/ccan
>