Reporting issues is inherently part of the job as a developer. The problem is that reporting issues, although beneficial to the organization and record-keeping of the engine's development, can take away time from developers that they can spend actually fixing issues. This is why we have reporters.

The job of reporters

Reporters simply report issues and try to be aware of issues that already exist. You can report your own issues, but it is not required. The primary task of reporters is to look through the forums (namely the "Bugs and Issues" section) to find reports of issues and document them for the developers. They also, where needed, ask for elaboration on reported issues if there is not enough information for the developers to do the task.

Job requirements

Reporting issues is quite easy. Although no programming skills are required, it is nice if you have a little programming experience (even if very basic) just to be able to have a better understanding of the issues you are reporting. The same goes for experience working with the NetGore engine - not required, but helpful. Since you will be communicating with the users of NetGore quite a lot, and are likely to run into user posts on issues that are poorly written or written out of frustration, you will need to have good people and communication skills. Ideally, a reporter will be able to work with a user who has nearly no experience with programming or using NetGore, and be able to help them provide enough information to generate a quality report. Finally, reporters must be fluent in English, as they will be communicating both with confused users and scrutinous developers.

If you feel you don't meet the requirements, you can still apply as long as you have decent people skills and fluency in English.

Writing issues

Writing issues is quite a simple task. All issues are written on the Google Code project page using the issue tracker. It is, for the most part, just like writing an email, forum post, or anything else on the web. You pick a subject, write the details in the body, then include any related documents. There are a few tags which are used for categorization, but those are quite simple to figure out and don't have to be 100% accurate.

How much you include in the issue report depends entirely on the issue at hand. For simple issues, you write less. For large or difficult to repeat issues, you want to write more. But don't pad your report with verbosity - keep it clear and concise. If someone reports a difficult issue, but you have little information to work off of, it is okay if you keep it short since it ends up doing more harm than good if you try to expand it with filler words or stuff developers don't need to know.

Components to include

The actual components that you need to include for an issue, too, depend on the issue. Usually, it is not needed to request stuff like hardware or OS information (unless they are running a non-Windows OS or a release earlier than XP). The most important thing, by far, is how to repeat the issue. If a developer can't repeat an issue, they will have a very difficult time finding and fixing it, and won't be able to tell if they did fix it.

If someone reports an issue and mentions something visual such as display issues or an error message, it is helpful to get the user to upload a copy of the error report or screenshot of the issue.

Finally, it is nice to include the name of the user who mentioned the issue just in case they need to be contacted in the future to request more information on the issue.

Maintaining issues

LackingDetails

At times, issues will be reported and they won't have enough information. This is to be expected. Not even developers know exactly how complex an issue can be until they start on it. When this happens, a developer will add a LackingDetails tag to the issue. Ideally, when this tag comes up, reporters will help out by investigating the issue their selves and trying to get more information out from the user who initially mentioned the issue. This last point is why it is nice to include the name of the user who mentioned the issue in the first place.

Duplicates

It is possible for some issues to be reported more than once. As long as reporters look at the issues reported by others, it should be easy to track duplicate issues. When you see a duplicate, you will simply mark the newer issue's status as Duplicate and reference what the original issue report is.

Handling issues posted in the forums

Multiple reporters and developers will be looking in the forums for issues to report. Because of this, it is important to make note that an issue has been reported. That way, nobody wastes their time looking to see if an issue was reported yet.

A few features have been supplied to assist in the issue notification process. Generally, the process should look like:

1. Find an issue report in the forums.
2. Check that nobody else has made a post of the issue being reported.
3. Refresh the page if you have been on it for a while just to see if any other reporters have already posted.
4. Make a quick post stating that you are handling the issue. Something like "Creating report..." will suffice. This will just be a short-lived, temporary note that will likely be changed shortly.
5. Go to the code project page and create the issue report. Be sure to make note of the number of the issue(s) you created.
6. Go back to the post you made on the forum and edit it to include the issue number(s) created for the issue.

For consistency reasons, it is generally best to use the repissue BBCode command to report the issue.

Joining the team

If you want to be a reporter, please contact Spodi.