Repository Guidelines

The repository for TR has some guidelines when submitting requests or viewing the issue tracker. These are listed below and will help guide those interested in contributing, requesting enhancements, or understanding the current progress of TR.

---

Issues

Requests, bugs, enhancements and progress of the project can be found under the "Issues" tab.

What Is An Issue?

Issues contain eight main pieces, a title, description, assignee, kind, priority, component, version, and attachments. When filling new issues, users are required to enter a title, kind and priority to submit an issue. Although these are the bare minimum to submit, we request that users follow our guidelines to help the developers track and handle issues quickly. Generally not necessary to change the majority of these fields. Internal managers or developers will typically handle assignee, kind, priority, component, and version. The obvious exception of this rule of thumb is with bugs, which are found under the kind field.

Titles and Descriptions

When submitting an issue, please try to be as clear and concise as possible, in both your title and description. Titles should be single phrase or sentence explaining the core of the issue. Descriptions should have more elaborate explanation of the request/bug/issue that you would like addressed. However, descriptions should not include logs or other technical output from the software. Detailed technical data should be provided as attachments. The Description should be used to provide the reader with a basic understanding of the problem or feature. Links to relevant information are welcome if you believe it will help solve the issue.

Attachments

Attachments are great when you are reporting bugs. This is the section in which you would likely leave any technical software output, log files, or other important information that would be too long to read in the basic description section.

Kind

Kind is a single word descriptor to explain the type of issue you are submitting. There are four options under this field. Those options are as follows:

• Task -- This is something the developers are definitely working on towards the project or are new feautres that will be implemented in an upcoming release.

• Enhancement -- This is an inprovement to an existing system.

• Bug -- This is straightforward and is used when the issue you are creating is a bug in the current version of the software.

• Proposal -- Issues with the proposal kind are issues that have not been reviewed for submission into the project.

When users are creating new issues, they will generally be choosing the bug or proposal kind. The other options are typically handled by developers once a decision has been made on the issue.

Assignee

Assignees are used to provide an issue to a specific developer. In general it is best to leave this blank unless you specifically have a reason to change the value. The project managers and developers will generally look into the issues and assign a person to the issue internally. However, this field will provide you a good point of contact (POC) when trying to find out more information about the issue in question.

Priority

Priorities are used to define the manner in which an issue will be tracked. There are five levels of priority that can be assigned. The descriptions for each priority are provided below and described with bug/other in mind.

• Trival -- Small bugs that aren't nessecary fixes; Small requests requiring minimal time to implement; Outside of the normal development scope

• Minor -- Moderate bugs that should be fixed in a timely manner; Secondary to main development

• Major (default) -- Normal priority bugs that need to be addressed; Things that need to be done to fulfill general development goals

• Critical -- Bugs that must be fixed quickly; Must have/highly requested or desired items

• Blocker -- Breaks critical systems; Task is undeliverable unless the issue is addressed; Should be done yesterday!

When submitting a new issue, it is best to leave this at the default "major" option unless you have a reason to change the value. Like most fields, the project managers and developers will handle this internally once the issue has been reviewed.

Component

Components are descripters used to aid in searching and addressing all issues related to a specific theme. Components can be:

• Content tools -- Tools used to help in development efforts, either for the end-user or the internal team.

• GUI -- Issues related to the GUI system; Menus, minimaps, in-game consoles, etc.

• Input -- Items that handle input for the project.

• Lighting -- Issues related to the handling of lighting, shadows, etc.

• Networking -- Issues related to networking components of TC.

• Physics -- Issues related to the physics system of TC.

• Rendering -- Issues related to rendering a scene. Examples are auto-LODs, particle system, imposters, camera tasks, volumetric rendering, ...

• Shaders -- Issues related to shaders systems found in TC.

• System -- Core systems that are the foundations for TC. This includes the messaging/entity system, shader manager, audio system, AI, plugin system, TC scene graph, compilation, ...

Version

Versions are used to tell the developer and users what tasks or bugs are expected to be addressed by the given release. Currently the versions available are given below with a short description of their intended goals.

• 0.2 -- Core setup; Base systems; Pre-alpha release
• 0.5 -- Major features needed for overall functionality; Alpha release
• 0.9 -- Features wanted for I/ITSEC demo; First release; Beta release
• 1.0 -- First official release; Major bug fixes have been addressed from the Beta release
• 1.x -- Future goals (As of January 2018)

---