This section provides an overview guide to the basics of using the Project Tools and Projects within them. For the purpose of this guide, we'll use the
TXU Site Management Project as examples. The principles apply throughout the whole Project Tools system.
Within most Projects it is possible to create one of several types of issues. For example, let's take the steps to report a problem with styling on TXU through the TXU Site Management Project.
First open up the Project. Clicking the Post New Issue button will drop down a menu. From that menu select Bug (Feature is for suggestions on changes, and Tasks is more often used by the staff when specific tasks need accomplishing within the site).
The page that loads is the main page for creating a new issue. There the first three options that need posting include a Title, Summary and Description. The Title should be a simple explanation of the problem. For example we may report our Style bug with the title "Community Drop Down Menu Text is Unreadable". We would then place the following in the Summary: "The Community Drop Down menu text is the same colour as the background and is unreadable". The Description would then contain more details, such as: "The Community Drop Down menu text is the same colour as the background menu, which makes it unreadable. This happens on every page I've loaded. I use the Google Chrome web browser."
That sort of use of the three areas relating to the issue is important, as it can make our report easily understandable, or can present a headache if not thought out to those responsible for fixing problems.
Below that first section is the Additional Options portion of the issue. Firstly, you may have the option to make the issue Private. This prevents other users seeing the information (and in fact, this option can be chosen on replies to the issue as well). This option allows confidential information to stay confidential, with only the issue resolvers able to see those private details.
Priority is always subjective, and will often be adjusted by the team to help them prioritise what's important. Don't automatically assume that because you feel something is critical to you that you need to place it as the highest priority. Be reasonable in your assessment. Is the problem/feature/task a showstopper? If not, is it comlpetely trivial? If not, where should it sensible be placed? Our above example isn't a showstopper bug, but it's not trivial either, as it makes the site unusable to some degree. A priority of 6 would make the most sense for it.
Category is also important. Make sure you select the best category for the issue. It may be changed later on by the issue managers, but placing a category is important (necessary to be able to post in some of the projects). We choose General for our example.
Status will be Unconfirmed/Suggested or similar on initial creation. That again will later be changed by the issue managers.
When selecting the next two options, you will find a slight variation in terming. Affected/Applicable/Suggested/etc depends on the type of issue you are reporting. Whatever comes first, the idea is you report it based on the verion you are using of whatever it is that you are reporting on. In our case we'd want to select the highest (first) version that comes as it is current. The second option Fixed/Completed/Implemented/etc will only be adjusted by the issue manager, if it's available for viewing.
Milestone relates to the milestones for that project (more on them later), but normally it would be assigned by the issue manager. You then have the option to Subscribe to the issue, and then on top of that there will be the option (for Issue Managers) on assigning tags and users to the Issue, thereby ensuring that it is worked on.
Many of these same features are available once an issue is posted, most of which will be in the box in the top right corner of the Issue page.
The most irritating thing for project managers is to discover a duplicated issue. It only wastes time for them, and can hinder the fix. So searching properly is important. This can be done in the main Issue list for each project from the drop down menu on the right hand side. You can choose
Contains Text,
Posted By,
Status and
Assigned Users all will let you find with some versitility the problem. Often searching for specific error codes will help you find a bug, or the names of a specific product/problem. Be thorough. When many reports are being made, it becomes more of a headache to the Issue/Project Managers if they have more to search through than necessary.
There is also an option of doing a default search for
Find New Issues as well as an
Advanced Search. In fact, Advanced Searches are very useful. You have a lot more versitility in what to search for (indeed for project managers, it's useful in that Searches can be saved, and even made global, allowing a link to be posted for all issues matching certain criteria, one example being this one:
http://www.thexuniverse.com/projects...ssuereportid=4).
Searching this through before reporting a problem/suggestion/etc will allow for a better and more fluid use of the Project system.
When using the Project Tools system, always think about the Issue/Project Managers. Make their work easier. Ask a question in a general forum if you are unsure about how to use the system (indeed post a reply to this Wiki article if you have questions). Many of the Managers will provide you with their directions on how to use the system according to their needs. Please read that carefully, including reading the long description of the project usually available at the top of the main project page.
Bookmarks