All projects submitted to mIRC.net are virus checked by site reviewers or administrators before they can be reviewed. Once approved for reviewing a project is moved to the review queue where any registered and logged in user may review the project. When reviewing a project there are three sections that need to be reviewed, Documentation, Functionality and Design. There is also a section to give a summary review. Each of the three sections has a rating between 1-5 (5 is the highest). You may choose to not review any of the three sections by selecting 'No Rating'. Information on all sections is included below. Once a review is submitted it will be checked by an administrator and will be either approved or rejected. If it is approved the project will be placed in the archives with your review. If it is not accepted the project will remain in the Review Queue. The number of reviews you have written is shown in your profile and if you have written enough reviews you will appear on the contributers page. You also receive several permanent points for reviewing a project. Personal opinions may be expressed in reviews however they should always be constructive.

Documentation:

In this section the documentation that comes with the project will be reviewed. For some projects, rating the documentation would be inappropriate. For example, a snippet that is straight forward to use. All scripts and DLLs need documentation. Addons do not need documentation but they should have it. Tutorials should not have a documentation rating. Snippets may come with documentation but usually it is not necessary. If you choose not to rate the documentation please specify a reason why. For example, 'It would not be appropriate to review the documentation for this project as none is needed'. A documentation rating for scripts, DLLs, addons and themes should always be given. If no documentation is included a rating of 1/5 should be given. When rating documentation one should look for details about what the script does, author's contact information, instructions on installing the script (including loading any script files), instructions on configuring the addon, information on using it (executing the project's functions), the amount of detail in the documentation, the format of the documentation and the grammar/spelling of the documentation.

Functionality:

This section is for reviewing how well a project works and how useful it is. For this section the functionality of the project should be tested. Any bugs or problems encountered should be noted. Useful or unique features should also be noted in the review. Both should be reflected in the rating. A brief list of main features of the project may be given, especially for scripts, addons and DLLs. Details about how the features of the project are used (for example, through a dialog, popups or aliases) and how configurable the project is should be included in the review. A project that works well and does not have any bugs should not be automatically given a 5/5 rating. The usefulness of the project should also be taken into account. For example, an mp3 player should not be given 5/5 because it has no bugs and supports all the standard mp3 features. It should only be given a 5/5 rating if it is more useful than other mp3 players or perhaps if it is exceptionally well made. Recommendations on how to improve certain features of the project may be put in the review.

For tutorials this section is used to rate the content of the tutorial. Information on the scope of the tutorial, the detail it has, any mistakes and the usefulness of the information should be given.

For both tutorials and other types or projects recommendations for possible functions or extensions to existing functions may be made. If any major bugs are found, the project should be rejected. See the 'Overall' section for information on how to recommend a project is rejected.

Design:

The design section is to review and rate the design of the project. This includes what a project looks like and how it is coded. For dialogs: alignment, buttons (consistency of size and placement), empty space, use of DLLs (such as MDX) and overall look and ease of use should be commented on. Any messages sent out by the project should be reviewed (for example, use of colours/bold). For the code, the readability of the code should be noted aswell as any intentionally obfuscated code (code intentionally made hard to read or interpret, usually in a futile attempt to deter rippers). Global variables, common alias/dialog/variable names (that aren't local) and error checking should also be reviewed. If the project leaves global variables set when unloaded that should be noted. You should also note if the script lacks error checking, ie, how easy or hard is to break by giving it bad input. The method that the script uses to store information may also be noted. The uninstall feature of the project should be tested and reviewed aswell. Note if it removes (or gives the option to remove) any files created or global variables, turns off timers, unloads hash tables, etc.

For tutorials this section should be used to review the layout of the document. Attention should be given to colours, use of text formatting and layout.

Overall:

In this section one can give a summary review. It should contain a summary of the main points from each section aswell as the overall opinion of the project.

If you believe the project should be rejected, leave all the other sections empty and state in the Overall section that you believe the project should be rejected. Give a reason why so the site administrators can double check it and take the appropriate action.

FAQ:

How do I become a site reviewer?
What can a site reviewer do?
How do I know if my review was rejected?
How do I update a review?
Can I use HTML in my review?

How do I become a site reviewer?

The site administrators keep track of who is reviewing projects. If the site needs more site reviewers, and the administrators think you have been doing a good job reviewing they will ask you if you want to be a site reviewer. There is no application to fill out, and please do not ask any of the administrators if you can become a reviewer.

What can a site reviewer do?

A site reviewer can download files in the virus-queue and reject them or move them to the review queue. They can delete files from the review queue if they are later found to not meet the requirements to be accepted. They can approve or reject submitted screenshots. They can approve or reject updates. They can upload screenshots for any project. They can update the review for any project. They can also change information of projects/updates when accepting or rejecting them (including accepting/rejecting a screenshot submitted with a project). They can edit project descriptions, titles, and section.

How do I know if my review was rejected?

If the project is added to the archives and your review is not in the 'Independent Review' then it was rejected. If the project you reviewed is still in the Review Queue a few days after you submitted the review then it is likely it was rejected. There is no notification that a review was rejected.

How do I update a review?

Go to the project you want to update the review for; click 'Independent Review'. At the bottom of the review where it says 'Reviewed by ...' there should be a link next to it that says (update review). Click the link and edit the review. Submit the updated review and wait for an administrator to approve or reject it. Again, if it is rejected you will receive no notification. Usually review updates are accepted or rejected in a day or two so if it is not rejected by then you should assume it was rejected. You may only update a review that you wrote.

Can I use HTML in my review?

Yes, you can.

Any questions regarding reviewing or submitted reviews should be sent to Mentality, tye, Mpdreamz or hixxy. Any questions regarding submitted projects should be sent to any of the administrators listed above or to any site reviewer. Any FAQ suggestions or corrections to this document should be sent to tye.