vBulletin 3 Hacks & Quality Assurance at vB.org

[Erwin]

With the RC1 release of vBulletin 3 coming closer, the Staff at vBulletin.org wishes to raise the standard of code in Hacks released here. vB3 Hacks will soon be allowed here, and it is of great importance to us that the quality of Hacks goes up a notch. In the past (with vB2-hacks), plenty of hacks have been released here on vBulletin.org containing security loopholes, unnecessary queries, and overall bad code.
To raise the standard of Hacks, we are thinking of implementing a system where experienced, skilled and well-respected vB Hackers are selected to review vB3 Hacks released here at vB.org. This will come in a two-level flavor - a basic review that will be made for every single hack that is released, and a far more in-depth review (upon request).
Especially the second (and far more thorough) level of the system will allow end-users to easily spot the more reliable Hacks on the site, as the second level approval means it is a secure, well-coded, well-optimized, easy to install and overall good quality hack.

This system will hopefully encourage hackers to raise the standards of their coding. Obviously this is voluntary - no one is forced to follow the recommendations of this review team. The basic review that is applied on all Hacks is mostly to make sure that beta-quality hacks don't get posted as full releases, and other such things.

The rating criteria are not set in stone already, we're making this announcement so that we know what YOU all are interested in and find important etc.
We already have some ideas in mind. However, we wish to have input from the members too. In particular, we want to get suggestions for the following:

a) Criteria used to rate
b) What points sytem to use
c) What rating scale to use


Give us as many of your thoughts as possible on this, and we, the Staff, will put our heads together. The more you people can come up with, the better. Who knows, we may just end up with some really nice system that everyone just loves! It all depends on how well you all can think up useful ideas.

We hope that this will improve our community and the quality of hacks released, which will be good for everyone in the end. :)


Keep in mind that this will be site-wide for vBulletin 3 Hacks only, not vB2-Hacks. This does not mean that you can no longer release vB2 hacks, this only means that the rating system will not apply to them.

[Andrew111888]

I think that's a great idea, Erwin.:)

By doing this, hacks will become even better and with a good team of hackers reviewing them, they will tie in is as well as possible with the standard code. I fully support it.:D

[assassingod]

Excellent idea. Having people rate the standard of hacks will greatly improve the quality of future hacks:)

[Dan]

With the RC1 release of vBulletin 3 coming closer, the Staff at vBulletin.org wishes to raise the standard of code in Hacks released here. vB3 Hacks will soon be allowed here, and it is of great importance to us that the quality of Hacks goes up a notch. In the past (with vB2-hacks), plenty of hacks have been released here on vBulletin.org containing security loopholes, unnecessary queries, and overall bad code.
To raise the standard of Hacks, we are thinking of implementing a system where experienced, skilled and well-respected vB Hackers are selected to review vB3 Hacks released here at vB.org. This will come in a two-level flavor - a basic review that will be made for every single hack that is released, and a far more in-depth review (upon request).
Especially the second (and far more thorough) level of the system will allow end-users to easily spot the more reliable Hacks on the site, as the second level approval means it is a secure, well-coded, well-optimized, easy to install and overall good quality hack.

This system will hopefully encourage hackers to raise the standards of their coding. Obviously this is voluntary - no one is forced to follow the recommendations of this review team. The basic review that is applied on all Hacks is mostly to make sure that beta-quality hacks don't get posted as full releases, and other such things.

The rating criteria are not set in stone already, we're making this announcement so that we know what YOU all are interested in and find important etc.
We already have some ideas in mind. However, we wish to have input from the members too. In particular, we want to get suggestions for the following:

a) Criteria used to rate
b) What points sytem to use
c) What rating scale to use


Give us as many of your thoughts as possible on this, and we, the Staff, will put our heads together. The more you people can come up with, the better. Who knows, we may just end up with some really nice system that everyone just loves! It all depends on how well you all can think up useful ideas.

We hope that this will improve our community and the quality of hacks released, which will be good for everyone in the end. :)


Keep in mind that this will be site-wide for vBulletin 3 Hacks only, not vB2-Hacks. This does not mean that you can no longer release vB2 hacks, this only means that the rating system will not apply to them.
wonderful idea Erwin..... :D

[Preech]

I feel it's a good idea.
I plan on jumping on the VB3 hacks release bandwagon myself. As a upcoming PHP Coder.

[KuraFire]

Come on guys, we want your input on this, not just praise for the idea! Thoughts, Ideas, Comments, Criticism!!! Let's hear it! Anything at all?

Oh, and it wasn't only Erwin's idea, y'know :p

[PixelFx]

Sounds good, I've been getting my manual out, so I can make my code look nicer ;)

[Logikos]

I fully support it. I think a 1 to 10 scale is just fine. I think it would be best if it was right down to the wire in the rating system. Like 7.6 Rating not just 8. Im sure you know what i mean, im a bit tired myself. lol

There should also be an area where not so great coders can post hacks too as well. Of course with this in mind, making sure all users know that this isnt the best coded hack.

[trekwarfare]

Just kind of a thought I think would make it easier for peeps who aren't experts in PHP (I'm getting there, but by no means ready to code my own). With the downloads for each hack, maybe have some sort of rating/feedback system, one where you could on a scale of 1 to 10 rate various components of the hack, and to go with that, also have a comments section for each rating, like if you give installation a 7.8, explain why it wasn't a 10 (or why it was a 7.8 for that matter).

That might help identify more problem areas within a certain hack. I've seen a few that are easy to install, but required a lot of self coding to get going and then only to find out down the road it would generate some problems(*cough* Karma 2.0 *cough*).

just my 2 cents though

[N9ne]

Good idea, although with a rating system, be prepared to see it abused, people hate people (that's human nature) and they will have fights with the rating system, inevitable.

Other than that, sounds good, and partly encouraging to the lesser experienced PHP programmers who will see this as an opportunity not only to have their work evaluated but to also advance and hone their PHP skills.

[Velocd]

The ratings aren't going to be made public, so that should ease some of the verbal abuse in competitions.

[Xenon]

\[]emesis']I fully support it. I think a 1 to 10 scale is just fine. I think it would be best if it was right down to the wire in the rating system. Like 7.6 Rating not just 8. Im sure you know what i mean, im a bit tired myself. lol

There should also be an area where not so great coders can post hacks too as well. Of course with this in mind, making sure all users know that this isnt the best coded hack.
noone will stop users from releasing hacks, even if they are bad coded.
it should just be visible to users that a hack is problematical/easy/good coded/well optimized or something like.

[N9ne]

The ratings aren't going to be made public, so that should ease some of the verbal abuse in competitions.
That's ok then.

As for the rating system, I think a % would be suitable, if not, scale it down to x / 10.

[KuraFire]

That's ok then.

As for the rating system, I think a % would be suitable, if not, scale it down to x / 10.
Again, ratings themselves will not be made public, not to the hackmaker nor to the general public of vB.org.

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. :)

[sigh]

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!

[TECK]

noone will stop users from releasing hacks, even if they are bad coded.
it should just be visible to users that a hack is problematical/easy/good coded/well optimized or something like.
Thanks Stefan, exacly my point.
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.

[assassingod]

Thanks Stefan, exacly my point.
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.
Yeah, stopping the author view the comments makes no sense because it then defeats the purpose of the system:confused:

[NTLDR]

Yeah, stopping the author view the comments makes no sense because it then defeats the purpose of the system:confused:

Its my understanding that hackers will be shown where they have gone wrong and pointed in the right direction so they learn from their mistakes and can improve :)

[Erwin]

TECK, please PM me. Did you get my email? You have PM disabled so I cannot PM you.

[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.

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.

[Erwin]

Keep the suggestions coming. :) We want the members to have input in to this system as it will affect the whole community.

[Vile]

Excellent idea indeed :)

[KuraFire]

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.

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:

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 :)

[futureal]

Kura: I guess what you are saying is a bit different than what others had said earlier in the thread. Having a simple Yes/No Approved seems like a better idea to me than a percent-based rating. Either it meets the standards or it doesn't.

As far as public comments, I still agree that the Quality Assurance team should communicate with the author in private.

This whole system sounds like a nice idea for the end user, but risks making it more complicated and less friendly to the hacker. Part of what I like about vb.org is that there are tons of different ideas implemented in tons of different ways here, and anybody is free to do it. I wouldn't want to see this system "crowding out" some of the guys who come in just to write one hack here or there.

The other risk is that you are making the process more complicated. Just like my opinion of the hack subforums: the more unnecessarily complex things become, the less useful they become.

This is a good idea, it just needs careful implementation.

[ap0c]

Kura: I guess what you are saying is a bit different than what others had said earlier in the thread. Having a simple Yes/No Approved seems like a better idea to me than a percent-based rating. Either it meets the standards or it doesn't.

As far as public comments, I still agree that the Quality Assurance team should communicate with the author in private.

This whole system sounds like a nice idea for the end user, but risks making it more complicated and less friendly to the hacker. Part of what I like about vb.org is that there are tons of different ideas implemented in tons of different ways here, and anybody is free to do it. I wouldn't want to see this system "crowding out" some of the guys who come in just to write one hack here or there.



This is a good idea, it just needs careful implementation.
I agree with the QA team discussing any issue with the author in private. People take comments the wrong the way at times. Maybe a standardized form should be filled out by the QA team and sent to author with basic comments and if the author has questions or simply disagrees with what the QA team "thinks" is the correct way to script something, the issue would be better handled in private. The less public arguements between hack authors and a QA team the better, imo for this site and people( end users) in general.

[KuraFire]

Discussions between Hack Author and QA Team concerning the submitted / approved / unapproved Hack will always be in private.

The rating criteria Erwin mentioned in the first post are for QA team in-house, the results of a review of a hack will not be made public via those. This to prevent endless bickering about details that aren't as important as the big picture: approved, yes or no?

[colicab-d]

grrrrr - eat as tony would say :D good idea chaps :D

[Jayk]

I think this is a great ideal.

Also if it can use laymen terms as far as descriptions wrt install. I muttled through a chat hack, got it to work but it took a while.

Great ideal and vision, kudos

[MindTrix]

I love the idea Kura suggested about a step by step guide to creating a hack beeing written up! Im sure it will be VERY usefull to newbie/wannabe hackers like me.

Request--

When vB3 hacks are released can we have them shown on the front page like the vB2 ones are? I was thinking of a column next to the vB2 one, but i guess it might look out of place.

[Xenon]

the vb3 hacks will be visible on the homepage yes.
most likely within the same window, we'll see

[KuraFire]

Stefan, perhaps a better idea would be to make vB3 hacks appear in the same column as the vB2 hacks, but underneath or above it, so that people can easily distinct between them without us having to add [vB3] or [vB2] to each thread title. :)

[Bison]

I got here a bit to late to review all of the threads written here and I don't have the time to do this but I'll throw in my two cents on this subject:

There is a definite need to create a rating system for hacks at this forum. In the past, there have been many modified versions of the same hack ... some just a bit more prettier than it's predecessor. Most of them riddled unnecessary queries. This is what I believe ... created too many help tickets at vb.com, and most of the problems were related with what we have been producing here.

Think that there should be two separate categories ... if a hacker doesn't submit his hacks to the rating team, his hacks should be allowed, but put in a category that tells members that this hack was not reviewed by the rating team. This will leave it up to the user to decide if they want to install this hack. The other category lists the hacks that have been reviewed and graded for functionality ... and rated accordingly.

If the hacker doesn't like thier score, they have the option of requesting that their hack be removed from this list so that they can make the necessary changes to bump up their rating. They have to apply the reccommended changes that came from their previous review in order for the hack the be re-released to the reviewed forum.

Am I making sense?

[LightBringer]

Great idea, but a question does come to mind.
Resources required to review the hacks.

With as quickly as hacks are released around here, do you guys have all the peeps necessary to keep the ebb of flow going to the community so A: We're not waiting around for months for an in-progress hack, and B: Support for those hacks are still given in a timely manner?

[KuraFire]

I got here a bit to late to review all of the threads written here and I don't have the time to do this but I'll throw in my two cents on this subject:

There is a definite need to create a rating system for hacks at this forum. In the past, there have been many modified versions of the same hack ... some just a bit more prettier than it's predecessor. Most of them riddled unnecessary queries. This is what I believe ... created too many help tickets at vb.com, and most of the problems were related with what we have been producing here.

Think that there should be two separate categories ... if a hacker doesn't submit his hacks to the rating team, his hacks should be allowed, but put in a category that tells members that this hack was not reviewed by the rating team. This will leave it up to the user to decide if they want to install this hack. The other category lists the hacks that have been reviewed and graded for functionality ... and rated accordingly.

If the hacker doesn't like thier score, they have the option of requesting that their hack be removed from this list so that they can make the necessary changes to bump up their rating. They have to apply the reccommended changes that came from their previous review in order for the hack the be re-released to the reviewed forum.

Am I making sense?
Yeah you are, but whenever a Hack is not approved, the Hack author can fix the flaws in his/her Hack and just re-submit the new version for approval again, already. :)

So what you suggested was already part of the plan. \o/
(which makes it a good suggestion ;))


I don't think we want to make too large a distinction between approved and unapproved hacks, though. Too much segregation ;D is not productive for people's spirits. :)

[KuraFire]

Great idea, but a question does come to mind.
Resources required to review the hacks.

With as quickly as hacks are released around here, do you guys have all the peeps necessary to keep the ebb of flow going to the community so A: We're not waiting around for months for an in-progress hack, and B: Support for those hacks are still given in a timely manner?
We're working on that :)

Keep in mind that even Hacks that are in the queue will be visible on the list and can be used and have support etc. :)

[Princeton]

For usabiltiy purposes...
I believe that all new hacks should be placed in a BETA HACK forum. If the percentage of 'yea' votes are higher then the 'nea' votes (80/20) then an automatic move to the HACK forum is enabled. (cron job)

If a hack is found in the HACK forum, a member shouldn't be obligated to look for approval. It should be assumed that it has been approved.

The BETA HACK forum should exist for purposes of bringing out quality hacks and quality coders.

[alkatraz]

having 2 levels or whatever is a great idea!

[KuraFire]

For usabiltiy purposes...
I believe that all new hacks should be placed in a BETA HACK forum. If the percentage of 'yea' votes are higher then the 'nea' votes (80/20) then an automatic move to the HACK forum is enabled. (cron job)

If a hack is found in the HACK forum, a member shouldn't be obligated to look for approval. It should be assumed that it has been approved.

The BETA HACK forum should exist for purposes of bringing out quality hacks and quality coders.
Not a very viable option because that would mean that we are to either review every single hack that is released, and thus it's sort of an enforcement (ie. hack authors have no choice anymore about whether they want their hack reviewed or not). That, or we are to not review any hacks at all, which defeats the whole purpose of this plan.

Letting normal members approve of a hack with votes is not a reliable way of defining whether the Hack is safe to use or not. Best example would be Lesane's Store Hack. That would easily get a ton of votes, but that doesn't make it a safe-to-use Hack.

We're putting this together to provide a 'safety label', a 'quality label' if you will. Hacks that are QA-Approved are thusly reliable that you can be sure of it that if you install the hack, someone will not be able to break into your admin panel through some security leak that the Hack created.

[Princeton]

Here's what I think should be done:
NEW RELEASES should be APPROVED HACKS. All hacks are sumbitted into BETA HACKS forum for review/approval. Judges and members review hacks to make end-product optimized and approved. Upon approval hacks are "moved" to APPROVED HACKS. Judge's comments are highlighted (using vbcode so that coders/members) can distinguish who is a judge. Not a very viable option because that would mean that we are to either review every single hack that is released, and thus it's sort of an enforcement (ie. hack authors have no choice anymore about whether they want their hack reviewed or not). That, or we are to not review any hacks at all, which defeats the whole purpose of this plan. The "rating" system does not necessarily have to be open to all members. I never said it should. On the other hand, the BETA HACKS forum SHOULD be open to ALL members (which it is). By entering BETA HACKS forum, a member already assumes that hack may not be up to par. If a hack is submitted in BETA HACKS forum any member can use such hack at their own discretion. At the same time, "judges" will not have a backlog of reviews to implement at any one time. Isn't the BETA HACKS forum available to coders for such a review? Will judges install and test all hacks? This system will make any hacks immediately available to everyone. BECAUSE, at any one time you cannot gaurantee that all "judges" will be available. As the saying goes, anthing can happen. Furthermore, any hacks not approved may discourage authors to submit additional hacks or requests a review. At the very least, submitting such a hack into the BETA HACKS forum will allow authors to improve such hack using recommendations from everyone especially the "judges". Upon approval, not the coder; but, "judges" may move such hacks to APPROVED HACKS. As ADMINs:
You should think about the workload. You should think about usability. You should think about how people behave/react. All criticism is good for coders. A critique made for one coder can and will help other coders. However, a guideline should be created on "how" to critique. We do not want people to degrade others or feel degraded. There should be a defualt beta hacks questionaire for judges; and, answers should be visible on hack page (showthread) with comments on how to improve. I believe, also, there should be a usability factor. Not to determine "approval"; but, to make aware to all users who are not familiar with what is usable. How usable is this hack? There should be a "probationary period" for members who are found to go against these rules. To let a member know that they are in probation, admins should change style to reflect a "probationary period". For example, a red highlighted border on page; and, for usabiltiy purposes the written words "You are in probation ... read more here" with a heading style. It will be used as a reminder to what could come after --> BAN. Here's a scenario:
Upon the release of VB3 RC1 an influx of new hacks will be submitted for approval. Why? Because, all coders want to release a clean and optimized hack. Will your reviews be available instantly? Or, will coders have to wait-in-line to get such approval? And, will such hack be available online without a seal-of-approval?

[Catch-22|BL]

Peer review? Please just make sure you have some good reviewers! ;)

Let me depart from the existing discussion and just reply to Erwin's request for comments.

I propose six hacking levels (tongue in cheek):

Rust
Iron
Bronze
Silver
Gold
Platinum


I propose this flowchart (half-kidding):

1. Someone submits a hack.

2. Important: When a hack first submits his/her code, they should identify if they are dumping the code (as is) or if they are sticking around. Is it okay for other people (with credit provided) to modify or "adopt" their hacks if they vanish?

3. A qualified person does a clean install to see if the thing even works. This person should also be familiar enough with vb.org to spot duplicates and blatant rip-offs.

4. If it does not delivered promised function, the hack is put in the Rust (disfunctional hacks) category.

5. If it works, the qualified person estimates the relevance and it is either put in the Iron (appears to function but is really just a trivial tweak) or Bronze (appears to function and has some significance). Note the Iron category is good enough for most custom requests that will only be used by a handful of people. No further reviews are necessary for Iron level and that is as far as it goes for those hacks. Insignificant hacks do not merit the time or energy. If by some miracle an Iron hack starts getting dozens of installs, someone can always bump it up to Bronze.

6. Bronze hacks can either stay at that level or the hacker can request an upgrade to Silver status. If the hacker requests the status upgrade, some very qualified people review his/her code and observes what happens when the first few people start installing the hack. A couple weeks in the shark tank will let you know if a new hack is poorly optimized or messy. If the hack is found to be fully functional and sufficiently optimized, the hack is sent to the Silver level. If not, the hack stays Bronze and the hacker is told to either abandon his/her request or improve the hack.

7. After a month at Silver, the hacker can request an upgrade to Gold. Unless flaws have appeared, it should be simply a check to see if the hacker is supporting the hack and addressing comments from the community. Aftercare is the measuring stick for Gold.

8. Once at the Gold level, it should be automatic that the hack works on the current version of software and the zip file should be a self-contained unit. Combing through support threads that are hundreds of posts long should definitely not be necessary. Things should by tidy.

9. Any Gold level hacks that reach a certain number of installs can be automatically promoted to Platinum (highest level). Platinums hacks should be functional, significant, sufficiently optimized, well-maintained and popular.

10. Important: Hacks need to be reviewed and perhaps demoted on a regular basis. If a hacker stops supporting his/her Gold hack, it should be dropped back down to Silver. If there are so many upgrades that a hack loses function or relevance, it should be moved to a lower priority.




Before you laugh too hard, think about it....basically any person who stumbles across a decent idea and is willing to humbly revise his hack (sometimes under the guidance of others) while remaining persistant can proudly proclaim they have a Gold level hack. Quality over quantity, baby. ;)

[dniMTheory]

YIKES!...all this sounds good on paper but by the time RC gets released and this gets put into play, it could be summer already.

Everyone is not a perfect coder and some are still learning. I say filter all the hacks through the beta forum until it is confirmed that it is ready to be released. Who needs a code rating and who wants someone to micro manage their hacks.

i'm not totally downing the idea, I just think some of the suggestions of how it should work are overkill. I say we keep it as simple as possible.

There has emerged atleast 3 other hacking sites since the betas have come out. Do we really want that one awesome hack to be an exclusive on another board because the author got ++++ed because he got a silver rating for not being able to offer support? <---not a good case to argue but you get my point.

I say we keep it simple and encourage innovation or however you spell it. How many "points systems" or "you need x amount of posts" to do this are we gonna see.

[integra99]

What if the Approved forum is only open for admins/mods to post in. Make everyone post in the beta forum, and when an experienced hacker thinks its ready, let him move the thread

[dniMTheory]

Forget my last post....I thought this was an overal view of all posts. Not just security.

If its just security we are talking about, can we just have green and red images beside the hack somewhere. green means it's safe, red means its bad.

[BigJohnson]

will hacks be able to be posted when Vbulletin goes GAMMA?

[integra99]

will hacks be able to be posted when Vbulletin goes GAMMA?
Would you want to spend hours and hours making something then have to turn around a few weeks later and redo it? If you want a hack now so bad, make it yourself. Otherwise, quit wasting bandwidth and my time posting. That would be super, thanks.

-Colin

[Gio Takahashi]

will hacks be able to be posted when Vbulletin goes GAMMA?
BigJohn, vB is expecting the release of vB3 in late november, no hacks will not be released until then. I believe the vB developer wishes that as well, you should read the front page news before you ask.

[BigJohnson]

I did read but vb.org said once vb hits RC1 you can then release hacks. Now that vb.com said it wont be RC1. It will prob be GAMMA they said. So I am asking if hacks will be able to be released for the GAMMA here at vb.org

[Gio Takahashi]

vb.org still states that hack will be released once RC1 is released, gamma doesn't change that fact. ;)

[Erwin]

vb.org still states that hack will be released once RC1 is released, gamma doesn't change that fact. ;)
Gio is correct.

[Gio Takahashi]

Besides, according to vB and jelsoft, Kier says that RC WILL be released before end of 2003, so you have 95% chance that vB3 will be released in December.

[poolking]

Would you want to spend hours and hours making something then have to turn around a few weeks later and redo it? If you want a hack now so bad, make it yourself. Otherwise, quit wasting bandwidth and my time posting. That would be super, thanks.

-Colin
Just browsing through, is there any need to be rude?

[MuSuL]

Im pretty new around here but the first post should set the standard here on this thread!...Im sick and tired of installing hacks, then having to come back for help and help is not given by the creator!...

In this up coming week I will be removing about 3 full hacks which the creators have not responded to help questions in the last 2 months...I don't want to use a hack that will not have support or is not working properly....

I support all hacks and the creators of their hacks, but PLEASE follow thru with what you create!

This is the only and best site to get hacks, just wish there was a standard or a set of rules to govern what is created and support....

Hats off to all who have gave up their time to others to better the system...now lets get the ball rollin and keep it high...

MuSuL

[Erwin]

A lot of the hackers have lives outside of vB. :) So they may not have time to answer questions in their hack threads, especially if the question has been answered before.

We used to have a tag that stated whether the hack author would support the hack or not. Maybe we need that back...

[Xenon]

yes we will need that Back ;)

[VAN]

Interesting concept, but I'd like to add a little...err..a lot. :D

When posting a new hack, offer an option to the hack writer to have it "certified". This would basically be the in-depth inspection mentioned in the first post..but it wouldn't be free. If someone writes a hack and wishes for it to be "certified" as functional and secure, they can have it looked over by by a qualified person for a small fee...a couple bucks. This fee would go to the person who certifies the hack via Paypal. Perhaps smaller fees for super simple hacks.

The couple bucks is a small amount to pay to have a hack certified, but for someone who knows what they are doing, they could certify a few hacks a month and earn some spending money, or money to pay for their cable internet. Of course in order to be able to certify hacks, you would have to prove yourself a worthy coder.

So here's how I think it should work...

Member goes to post a new hack...
They choose whether or not to have it certified by a "professional".
If they choose yes, then the hack gets posted to an area only accessible to those members that have been designated to be able to certify new hacks, and an overview of the hack gets posted to a "waiting for cert" section viewable by all members. (this would prevent someone from attempting to code something that is already in the pipeline for release)

Those people that are able to certify hacks would have a section that lists all hacks currently requiring certification, and they can then choose which hack they want to work on. They would only be able to certify one hack at a time. The person who certifies a hack would also be responsible for providing support for that hack, since during the inspection process, they would know the code as well or better than the original writer. After the hack is certified, they are paid via Paypal and the hack gets posted with a "certified" icon. Payment not sent? Hack not posted. Simple.

If the hack writer chooses to not have his work certified, it gets posted immediately with an "as is" and "not certified" warning, and people can download and install it at their own risk, with support offered when possible.


This pay-for-certification system would benefit everyone. The hack writer would get piece of mind knowing that his hack is worthy of a "certified" icon, and can begin work on new projects while support for his certified hacks is provided by someone else.

The certifier benefits financially for his time and work.

The end user benefits by having the choice to only install certified hacks and gets piece of mind knowing that certifed hacks will always be supported.

Additionally, it would be great if anyone could pay to have a hack certified. For example...

Member XXX posts a really great hack, but for whatever reason chooses not to pay to have it certified. Member ZZZ loves the hack concept, but is nervous about installing a non-certified hack, so member ZZZ can "sponsor" the certification process by paying for it himself.

Just my thoughts. I for one would have no problem in paying a small amount for the piece of mind in knowing that what i'm about to install wont cause security issues or conflicts.

[KuraFire]

This will not be a paid system. We're aiming to raise the overall quality of hacks with this, not to segregate and create a sort of "elite hacks" vs "plain hacks" system.

Moreover, payment for Hacks is not allowed on vB.org, and as far as I gather from vB.org and vB.com Staff, your proposal would fall under that mention and thus not be allowed to begin with.

[Catch-22|BL]

A lot of the hackers have lives outside of vB. :) So they may not have time to answer questions in their hack threads, especially if the question has been answered before.

We used to have a tag that stated whether the hack author would support the hack or not. Maybe we need that back...


Yes, I think there should be more made of the fact that most hackers are freely sharing their modifications and doing so in their spare time. It is frustrating to see support threads where hackers are criticized and attacked by people who do not even know if they have access masks enabled or not. This rudeness might discourage good people from contributing more hacks.

Since vb.org is starting fresh with vb3, it might be good to become less tolerant of people who badger hack creators and make a nuisance demanding (not suggesting) additional features. A hack is a hack, IMO. Take it as a free gift or just leave it alone. We are all administrators and should have some mutual respect for each other.

My mindset is that "authenticated" hacks should be presented in a way where a person of reasonable skill and caution can successfully install it. And maybe you can ask for volunteers who (with permission) would like to be caretaker of other people's hacks once the original hacker moves on?

PS. Yes, I know I have too much to say....but if feedback is solicited, I will give it! ;)

[KuraFire]

My mindset is that "authenticated" hacks should be presented in a way where a person of reasonable skill and caution can successfully install it. And maybe you can ask for volunteers who (with permission) would like to be caretaker of other people's hacks once the original hacker moves on? The Ease-of-Installing aspect of a hack will matter when we review Hacks. Something that is very nicely made but a complete B!tch to install, will possibly not be QA Approved because of that.

On the whole, though, there are ways to ensure that your hack is easy to install for people. One such way is by using the Hack Tracking Log (https://vborg.vbsupport.ru/showthread.php?t=57860) to create your hacks. Tons of benefits come with that, one of which being the Installer Routine that comes with it, which will allow you to generate installer files that others can use, similar to Chen's vBHacker, but then taken to far higher levels of usability, ease of use, functionality, etc.


oh, and we're very happy with your feedback! :) Keep it coming! ^_^

[VAN]

This will not be a paid system. We're aiming to raise the overall quality of hacks with this, not to segregate and create a sort of "elite hacks" vs "plain hacks" system.

Moreover, payment for Hacks is not allowed on vB.org, and as far as I gather from vB.org and vB.com Staff, your proposal would fall under that mention and thus not be allowed to begin with.

I wasnt suggesting that anyone pay for hacks. I was suggesting a small fee be paid to the individual who validates and certifies a hack. Similar to the way your Service Requests forum operates.

[KuraFire]

I wasnt suggesting that anyone pay for hacks. I was suggesting a small fee be paid to the individual who validates and certifies a hack. Similar to the way your Service Requests forum operates.
I know, I got what you were suggesting. But that's still a paid system for the Hack author him-/herself.

Ahwell, it's not just my decision only or anything, but I can't see the benefits of making this be available only to those with money to spare, when our goal is to raise the quality of ALL hacks released here. Involving money in one way or another will create a `niche market`, pretty much, so that would defeat the purpose of all this. The Service Requests forum is for those with mucho $$$, not for your average joe hacker on this site (which is 95% of the userbase).

[kippesp]

I prefer 5-point scales where 3 is average, 4 is above average, and 5 is well above average. (And if it is decided to have a 10-point scale, I'll just give ratings of 1, 3, 5, 7, 10.) Having an example of what qualifies would be helpful.

It'd also be nice to separate the criteria. So have a rating for documentation & implementation. But don't go overboard on this and have an "ease of installation" rating--otherwise the complex hacks would, by definition, have a lower rating. And who really cares about something subjective like that--what is trivial to one person may be confusing to another.

[KuraFire]

I prefer 5-point scales where 3 is average, 4 is above average, and 5 is well above average. (And if it is decided to have a 10-point scale, I'll just give ratings of 1, 3, 5, 7, 10.) Having an example of what qualifies would be helpful.

It'd also be nice to separate the criteria. So have a rating for documentation & implementation. But don't go overboard on this and have an "ease of installation" rating--otherwise the complex hacks would, by definition, have a lower rating. And who really cares about something subjective like that--what is trivial to one person may be confusing to another.
We're currently working hard on balancing out all the criteria and how important they really are for the Hack. It's quite a pickle indeed, as we have to cater to all people between 100% n00b and 100% masterful coder. But, we're doing the best we can and it's starting to look real good, now :)

[poetic]

is vb.org gonna offer vb3 hacks when gamma comes out???

[sabret00the]

.com asked them not to as altho the style will be inplace the backend is alteast another build from nearly final

[Gio Takahashi]

poetic, it is stated in the announcements forum that when the vB3 RC is out, vB.org will then allow the hacks to be released, Gamma is Gamma, not Release Candidate.

[poetic]

ok sorry i just thought that gamma was pretty much RC1 just before it or something lol i thought they just wanted to rename it

[KuraFire]

vBulletin.org is at liberty to allow vB3 Hacks with the release of Gamma. However, Kier said that he would prefer it if they waited for RC1 instead, and the Admins of vBulletin.org decided (either on their own or due to Kier's request, I dunno) to wait for RC1 with allowing vB3 hacks.

So that's early december, then :)

[Gio Takahashi]

From what vB says, they said around Christmas time.

[Weasel]

My only input on this issue is to make sure every hack that uses MySQL queries uses:

" . TABLE_PREFIX . "table AS table

This is because vB3 now supports table prefixes and any hack that does not do this should not be quality assured. That is all 8)

[trafix]

My only input on this issue is to make sure every hack that uses MySQL queries uses:

" . TABLE_PREFIX . "table AS table

This is because vB3 now supports table prefixes and any hack that does not do this should not be quality assured. That is all 8)
There is a lot of new standards in VB3, The MySQL queries are just one of them :)

Other noobs is also the PHP (conditionals) in the templates, url link format and much much more .....

The devs have raised the standard of the overall coding of VB3 and in doing so the standards of the hacks will have to be lifted to comply. All of this will be taken into consideration during the QA process.

[Zach]

I have not read through all of this yet - but its a great idea, and maybe this was already mentioned, or planned, but it seemed the first half of the posts seemed to get to caught up in becoming an English teacher with a red pen.

I think the idea is awesome - but I think that when being reviewed that it should be more looked at not as a review or grading process, but as a finalization process. Most hacks are really not that big. Some are, but most are not. If there is something wrong with it - lets just fix it, give feedback of what was done, why it was done, and then release it as a completely solid piece of work - with no mention of any changes made or not made between submission and release.

The last part would be crucial as otherwise people would be scared of having to much red ink in the public eye - which I think you guys are trying to cover already anyway.

But again - if this process was used to just take out that extra two db calls and tighten stuff up, use more standard variable names, etc, this would be something spectacular for the community. If it became a king on high, you pass, you fail, thing - even if that was kept private to everyone but the person that "failed", it would kill things - it would create a three class system - the judges, the ones that are always accepted, and the ones that always fail. While the guys that didnt get accepted would be only known to that one person - that person is going to notice that some Pot Smoking goody goody (sorry overgrow - I have been around to long and still get a kick out of your forums topic and your importance in this community) - but anyway notice this pot smoking goody goody is always approved, while they are not - - which would start to build up resentment in some, and discourage them from submitting more.

done rambling - just full of my two cents remarks today -

[Zach]

Just finished browsing through the rest of these - and I will say point blank - the direction you are headed scares me - How dumb would it be to send something back to someone because they didnt put table prefixs in? Or something like that - when it takes probably less time to just fix it and get it released - nobody gets hurt, the community benifits by the hack being available, the hack writer gets feedback and knows next time to do that - if the same person keeps doing that, it takes one skim to see that, and the third time just hand it back then and say - "come on dude - we told you the other two times we need these table prefixs in it" just get those added and we will then look at it" - and still say then, that you have not looked at the code all other than to notice they missing prefixes so this is no rejection of anything cause nothing has been looked at.

Got to actually help, and in doing so, as corny as it sounds, inspire others to create more. Need no grading - which leads to praise - which is great - but what about the opposite end. There is no good with out bad in that system. The bad makes the good not worth having.

[Catch-22|BL]

Well, gamma is here and soon all the talking will be replaced with action.

Just a personal thanks to the staff. Your efforts to keep things organized are appreciated. Whatever you do, a percentage of people will complain about it later. At least you tried to solicit opinions. ;)

[DougCooper]

Sounds good guys look forward to seeing what hacks are made for VB3 !

[deathemperor]

yes, vb3 hacks are going to be so great !

[NuclioN]

From what vB says, they said around Christmas time.

Around Feb 2004 was a reply on vb.com http://www.vbulletin.com/forum/showpost.php?p=580474&postcount=8

[deathemperor]

they are not vb staff, I don't believe what they said. also I wanna know when too, but there is no clue for the final, any way, RC1 should be enough :D

[NuclioN]

Why waiting? --> --edit-- wrong url

Kier said ASAP. And the code will only change bugfixes.

[deathemperor]

well, I love the below post of Kier: hackers should start to work now :p
http://www.vbulletin.com/forum/showpost.php?p=581248&postcount=24

[Silverdawn222]

Yeah, I don't understand the VB.ORG policy when Kier so obviously sponsors the starts of hacking. Vb's message to the hackers has no positive effects, and only annoys people still waiting for a postponed RC1 with slighty bugfixes.

[NuclioN]

Not only that silverdawn the RC1 is also not the stable release. There will be bugs...always.

[deathemperor]

Kier also said that RC1 and later version after gamma is only about bugfixes, the gamma is released publicly for people to find bug, that's brilliant :p

[Erwin]

Kier also said that RC1 and later version after gamma is only about bugfixes, the gamma is released publicly for people to find bug, that's brilliant :p
Some bugs can't be found unless many people use the software. :)

[Silverdawn222]

So how does that differentiate Gamma from a final version? Bugs will always continue to exist, as will the fixes for it. If it were up to me, Gamma would be the version where hacks should be getting released (as Kier said).

Of course, it's not up to me.

[deathemperor]

I thought it's good for us to wait for RC1 ( not another chance though :p ), if I'm right, the final will be released with the accpetable bugs as you said bugs will always continue to exist.
same for the RC1, hackers have started their work I think so when the RC1 is released the hacks is accepted along with bugfixes.
Anyway, can't wait for the RC1 since Kier said it will be released in late December, it's almost late :(

[idwf]

i say...

BURN THE WITCHES!!! BURN THEM ALLL!!!!!!!!!

oh, and yes....just wait until RC1. Not toooo long.

[Nam]

Otherwise, quit wasting bandwidth and my time posting.
-Colin

Why wasting your time posting then?

p.s, smiley clickable face doesn't work with mozilla.

[Gary King]

Why wasting your time posting then?

p.s, smiley clickable face doesn't work with mozilla.
Wrong place to report this.

[gopherhockey]

Sounds like RC1 will be out on the 5th (according to recent announcement) - hope vb.org will be ready for hacks - I have certainly been working on some and need lots of help ;)

[Gary King]

Sounds like RC1 will be out on the 5th (according to recent announcement) - hope vb.org will be ready for hacks - I have certainly been working on some and need lots of help ;)
Recent announcements.. I haven't been able to access vB.com for a few days now :(

[ajk]

Hi Erwin,

As usual, I'm late to this discussion.

As a non hacker myself, but I use them in 2.3.3.
Can you make a standard by which all hacks for 3.0 are written?
That way, if the vHacker mod for 3.0 works out, all hacks will be compatible.

I know everyone has their own way of coding.
I just wish there was a standardized format.
Especially with 3.0 RC1 coming closer.

Thanks in advance,

[deathemperor]

I dont think RC1 will be out in 5th ( I really hope so ), there are a huge thread in Vb.com talking about that thing ( look like a war ).
I can't access vb.com these days either :( what's wrong with it ?

[Gary King]

I dont think RC1 will be out in 5th ( I really hope so ), there are a huge thread in Vb.com talking about that thing ( look like a war ).
I can't access vb.com these days either :( what's wrong with it ?
Site is constantly under attack, basically.

[Dark Shogun]

Can you make a standard by which all hacks for 3.0 are written?
That way, if the vHacker mod for 3.0 works out, all hacks will be compatible.

I know everyone has their own way of coding.
I just wish there was a standardized format.
Especially with 3.0 RC1 coming closer.

Thanks in advance,

Probably not because a lot of the hackers here don't like using vBhacker.

Dark Shogun

[Gary King]

Probably not because a lot of the hackers here don't like using vBhacker.

Dark Shogun
Only a small handful of hacks were for vBHacker as well.

[MindTrix]

I dont think RC1 will be out in 5th ( I really hope so ), there are a huge thread in Vb.com talking about that thing ( look like a war ).
I can't access vb.com these days either :( what's wrong with it ?
It will be released on the 5th, its been announced by the vb team :p

[Dean C]

It will "try" to be released on the 5th - don't misquote :)

[MindTrix]

Based upon the rate at which Mike, Freddie, Scott and I are currently dispatching bugs, we believe that we will be ready to put vBulletin 3 Release Candidate 1 in the Members' Area at some point on Monday (January 5th).
Nopes i didnt misquote ;)

[Gary King]

I must say, I wouldn't be surprised if it wasn't released on Jan. 5th.

[MindTrix]

I grudgenly agree but dont knock it, otherwise you will jinx it :)

[Gary King]

True true, I too hope it WILL be Jan. 5th.

[deathemperor]

wow, hehe, GREAT ! 4 days to go, cant wait for the RC1 ^^
I think I should prepare for its delay :p
Happy New Year, people :)

[Gary King]

Happy new years! :D

[Dean C]

"We believe that". ;)

[MindTrix]

Was that sarcasim Mist or do you actually believe its comming out on Monday?

[Gary King]

Was that sarcasim Mist or do you actually believe its comming out on Monday?
He's quoting what the Jelsoft team said isn't he?

[MindTrix]

Ahh yes so he was :)

Well we will all find out monday i guess :)

[sabret00the]

nope today ;)

[ajk]

nope today ;)


It doesn't matter WHAT day of the week it is.

I still can't log in there.

[ajk]

BTW, isn't this discussion getting WAY off topic?

Erwin was talking about the quality and control of hacks.

Now this has turned into a when's the next version discussion???

[poolking]

It doesn't matter WHAT day of the week it is.

I still can't log in there.
email support@vbulletin.com saying you cannot access the site and give them your customer no and the ip address you are trying to access from.

[feldon23]

If it hasn't already been said, Hacks need to be fully phrased before they should be considered for phase 2 certification (or whatever vb.org intends to call it).

[Gary King]

If it hasn't already been said, Hacks need to be fully phrased before they should be considered for phase 2 certification (or whatever vb.org intends to call it).
I definitely agree :)