[KuraFire]

Originally Posted by futureal

A rating system would need to be adjustable as future incarnations of a hack arrive. If a bug-ridden 1.0 is replaced by a stable 1.1 (or whatever) then it may not deserve the potentially shoddy rating it received at the onset.

The rating system doesn't have to be adjustable really, because we will give out this 'award' for only one (main) version of a Hack at a time. If the Hack is buggy at 1.0, it will simply not receive the Quality award. If the Hack at 1.1 is rewritten to have no more bugs (or no apparent ones, at the very least), the hack author can re-submit it for approval and we will then review it again. If at this point the Hack does indeed no longer have bugs, and is secure (no security leaks or dangers), and is running stable (doesn't randomly hog the server resources, or 'crashes'), it will be taken through a rating system for several criteria, and if it then scores well enough on those as well, it will be given the Quality label. If later on, then, a version 1.2 of the hack is released, it will have to be reviewed all over again, before we'll give the 1.2 version the Quality label.

Originally Posted by futureal

Feedback should be appreciated by any hack author (I know I appreciate any that I receive) but I am not sure that public critique is such a good idea (beyond the rating). If it were up to me, I would leave that private for the hack author. Having somebody put a lot of work into something only to see negative comments from experienced coders in public is not going to encourage them to keep working on it. Especially because something that takes me 20 minutes might take someone else 4 hours, or might take Chen 53 seconds, and so on. The chance of people thinking that other, more experienced hackers are "talking down" to them is high.

After reviewing of a Hack, the hack author will be told (regardless of whether or not the Hack was approved) what aspects of coding s?he could still improve upon.
We will aim as much as possible to not be condescending in that, so that people don't get the feeling we're talking down to them or anything. We want to make this system to encourage people to improve their coding skills, and we know that acting all stuck-up and what not is not going to help with that, so we'll make sure to be supportive, friendly, and down-to-earth.
It's good that you pointed it out though. :up:

Originally Posted by futureal

I think a publicly viewable stability rating (or whatever you want to call it) would suffice, along with private comments to the author about why such a rating is deserved and what he/she can do to improve upon it.

The Public will only see one thing: QA Approved: yes/no; (no can also mean it simply has not been submitted for approval).
The Hack Author will see two things: QA Approved (duh), and what areas s?he could still improve upon. This will be referenced using an extensive document will lots of useful tips and guidelines.
The Quality Assurance team will see whether it's been approved or not, will see what areas the hack author could improve upon, and see in a little more detail how the rating process has gone. The latter is important to have for when we encounter hacks where one Team member thinks is -just- good enough to Qualify, and another Team member thinks it's comes a little short.


At least, that's planned so far... if any member sees a problem with that, please tell! It's why we made this thread - to get everyone's opinion on it