Here's what we have so far, all condensed for convenience.


Servers (if someone needs a test bed)
-------
ajk
hirnsub
Spam




Team Applications
-----------------
Omario
michael
throesch
KyleYankan
hirnsub
krikkert
Sonic
Deskdirect
DemonSlayer
Spam
Godrx




Issues
------

To prevent biases (Resolved):

<omario>
1 tester who actually test the mod. he then showd this mod installed on his testboard (like id do it when my servers up) to 1 or 2 other testersto ensure he isnt being biased with his ratings.
</omario>

<KyleYankan>
What if a person likes me likes a Email mod more, then say a counter mod. But someone els likes a counte rmod.
</KyleYankan>

<michael>
It's not a question of who likes what. It's not a subjective score. If anybody is being biased, people will complain quickly enough. We can even setup a complaint form specifically for that. If there's enough convincing complaints, we can have someone else double-check a review in question. If real problems with one reviewer show up, they can be expelled. We should keep a public list of all reviewers updated so that there's no issues with someone claiming to be part of the team when they've been kicked out.
</michael>

Mods to be used on "pre-modded" board (open):

<michael>
Top 3-5 downloaded mods. - Security Fix, Polls, Add More Smilies, Stop Following My d**mn Mouse!
</michael>

More than one author of a mod (Resolved):

<michael>
There's always a main author. Add secondary authors to the description field.
</michael>

<DemonSlayer>
How about an extra field that has the other mod writers and as the stuff
</DemonSlayer>

<XXL>
people should not add their name in addition to the original author in the <author> tag but put their name into the description
</XXL>

<T-master>
Wants extra field.
</T-master>


Public vs. Home Servers (resolved):

<hirnsub>
i think speed is a big point (for example i'm planning to run yabb boards on bigger sites) and i don't know if reviewer should have acces to the install files, cos i'm tryin to work out a fair and standardized way of certification - and we should not only give dua's a hand - we too should garantee fair testing! no homeserver is like the other and how often do we find a personel solution for some probs or own affords on our servers and progs
</hirnsub>

<michael>
Reviewers need to be able to review in whatever way is best for them, as long as they do a thorough review. How the reviewer chooses to go about doing this (on a public server or on a local machine) should be completely up to him/her. Perl interpretation is the same anywhere you go. The only things that will change are variables such as the location of sendmail. Testers will know enough to not let the nuances of their system get in the way of their reviewing.
</michael>

<XXL (Michael Prager)>
public server? I don't see any really need for it, I'm just fine with my local apache. Keeping mod testing as fast as possible is very important, if you have to wait several days to get a simple message that you got a spelling mistake isn't very usefull for authors. So a local test board is the best.
</XXL>




Procedures
----------

<michael>
The basic steps that MUST be completed should be these:

• Mod is installed on a clean board and an already modded board using BoardMod.
• Reviewer tests the new features to make sure they work properly and don't screw up the board.
• Reviewer does a quick check of the code to see if there's any problems that stick out.
• Reviewer checks over Mod title, description, and instructions to make sure they are adequate.

</michael>




Structure
---------

<michael>
New mod would be submitted and added to a queue of mods to be reviewed. For people not willing to wait for review, there would a be a public queue page.

Review form:
Compatibility: 0-5 stars
Code Design: 1-5 stars
Originality: 1-5 stars
Functionality: 1-5 stars

Comments:
<< Pre-fab Comments Here >>
(with checkboxes to select multiple problems)
[ ] Doesn't install properly.
[ ] Code is bloated.
[ ] Code doesn't make enough usage of existing code.
[ ] This has been done before.
[ ] Spelling errors
[ ] Minor bugs (specified below)
[ ] Major bugs (some specified below)
and so on...

Additional Comments:
<< Text box for reviewer to fill in more details if necessary. >>

Accepted mods would be viewable on an "accepted mods" page. Rejected mods would still be available, on a "rejected mods" page.


Ratings:  
1-5 star rating in each category  
1) Compatibility & Install -  
5 stars = installs perfectly on both a clean board and a board that has the mods we've chosen (i.e. polls, etc.). Directions are excellent  

3 or 4 stars = installs perfectly on only one of the two boards, directions are sketchy.  

3 stars or less = minor to massive compatibility problems, poor instructions.

2) Code design -  
5 stars = Efficient (not bloated) code that makes as much use of previously written code as possible and uses all the security and other features of YaBB (such as putting text in English.lng and using fopen, fclose instead of open and close, etc.). Code is formatted (i.e. tab spacing) for easy viewing.  

4 stars = Formatting or conciseness isn't quite as good.  

3 stars = Barely passable code. Formatting is messy and code isn't as efficient as it could be.  

< 3 stars = Terrible code, little or no code reuse, no formatting, etc.

3) Originality -  
5 stars = something totally new.  

4 stars = Something similar was done before, but this mod improves upon it significantly or adds it's own twists. (i.e. a complete rewrite or an old mod cleaned up with new features added)  

3 stars = Improved/updated version of a previous mod, not terribly original (i.e. important bug fixes or a mod converted from Gold Release to SP1).  

< 3 stars = Same exact thing has been done before, as well as or better than the mod being reviewed. OR mod has very minor updates not worth a whole new mod entry.

4) Functionality -  
5 stars = works perfectly to all appearances.  

3-4 stars = Works almost perfectly. Spelling errors, maybe a small bug or two.  

< 3 stars = Destruct-o-matic - doesn't work, possibly causes the board to fail, associated texts are unreadable due to spelling errors or poor english.

Possibly combine Code Design and Functionality.

Review time:  
Mods should take a day or less to test out. If it's too troublesome to install a mod because it doesn't install with BoardMod and there's too many changes that need to be made, just give the mod 1 star for compatibility (i.e. failing grade) and give it "N/A" in the other categories, which is equivalent to ZERO stars! You don't want to have to fuss over installing a mod to review it. It should be quick and easy. Just install it on the two boards using BoardMod, have a glance at the code, try the new things that the mod implements, and submit your rating.

Database layout:
http://www.themikecam.com/mikecam/test.html

Categories:
Maybe a "related mods" section at the bottom of each mod info page. The only thing is that I have no idea how I'd go about coding it. Well, actually, I've a small one, but I dunno. Maybe if we added a field to the mod table that would be filled in if the mod was an add-on to another mod. So, mod X would be submitted. Then when add-ons to mod X (mods Y and Z) are submitted, the author or the reviewer will say the mods Y and Z are add-ons to mod X. Then, when a user views the info for Mod X or for any of it's add-ons, the "related mods" will show a list of the add-ons and such.
Alternatively, we could have subcategories after the main categories (features, cosmetics, etc.) for different types of mods (IM mods, etc.) and then just show a list of mods in that subcategory for the "related mods" section. But I don't like this solution as much as the first one.
</michael>

<XXL>
I suggest to add some kind of comment system to the mod entries. Since we already have a pretty good posting system, I suggest to use it: YaBB. Every mod would be linked with a single thread in a special board. There, people can post their problems and bugreports. That way, you don't have to search the board for such threads, you get all the information you need in this single thread.
</XXL>

<omario>
Layout: http://www.clickopedia.com/modlayout.htm
Possibly base our testing script off another script: http://www.phparena.net/pafiledb/demos/v2/pafiledb.php ?
</omario>




Misc. Feedback
--------------

<Ironwing>
I don't want just ratings, that would be useless to me.  I would like constructive feedback
</ironwing>

<omario>
i dont want to thave to work on a mod for 2 weeks only to have to wait another week for it to get tested!
</omario>

<hirnsub>
i'd like to mention anothers idea here to prevent forgettin it, someone suggested creating a special mods section in the yabb.pl, i think, - just to keep information there about wich mods are installed on the board..
</hirnsub>

Explanation of the current common functions:

dbquery($query, $etype)
-- This will automatically connect to and select the database if there is no current connection. It will return results where appropriate or true/false where appropriate.
-- $etype is the error that should be returned if the function does not complete successfully. Valid error types are $e_silent (just returns a 0 or false), $e_critical (displays a error message on-screen, continues script execution), and $e_fatal (displays error message, kills script at that point, also closes db connection if necessary).
-- This function returns, where applicable, either the number of affected rows, false if there's an error and error type silent is used, or returns an indexed array of all results. Each index is a result set (row) which contains an associative array.
-- I think I should add an extra parameter to this function, $num for number of results to return. The way it currently is, it returns all results, which is inefficient if you only want 5 or so returns.
authenticate()
-- Currently should be called at the beginning of the script.
-- Logs the user in if a correct user/password combination has been passed in, or checks the session info to see if the user is logged in or not.
-- Should also be called wherever you want to check if a user is logged in.
-- Returns 1 for a user that is logged in (or after a successful login) and returns 0 for a user that is not logged in (or after a failed login).
-- Banning will probably be implemented from here, as well.
error($type)
-- Returns an error of $type. Currently valid types are $e_silent, $e_critical, and $e_fatal.
shutdown()
-- Currently just closes the database connection if it is open and "exit;"s the script. Call it at the end of your script execution. I may change this later on, I'm not sure exactly how it should work.

note for myself: let mod testers check lowercase/uppercase filenames

actually I'm working on this again for some time now

note to myself: add notification system about new mod versions for every mod.