The Arcive of Official vBulletin Modifications Site.It is not a VB3 engine, just a parsed copy! |
|
#11
|
||||
|
||||
The ratings aren't going to be made public, so that should ease some of the verbal abuse in competitions.
|
#12
|
||||
|
||||
Quote:
it should just be visible to users that a hack is problematical/easy/good coded/well optimized or something like. |
#13
|
|||
|
|||
Quote:
As for the rating system, I think a % would be suitable, if not, scale it down to x / 10. |
#14
|
||||
|
||||
Quote:
A Hack will either be approved or not approved. The Hackmaker will hear which aspects of Hacking/coding could be improved (whether the hack is approved or not), but (s)he will never hear the exact rating / score. Why not? People will always get into arguments when they see a score. There will always be people who disagree with a certain rating, then there will always be others going around saying "my hack is better than yours because I got an 8.1 and you got a 7.5!", then you will have people trying to appeal to a decision and get a second opinion and what not. When you only release YES/NO approved to the public, there is very little to make a fuss about. And that's what we want - we don't want to cause a ruckus for each hack, we want things organized, clear, and useful. A big heated discussion isn't useful, nor well-organized. A set of guidelines on where you can improve on, is. That said, we will also provide an extensive 'document' with help, tips and guidelines on how to make hacks, along with Kier who is writing such a thing already (last I heard). As stated in the announcement, we want to improve the overall quality of all hacks released on vB.org, and we would most like to be doing that without causing a lot of fights/arguments among the crowds. |
#15
|
|||
|
|||
I'm a pretty basic php & MySQL coder - not up to hacking standards, but ok for installing them.
I'd REALLY appreciate this system, since I like adding hacks to my board, but need to keep it stable & secure. Great idea! |
#16
|
||||
|
||||
Quote:
People can release hacks galore if they want to compete in "some" competition... but if we have an input from people with experience, we can decide if we should wait or go for the mod. I will even go one step further. Should we make the author being not able to see the comments? Not sure if it's a good idea... This is with 2 sides... If you don't see the comments of people, you cannot get upset... However, how do you learn then from the coding mistakes? I'm sure you guys will find the right balance for it.... Let me know please. |
#17
|
||||
|
||||
Quote:
|
#18
|
||||
|
||||
Quote:
|
#19
|
||||
|
||||
TECK, please PM me. Did you get my email? You have PM disabled so I cannot PM you.
|
#20
|
|||
|
|||
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.
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. 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. |
|
|
X vBulletin 3.8.12 by vBS Debug Information | |
---|---|
|
|
More Information | |
Template Usage:
Phrase Groups Available:
|
Included Files:
Hooks Called:
|