[Scol-info] SourceForge Tracker Tool Overview - 2003, June the 12th

[Bob Le G. <bob...@wa...>]

Hi,


The Tracker tool of SourceForge has been configured today
for the SCOL opensource project. The configuration is a
basic one that will be updated as needed in the future.
The simple settings will give the opportunity to all of
us to gradually get accustomed to this tool.


So, what is this tool used for, and how do we use it ?

* * *

Short description:

The purpose of the Tracker is to keep note of community
members' requests and to keep a history of the processes
needed to fulfil (or not) these requests.

Three main types of requests will be handled through this
tool:
- Bugs reporting
- Support requests
- Features requests
[There's a fourth type, which concerns Patches, which will
be discussed later.]


* * *

Identifying yourself on SourceForge:

For convenience, it would be better for any one who would 
like to post some request to first create an account on
the SourceForge web site. This is free and is of great 
help in requests management (for example if the member
who will process the request needs further informations,
or if you want to be kept automatically informed on your 
request's progress).

Creating a SourceForge account can be done there:
  https://sourceforge.net/account/register.php

Identifying yourself when connecting to SourceForge to post
or update requests can be done there:
  https://sourceforge.net/account/login.php


* * *

Getting to the Tracker:

Access to the Tracker can be done from the SCOL project
base page, in the Public Areas part (just scroll down) :
  https://sourceforge.net/projects/scol

Or on the same page, through the menu:
  Tracker |  Bugs |  Support |  Patches |  RFE

Especially useful are the Bugs, Support and RFE (Feature
requests) entries.

These three entries are buildt from the same template, so
the next explanations which are based on the Bugs reports
are valid for the other types of requests too.


* * *

Bugs reporting tool:

This tool uses a secondary menu with 4 new entries:
  Submit New | Browse | Reporting | Admin
Only the "Submit New" and "Browse" entries are of interest 
to us for a day to day basic use of the Tracker.


"Submit New" menu:
To report a bug, you'll have to fill the following fields:
- Group
- Category
- Summary
- Detailed Description
If necessary, you'll have the possibility to upload a file
too (Check the checkbox, choose your file and enter a file
description). The file could be a screenshot or a code
sample showing a bug for example. Note that the uploaded
file has to contain at least 20 bytes.

Group:
A group is one of the main aspects of the whole project. 
Currently defined groups are:
- 3DS Max        - For all modeling or exporting bugs
- Miscellaneous  - If you do not find any appropriate group
- Modules        - For DMS modules bugs
- SCOL Server    - For all server related bugs
- SCOL Voyager   - For all client related bugs
- SCS            - For bugs in SCS tool

Category:
A category is a more precise sub part of a group. Currently
defined categories are:
- 3D             - 3D related problem
- Install        - Installer problem
- Kernel         - Problems linked to the executable files
- Miscellaneous  - If no other appropriate category
- SCOL Language  - Problems with the programming language
- Web            - Web 2D related problemes

If you do not know what group or category to choose, just
select 'Miscellaneous'. Members who will check the new
requests will dispatch them as needed (or ask for new
groups or categories).

These pre-defined groups and categories are destined for
evolution. We've chosen to provide you with a short list
rather than directly implementing a huge and intricated
one. In the next months, new groups and categories will
appear as needed, and some will probably be renamed.

Summary & Detailed Description:
These are probably the most important informations that
you have to provide. Find a clear and short description
of your problem, then give as much information as you can
about it: basic problem description, error messages, step
by step procedure to reproduce the problem and system
configuration if needed (system & version, cpu, memory,
kinds of cards with latest driver versions ...), and so
on ... Upload code samples, screenshots or .dms files
using standard libraries if you see fit to do so.

Assigned To   &   Priority
I didn't speak about these two entries before because
you shouldn't assign requests to specific members by
yourself. The project managers or developers will 
assign themselves the different requests to the proper 
active members.
In most cases, the Priority too should be let to the
default value. Project managers will set the priority
as needed. If you believe one of your requests to be
of upmost importance, then modify the priority and
explain your reasons in the description. This doesn't
ensure the final priority which will be evaluated
by the project managers.
But I repeat: Changing the priority by yourself should 
be done really seldom. If everybody puts his requests
to HIGH priority, then the priority will no more be taken
into account in the future.


"Browse" menu:
This menu is used to perform some searches in the bugs'
database. The search options allow you to look for bugs
depending on the member they currently are assigned to, 
on the current bugs' status, their group or category.
You have different sorting options too for the result of
your search.
Once you get the result, displaying the list of wanted
bugs, you just have to click on a bug's summary to access
all the informations available for that bug. You can then
simply read the bug description or modify it.

"View/Modify" sub menu:
Once you select a specific bug, you can have a look at its
history and complete it with new informations and/or new
uploaded files.
But a very interesting functionality here is the 
possibility to Monitor a specific bug. If you have created
a SourceForge account and posted a request, then monitor 
it. Each time someone will be working on your request, 
you'll get an email telling you the changes. If you do not
monitor your requests, and if for example a member asks you
for more information, you may not be informed of this. And
if you do not answer to this information request, the 
Tracker will some day automatically and simply delete your
request.


Some more information on requests' status:
The Tracker offers only 4 status for the requests:
- Open: This is the basic status of a request.
- Pending: This status is used only by project managers or
  developers when they require more informations for the
  request. When you provide the required informations,
  change again the status to Open.
- Closed: The status of the request when it has been 
  fulfiled or rejected. The Tracker provides a Resolution
  field which may give more information on the reason why
  the request was closed, as well as some "template"
  answers or simply the possibility to post a more 
  precise explanation for the request closure.
- Deleted: A status that should seldom be manually used.
  But it is used by the Tracker itself to store Pending
  requests that do not get answers rapidly enough (15 days
  by default).  
This is for information. Basically, most users should only
use the Open status ... when they post a request or update
it ... If you have posted a request and believe it to be
no more relevant, update your request, explain why it can
be closed and let the project managers close it.

  
This is a first draft and this document will probably be
developped further in the near future. If you have any
question or suggestion, just send me an email.


Regards,


Bob Le Gob

SourceForge account : bob_le_gob
SourceForge email     : bob...@us...


P.S. Do not forget to move from the OVH mailing list
to the SourceForge official SCOL mailing lists.