1. Summary
  2. Files
  3. Support
  4. Report Spam
  5. Create account
  6. Log in
Version 7 (modified by travis-w, 5 years ago)

--

Purpose of the Tracker System

SouceForge.net is the world's largest Open Source software development web site. SourceForge.net provides tools that allow Open Source projects to develop, distribute, and support software.

One of these tools, the Tracker system, provides both support and development benefits. Tracker is used by SourceForge.net projects to accept and manage bug reports, support requests, feature requests, and source code patches.

Each project may have multiple Trackers. Each Tracker is used to store a different type of information. By using the same tool, Tracker, for each of these support and development activities, users and developers only need to learn one user interface.

Tracker is part of the SourceForge Collaborative Development System (CDS), one of the many services provided to projects hosted on SourceForge.net.

SourceForge.net staff use the Tracker system to provide support for the SourceForge.net site.

Where may I get support?

Support for project downloads, and for the SourceForge.net site and developer services, may be obtained by following the instructions in our Support Guide. A significant amount of support activity on SourceForge.net occurs through the use of the Tracker system.

SourceForge.net Support

Tracker is the primary tool used for support of the SourceForge.net site and developer services. Details of how the SourceForge.net team uses the Tracker system may be found in our Support Guide. Tips based on our own multi-year use of the Tracker system are included throughout this document.

Standard Trackers

Four Trackers are automatically created for each new project. Since these are part of our standard project service offering, we call these the Standard Trackers:

  • Bug Reports: As software bugs are discovered, users may submit a detailed Bug Report. These Bug Reports may then be escalated to a software developer for review and resolution. This Tracker is listed as Bugs in the project menu.
  • Support Requests: The Support Request Tracker is used to ensure timely and proper responses to all end-user support inquiries. The Support Request Tracker is most often used to track usability problems and usage questions related to the operation of the software which require an immediate response. This Tracker is listed as Support in the project menu.
  • Feature Requests (RFE): The Feature Request Tracker allows users to submit requests for enhancement (RFE) to the software. These types of requests typically do not require an immediate response and responses typically come in a significantly longer timeframe than those to Support Requests and Bug Reports. Submissions may be closed when the requested changes are incorporated in to the software, or when rejected by developers. This Tracker is listed as RFE in the project menu.
  • Patches: Software source code patches may be submitted by users and developers for review via the Tracker system. This allows for better, more uniform recording of patch submissions than is possible using other methods, such as mailing lists. Patch submissions may be closed when incorporated in to the software, or when rejected by developers. This Tracker is listed as Patches in the project menu.

Only a subset of these Trackers may be available on a particular project. Project administrators are encouraged to select the project tools which best meet the needs of their project, then disable unused project services to avoid confusion among users.

The Standard Trackers are provided to each project upon project creation because these Trackers are expected to meet the development and support needs of most new projects. Projects may create Custom Trackers if their needs are not met by the four Standard Trackers, or if otherwise deemed useful for issue management.

SourceForge.net staff use the Support Request and Feature Request Trackers, along with several Custom Trackers, to support SourceForge.net. The Bug Reports and Patches Trackers have been disabled, to avoid confusion and focus our support activities. Details of our use of the Tracker system may be found in our Support Guide.

Project Tracker List

To view a listing of the Trackers you may access:

  1. Login to the SourceForge.net site, if possible.
  2. Access the Project Summary page for the desired project.
  3. Click on the "Tracker" link for the project.

Projects may limit Tracker access to project members. Trackers whose access is limited to project members will require that you be a project member and login to SourceForge.net before obtaining access.

Issue Submission

To submit a new issue to a Tracker:

  1. Login to the SourceForge.net site. While some Trackers permit unauthenticated submissions, most require that you login. In order to login to SourceForge.net, you must first register a user account.
  2. Access the Project Summary page of the desired project.
  3. Click on the "Tracker" link.
  4. Click on the link for the desired Tracker.
  5. Click on the "Submit New" link.
  6. Read the instructions provided by the project on the issue submission page, if any.
  7. Enter a brief overview of your issue in the "Summary" field.
  8. Provide a full description of the problem, including details, in the "Detailed Description" field.
  9. Leave pulldown menu values as default, unless you know the right values for the issue you are reporting. These values may be set later by the project team, to help them sort issues for processing.
  1. Click on the "SUBMIT" button.

Additional comments and file attachments may be added to the Tracker item after submission. If you logged-in before submitting the Tracker item, it will now be listed on your My SF.net page.

Please note that the "Detailed Description" and subsequent comments to a Tracker item cannot be edited or removed. Other Tracker item fields may be changed after submission either by the Tracker item submitter or by a Tracker Technician or Admin.

The Tracker system is designed to prevent accidental duplicate posting of Tracker items. Duplicate posting can occur due to browser reload of the result page from issue submission, or by hitting the backspace key or Back button that returns you to a submission result page. To prevent accidental duplicate posting of Tracker items, we provide an error if a submission to a Tracker has the same Summary as another submission to that Tracker by the same user within the past ten minutes. Should duplicate postings occur, projects may close the duplicates, noting the Request ID of the original posting within a comment as to help users locate the Tracker item that will be used for handling the reported issue.

Public Visibility

By default, all Tracker items are publicly visible on all public Trackers. You should not submit sensitive information, such as email addresses, telephone numbers, and mailing addresses, to the Tracker system. The visibility of a specific item can be toggled to Private by checking the Private checkbox. Private tracker items are only viewable by the submitter (tickets submitted while unauthenticated are viewable by all users who know the URL to the ticket, only the project tracker administrators will get a link to the private ticket after submission, so don't lose the URL after submission) and project tracker administrators.

If sensitive information is accidentally posted to a Tracker item, seek assistance from SourceForge.net staff.

Issue Identifier

Each Tracker item is assigned a unique identifier. This Request ID or Tracker item ID is unique on SourceForge.net. You may use this ID to reference an issue within other project communications.

If a Tracker item is moved to a different Tracker, access will still be possible using this ID.

Tracker items may become inaccessible if a project administrator disables the Tracker or requires project membership to access the Tracker. A permissions error will result if you try to access a Tracker item in a disabled or member-only Tracker without sufficient permissions.

Tracker items may only be removed individually by SourceForge.net staff. If you attempt to access a deleted Tracker item, you will receive an error message stating: "ERROR: Artifact: Only Group Members Can View Private ArtifactTypes".

My SF.net Page

Each SourceForge.net user may access a list of the Tracker items they have submitted, or are assigned to handle. This information is provided on the My SF.net page.

Tracker items are separated in to the following sections, and grouped on a per-Tracker basis:

  • My Assigned Tracker Items (Open).
  • My Assigned Tracker Items (Pending).
  • My Submitted Tracker Items (Open).
  • My Submitted Tracker Items (Pending).
  • My Submitted Tracker Items (Inactive), which provides a list of Items whose status was changed to Pending, Closed or Deleted in the past 30 days (older Items and Open Items are not shown).

If a project is eventually removed from SourceForge.net (due to abuse or inactivity, for example), Tracker items related to that project will no longer appear on your My SF.net page. If a project administrator disables a Tracker or limits access to a Tracker to team members, Tracker items will no longer appear on your My SF.net page if you are unable to access them.

The Monitoring section of the My SF.net page provides a listing of resources you have elected to monitor, including monitored Tracker items.

Issue Viewing

To view a Tracker item, use the Tracker Browse view, search facility, or My SF.net page to locate the desired Tracker item. Open a Tracker item by clicking on its Summary.

There are two possible views for a Tracker item:

  • The modify view allows the modification of Tracker item settings, such as assignee and status. Posting of comments and file attachments is also possible using this view. This view is automatically shown to the submitter and assignee of a Tracker item, as well as to Tracker Admins.
  • The display view provides a read-only listing of Tracker item detail, but permits the posting of comments. This view is automatically shown to all other users.

Important details to consider when looking at a Tracker item include:

  • The date of the latest update, and name of the user responsible for the latest update, to this request. This detail is found in the "Last Updated By" and "Date Last Updated" fields, at the top of the Tracker item view.
  • The current assignee of the issue, as shown in the "Assigned To" field. If set by the project team, this is the person who is expected to process your issue report.
  • Current issue status, as shown in the "Status" field. If status is "Pending", the project team is waiting to receive information from the user before they can proceed with issue handling.
  • The text of the most recent comments to the request. Comments are shown in reverse chronological order (newest comments first).
  • The "Date Submitted" field, which will help you know the age of the request.

The bottom of the Tracker item view includes a "Changes" section. This section will show a change history for the Tracker item. This change history will include the time and date that each update and comment was made to the Tracker item. This history will also show the value of each modified field before it was changed, not the current or updated value from that change.

File Attachments

When debugging an issue, it is sometimes helpful to have a screenshot or error log submitted for review. File attachments may be added to a Tracker item using the form at the bottom of the Tracker item view.

File attachments may be downloaded by clicking on the "Download" link next to the desired file in the "Attached Files" section of the Tracker item.

File attachments are publicly visible. Attached files may be removed by the issue submitter or by the project team.

To add an attachment to a Tracker item:

  1. Login to the SourceForge.net site.
  2. Access the desired Tracker item.
  3. Check the "Check to Upload and Attach a File" checkbox.
  4. Click on the "Browse..." button and select the file to upload.
  5. Note that file attachments are publicly visible; do not upload sensitive information.
  6. Enter a description for the file, such as "Screen shot of File Open error message", in the "File Description" field.
  7. Click on the "Submit Changes" button.

The Tracker system currently accepts attachments larger than 20 bytes and smaller than 256,000 bytes.

The handling of downloaded files is determined by your web browser. Certain file types are commonly displayed rather than downloaded by a browser. For these files, you may need to right click on the download link and use the "Save target as..." browser option. For XML files and other text-based files, it may be advantageous to compress these files using the Zip format or Gzip format, as to reduce file size and cause the browser to download the file.

In the case of contributions, such as source code patches: Users should be careful to only upload materials which are Open Source in nature and which comply with the license terms of the project. Projects should be careful to only accept contributions which are compatible with their license terms and to provide proper acknowledgment and attribution for all contributions.

SourceForge.net staff typically ask for screen shots when dealing with browser compatibility problems and issues with GUI-based client software. While Linux and Mac OS X users typically generate screen shots using the OS-provided tools, we recommend the use of smartision ScreenCopy (hosted on SourceForge.net) to users of Microsoft Windows operating systems.

Issue Status Values

The Tracker system supports four issue status values:

  • Open: New submissions are given an Open status. Issues which are unresolved should generally be left in the Open status.
  • Closed: When completed, canceled, or rejected, an issue may be changed to the Closed status.
  • Pending: When the project team needs additional information in order to respond to the issue, its status may be changed to Pending. Pending issues will automatically be returned to an Open status when the Tracker item submitter posts a comment. If the Tracker item submitter fails to login and post a comment within the time frame specified in the settings for that Tracker, the Tracker item will automatically be changed to a Closed status.
  • Deleted: The Deleted status does not actually remove any data from the Tracker system. This status value is used in a project-defined way, typically to move rejected or canceled issues for more accurate reporting. The SourceForge.net staff can assist you if you actually need a Tracker item removed.

While a project is welcome to use the Issue Status values as desired, care should be taken not to use the Pending status improperly, due to the automated issue closure mechanism attached to the Pending status.

Pending Status

The Pending status is useful when a Technician requires additional information from an issue submitter in order to process an issue. The Pending status includes a special automatic closure mechanism to ease the issue management process.

To begin the process, a Technician may add a comment to the request, detailing the information they need in order to continue processing of the issue, and then set the status of the issue to Pending. When the item submitter posts a comment to a Tracker item that has Pending status, the status is automatically changed to Open, as a signal to the Technician that the requested information has been provided.

Once the issue is in Pending status, the submitter is expected to respond within a certain number of days (configurable as a Tracker option). If the submitter fails to respond within that time period, the status is automatically changed to Closed, representing that the user has not responded within a reasonable amount of time. If the user wishes to respond subsequent to closure, the Tracker item may be re-opened by changing the status back to Open.

The default waiting period before automatic closure of Pending Tracker items is 7 days.

To configure a custom waiting period, a Tracker Admin will:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  1. Click on the "Update preferences" link.
  2. Enter the desired number of days in the "Days till pending tracker items time out" field.
  3. Click on the "SUBMIT" button.

Projects are encouraged to set the waiting period for automatic closure to a reasonable value, typically no shorter than 7 days. SourceForge.net staff use a waiting period of 14 days on their Support Request Tracker.

Special care must be taken with issues submitted by an unauthenticated user. Comments posted to a Tracker item by unauthenticated users will not cause the issue status to revert to Open. Projects are encouraged to adopt the policy of not using the Pending status for anonymously-submitted Tracker items. If use of Pending status for anonymously-submitted Tracker items is continued, projects should have a member of the project team periodically review all anonymously-submitted Tracker items. This review may be done either using the Browse view or by using the "Last Comment/Update Detail - Pending Items" Tracker report.

Issue Priorities

The Tracker system represents issue priority on a scale from one to nine. Priority one issues are considered the least important and lowest priority. Priority nine issues are considered the most important and highest priority. Issues with normal priority are in the middle of this priority range (five).

Within the Browse view, the background color of each Tracker item line will represent its priority. Darker red tones represent higher priority. Whiter tones represent lower priority.

Projects may develop their own scheme for assigning issue priority. Users are encouraged to leave the priority setting for their issue at the value set by the project team. Details on how the SourceForge.net staff prioritize issues may be found in our Support Guide.

When changing issue priority, project members are encouraged to also post a comment to the request, so the submitter understands the priority change.

Issue Assignment

Tracker Technicians are responsible for processing submitted issues. Issues may be assigned to any project member designated as a Technician for that Tracker using the "Assigned To" pulldown menu on the Tracker item view.

Users are encouraged not to change the assignment of their Tracker items. Project teams are better equipped than their users to know who would be the best person to respond to a particular issue.

To change the assignment of a Tracker item, select the desired Technician in the "Assigned To" pulldown menu, then click on the "Submit Changes" button. Tracker Technicians and Admins may also change issue assignment using the Mass Update feature.

Resolution Codes

To keep track of how an issue was resolved, some Trackers include a Resolution field. The Bug Reports Tracker includes this field. Custom Trackers may include this field based on the decision of the project administrator.

Resolution codes are standardized across all Trackers. Current Resolution codes are:

  • Fixed
  • Invalid
  • Won't Fix
  • Later
  • Remind
  • Works For Me
  • Duplicate
  • Accepted
  • Out of Date
  • Postponed
  • Rejected

The Resolution code field may be used both to track the handling process for an open Tracker item (with the Postponed, Later, and Remind resolution codes), and to record the outcome of the processing of a Tracker item (with the Fixed, Invalid, Won't Fix, and Accepted resolution codes).

The decision of which Resolution codes will actually be used by a project is left to the project administrator.

The Resolution field may be enabled or disabled on Custom Trackers using the 'Display the "Resolution" box' Tracker option.

Issue Processing

Though the exact process for issue handling is left entirely up to the project, Tracker items are generally handled in the following manner:

  1. A user submits a new request. The Tracker item is automatically given a status of Open.
  2. Upon each update to the Tracker item, an email will automatically be sent to users who are involved with the Tracker item.
  3. A designated member of the project team, a Tracker Admin, reviews each new Tracker item and assigns it to a Tracker Technician. A comment may be added at this time to detail the expected response time for the issue.
  4. When the Tracker item is first reviewed by the Technician, they may add a comment providing detail on how the issue is being handled. Issue priority may be changed as needed.
  5. If the Technician requires additional information in order to respond to the issue, they will request that information and change the status to Pending.
  6. The Tracker item submitter will respond with any requested information via a comment to the Tracker item. The status of the Tracker item will automatically be changed to Open when this comment is posted.
  7. When ready to proceed with resolution, the Technician will do whatever work is needed behind-the-scenes to complete the request, or add a comment explaining why the request is being rejected.
  8. Once the request has been answered or completed, the Technician will add a comment providing a summary of their actions, and change the issue status to Closed.
  9. Tracker items may be re-opened as necessary to ensure suitable response has been received by the issue submitter.
  1. Projects are responsible for managing their own Trackers on a day-to-day basis. Users are expected to respect the wishes of projects to leave Tracker item settings and status as they are configured, if requested.

SourceForge.net staff use their Support Request Tracker to provide support for the SourceForge.net site and developer services. Details on how the SourceForge.net team handles issues using the Tracker system may be found in our Support Guide.

Tracker-Generated Emails

To aid in the communication process, Tracker will automatically send email to any user who has direct involvement with a Tracker item when updates occur. Users involved with a Tracker item include the submitter, current assignee, and all users who have posted comments to the Tracker item.

These emails will be similar to:

To: noreply@… From: "SourceForge.net" <noreply@…> Subject: [ alexandria-Support Requests-1008648 ] Issue Summary Date: Fri, 13 Aug 2004 05:08:39 -0700 Support Requests item #1008648, was opened at 2004-08-13 08:08 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1008648&group_id=1 Category: Project Administration Group: Second Level Support Status: Open Priority: 5 Submitted By: Jacob Moorman (moorman) Assigned to: Nobody/Anonymous (nobody) Summary: Issue Summary Initial Comment: Detailed Description of Issue


You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=200001&aid=1008648&group_id=1

The link provided in the Tracker email will bring you to the view of the Tracker item. You may then respond using the "Attach A Comment" field of the Tracker item. Copies of comments posted to the Tracker item by other users, and of your own comments, will be sent to you by email. Each email contains a full copy of the Tracker item and all posted comments.

Email may also be generated by Tracker as part of Tracker monitors or project-configured automatic emails.

All Tracker-generated emails originate from noreply@…. You should not reply to these emails. Any replies sent to Tracker-generated emails will automatically be discarded.

Tracker Monitoring

By default, users with direct involvement (submitter, assignee, users who have posted comments) with a Tracker item are sent email when updates are posted to that Tracker item. Other interested users may use the monitoring system of SourceForge.net to receive these same updates by monitoring a particular Tracker item. SourceForge.net subscribers have the option of monitoring an entire project, which will include Tracker updates for the Trackers of the monitored project.

To monitor a Tracker item:

  1. Login to the SourceForge.net site.
  2. Access the desired Tracker item.
  3. Click on the "Monitor" button, located at the top of the Tracker item.
  4. A listing of Tracker items which you are monitoring may be found on the My Monitored Resources page. Tracker items will be shown in the "Monitoring: Tracker Items" section of that page.

To monitor a project:

  1. Become a SourceForge.net subscriber, if not already.
  2. Login to the SourceForge.net site.
  3. Access the Project Summary page for the desired project.
  4. Click on the "Monitor Project" link, located below the project description, to begin monitoring of the project.
  5. A listing of projects you are monitoring may be found on the My Monitored Resources page. Projects will be shown in the "Monitoring: Projects" section of that page.

If a project is eventually removed from SourceForge.net (due to abuse or inactivity, for example), Tracker items related to that project will no longer appear on your My Monitored Resources page.

The monitoring system is designed for use by individual users. Project teams may have emails about all new Tracker items or Tracker item updates sent to a project member or mailing list without using the monitoring system.

Tracker Technicians

Each team member who is going to accept issues for handling should be added as a Tracker Technician. Tracker Technicians are listed in the "Assigned To" pulldown menu during Tracker item submission and when modifying a Tracker item.

Before adding a team member as a Tracker Technician, you should make them aware of the support policies of your project and what you expect of them in terms of issue response times.

Only project members may be added as Tracker Technicians. Each Tracker may have its own set of Technicians.

Tracker Permissions

Project administrators may designate which team members should be able to process and manage Tracker items. Team members who process Tracker items are called Technicians. Team members who manage Tracker items, such as issue assignment, are called Tracker Admins.

Only project members may be added as Tracker Technicians and Admins. Each Tracker may have its own set of Technicians and Admins. A project member may be either a Technician, an Admin, or a combined Tech/Admin.

To configure the permissions for your Tracker:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Add/Update Users & Permissions" link.
  5. To change the permissions for an existing Tech or Admin, you may use the "Permission" pulldown menu to select whether you wish for them to be a "Technician", "Admin" or "Tech & Admin". After changing the pulldown menu value as desired, click on the "Update Developer Permissions" button to complete the change.
  6. Care should be taken when removing a Technician from a Tracker.
  7. To add a project member as a Tracker Technician, select their name from the box in the "Add These Users" section of the page, then click on the "add users" button. You may use the "add all users" checkbox to enable Tracker access for all team members. After adding the users to the Tracker, change their permissions as needed.

Categories and Groups

Each Tracker is configured with a set of Categories and Groups which allow project teams to place Tracker items within distinct logical sets. These settings are used as sorting options within the Browse view of the Tracker, and for reporting purposes.

Categories are used to describe the general subject of the issue, such as the portion of the software which the issue relates to. SourceForge.net staff include Categories for each major site feature within their Support Request Tracker.

Groups are used to associate similar types of issues in a way that is useful for reporting purposes. SourceForge.net staff include Groups based on the escalation level of issues, such as First Level Support, Second Level Support, and Administrative, within their Support Request Tracker.

Each Tracker may have its own set of Categories and Groups.

To manage the Categories for a Tracker:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Add/Update Categories" link.
  5. Click on a Category title to rename the Category, if needed.
  6. Use the "New Category Name" text box and "SUBMIT" button to add new Categories.

Categories may not be deleted once created. Disused Categories should be renamed as that they are at the bottom of the Category listing. Unused and erroneously-submitted Categories may be renamed and reused as needed.

Group management is handled in the same manner as Categories. Groups are managed via the "Add/Update Groups" section of the Tracker Admin pages.

Projects should establish a basic set of Categories and Groups when they begin using a Tracker. These lists should evolve over time (older issues need not be resorted, necessarily) as the project grows.

Categories and Groups may be used as part of strategies for managing multiple software versions or sub-projects within a single Tracker.

Canned Responses

When providing support on a large project, there is a tendency for the same issues to be reported by multiple users. To ease the burden of responding to these issue reports, the Tracker system allows Tracker Admins to create ready-to-use comments that may be applied to a Tracker item. These ready-to-use comments are called Canned Responses.

To use a Canned Response, selected the desired Canned Response in the "Use Canned Response" pulldown menu when modifying a Tracker item, before clicking on the "Submit Changes" button. If a comment is entered in the "Attach A Comment" field when also selecting a Canned Response, both will be posted to the Tracker item (the Canned Response will be posted second).

Canned Responses are specific to a particular Tracker.

When a Canned Response is used on a Tracker item, its text is placed as a comment to the Tracker item. This text is static, just as if a similar comment had been posted to the Tracker item. If the Canned Response is later updated, those changes will not be reflected in the Tracker item comments that had previously been posted using that Canned Response.

Each Canned Response consists of a Title, Message Body and Status. The title of the Canned Response will be shown in the "Use Canned Response" pulldown menu on Tracker items. When used on a Tracker item, the Message Body will be used as a comment. Canned Responses with Active status will be shown in the pulldown menu. Inactive Canned Responses will only be shown in the Admin interface.

While Canned Responses may be used by site users, we discourage this type of Canned Response use. We prefer that Canned Responses be used only by Tracker Technicians.

To manage Canned Responses:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Add/Update Canned Responses" link.
  5. To edit an existing Canned Response, click on its Title.
  6. To add a new Canned Response, enter the "Title" and "Message Body" in the form provided at the bottom of the page, then click on the "SUBMIT" button.
  7. No means is provided to delete a Canned Response. By editing a Canned Response you may change the "Title" of the Canned response, and change the Status of the Canned Response to "Inactive".

Project administrators should name their Canned Responses in a uniform manner, so Technicians can easily locate the desired Canned Response.

SourceForge.net staff maintain more than 150 different Canned Responses covering common issues and questions for use with our own Support Request Tracker. Details on SourceForge.net staff use of the Tracker system may be found in our Support Guide.

A tool for automating the management of Canned Responses may currently be found in the CVS repository of the sitedocs project. This tool, atracker, is part of the adocman tool suite developed by SourceForge.net staff. atracker may be used to extract Canned Responses from the Tracker system and to post updates to Canned Responses within the Tracker system. This allows projects to store Canned Response data within CVS for tracking of changes, and post changed Canned Responses back to the Tracker system.

New Issue Auto-Assignment

Based on Categories, new Tracker items may automatically be assigned to a Technician. If you have established Categories which are consistently processed or reviewed by a particular Technician, configuring automatic issue assignment can save time spent reviewing new issues.

To set up auto-assignment of new issues:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Add/Update Categories" link.
  5. Click on the category whose new issue reports you wish to auto-assign.
  6. Select the desired Technician from the "Auto-Assign To" pulldown menu.
  7. Click on the "SUBMIT" button.

This auto-assignment only occurs upon new issue submission. If the Category of a Tracker item is changed after submission, assignment will not automatically be changed.

Even if auto-assignment is specified for every Tracker Category, it will still be necessary for unassigned issues to be reviewed. Issues may be submitted without a Category; issues without a designated Category will not be auto-assigned.

This auto-assignment feature helps to reduce the amount of time needed for escalation of new issues, but is dependent on users being able to pick the right Category. Please select names for your Categories which will make sense to your users. Projects are also encouraged to provide instructions for issue submission, if appropriate.

Mass Updates

Tracker Technicians may update Tracker items either individually on a per-item basis, or in a group as part of a mass update. The Mass Update feature is available to Tracker Technicians and Admins from the Tracker Browse view.

To perform a mass update:

  1. Access the "Browse" link for the desired Tracker. Use the provided sorting and view limiting options to retrieve a list containing the desired Tracker items.
  2. Check the checkboxes next to the Request ID of the desired Tracker items. You may use the "Check All" and "Clear All" links to toggle all checkboxes at once.
  3. Set the "Category", "Priority", "Assigned To", "Group", and "Status" values as desired using the pulldown menus provided at the bottom of the Browse page.
  4. Comments may be posted to each selected Tracker item through the use of Canned Responses. If desired, select a "Canned Response" from the provided pulldown menu.
  5. When settings have been selected as desired, click on the "Mass Update" button.

Changes made during a mass update will generate email as would be done if each Tracker item were changed individually.

Emails for Project Team

By default, Tracker will send an email to users who are directly involved with the Tracker item, or who have enabled monitoring. Each Tracker may also be configured by a project team to send out new email upon new issue submission or upon issue update.

The additional Tracker emails allow the project to have notification of new updates sent to someone who provides oversight for project support, or to allow the project to keep track of support and development occurring through the Tracker by having notifications sent to a mailing list.

To have Tracker send additional mail on new Tracker items or updates:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Update preferences" link.
  5. Enter the email address which will receive the additional Tracker mailings in the "Send email on new submission to address" field.
  6. If you wish for mails to be generated on every update to a Tracker item, not just on new issue submissions, check the "Send email on all changes" check box.
  7. Click on the "SUBMIT" button.
  8. If you have configured Tracker to send mail to a project mailing list hosted at SourceForge.net, you will also need to configure that mailing list to accept this mail.

Only one email address may be specified for this feature. If you need mails sent to multiple addresses, please create a mailing list for that purpose.

Tracker Mails to Mailing Lists

Tracker may be configured to send mail to a project mailing list, which can help improve communication and oversight within the project team. Special mailing list configuration changes are needed in order to accept these mailings at a SourceForge.net mailing list.

Problem overview: Email generated from Tracker originates from 'SourceForge.net <noreply@…>'. Each mail blind copies (BCC) the actual recipients and uses "noreply@…" in the To: field. Special mailing list configuration changes are needed in order to accept these mailings to a SourceForge.net mailing list. Mailings where the recipient is not listed in the To: or CC: fields are said to have an implicit destination. Though implicit destinations are used legitimately by SourceForge.net, many spammers use this technique to mass-mail thousands of people at a time. As result, Mailman, the mailing list management software used by SourceForge.net, blocks messages received through implicit destination by default.

To reconfigure a SourceForge.net mailing list to accept mail from Tracker:

  1. Login to the SourceForge.net site.
  2. Click on the "Lists" link for the project.
  3. Click on the "Admin" link.
  4. Click on the "Administer/Update Lists" link.
  5. Click on the "Administer this list in GNU Mailman" link next to the list you will use to receive Tracker mailings.
  6. Enter the mailing list admin password at the "List Administrative Password" prompt. Note that this password is mailing list-specific and will not match your SourceForge.net user account password.
  7. Click on the "Privacy Options" link.
  8. Click on the "Recipient Filters" link.
  9. Add "noreply@…" to the field marked "Alias names (regexps) which qualify as explicit to or cc destination names for this list".
  1. Click on the "Submit Your Changes" button.
  2. Configure Tracker to send email to this mailing list as desired.
  3. If you are operating a closed (subscriber-only posting) mailing list, you may also need to configure the list to accept posts from the noreply@… address. See the instructions in the "Sender filters" section of the Mailman "Privacy Options" page, or contact SourceForge.net staff for assistance if operating a closed list.
  4. If the list is properly configured to accept this mail, Tracker emails will be distributed to the list and be placed in the mailing list archives. If misconfigured, Tracker emails will be placed in the pending administrative request queue for review by a mailing list administrator.

Mailing lists used to accept Tracker mails are typically named "tracker", "auto", or given a name matching the name of the Tracker, such as "bugs", "support", "patches", or "rfe".

If a mailing list will be used solely for accepting the automated emails from Tracker, you may wish to block posts that are received from other places. To block other posts, you may set the 'Addresses of members accepted for posting to this list without implicit approval requirement. (See "Restrict ... to list members" for whether or not this is in addition to allowing posting by list members' field to "noreply@…" in the "General posting filters" section of the list admin pages.

Sorting and Searching

There are two basic tools available for use in locating Tracker items for viewing: the sorting and filtering mechanisms of the Browse view, and the Search feature.

Sorting: When in the "Browse" view, you may filter Tracker items by Assignee, Status, Category and Group using the provided pulldown menus. You may also filter by the username of the Tracker item submitter or by keyword in the Tracker item Summary by entering the desired text in the provided text boxes. The result of your filter criteria may then be sorted by Request ID, Priority, Summary, Open Date, Close Date, Submitter, and Assignee.

Up to 50 Tracker items will be shown on the Browse view by default. If you are a SF.net subscriber, this number may be increased or decreased using the UI Preferences page.

The most common filter and sorting criteria used by SourceForge.net staff on their Support Request Tracker include:

  • View of unassigned Tracker items: Assignee of "Unassigned", Status of "Open", Category of "Any", Group of "Any", Sort By "Open Date, Ascending"
  • View of my assigned Tracker items which are Open: Assignee of (my username), Status of "Open", Category of "Any", Group of "Any", Sort By "Priority, Descending"

Searching: The Tracker search facility, shown in the left navbar "Search" box when viewing the Tracker, will retrieve Tracker items that have details or summary text matching the specified keyword text. You may also search by Request ID for retrieval of a particular Tracker item.

Other ways to access Tracker items include:

  • A complete listing of all Tracker items within a Tracker with significant detail may be retrieved using the Tracker Listing with Last Comment/Update Detail reports.
  • For quick access to the Tracker items that you had opened or been assigned to process, a listing of these Tracker items may be found on your My SF.net page.

Summary Modification

SourceForge.net staff typically modify the "Summary" field for Tracker items within their Support Request Tracker upon initial review. This allows us to more strongly categorize similar issue types together (beyond use of the Group and Category fields).

This strategy is most useful when processing very large numbers of Tracker items. Before adopting this strategy, you should develop a standard base set of Summary data which will be used by your project. With a properly designed set of Summary texts in use on a Tracker, you can much more easily leverage the Search facility and the "Summary keyword" filter of the Browse view.

If you decide to modify Summary texts systematically, you should be sure to select text which will make sense to the issue submitters, so they won't think their issue has been misfiled.

Authentication

By default, Trackers require users to login to the SourceForge.net site in order to submit new Tracker items. This requirement has been established to help reduce abuse and to provide added benefits, such as issue lookup using the My SF.net page.

Some projects decide to permit unauthenticated users to submit issue reports. While eliminating the need to register for a SourceForge.net user account, this does increase the chance of abuse and reduce the effectiveness of the Tracker system for communicating information. We strongly recommend that you leave unauthenticated posting disabled.

Unauthenticated users will not receive Tracker emails, so will need to manually check their Tracker items for updates.

To reconfigure a tracker to permit unauthenticated (not logged in) issue submissions:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Update preferences" link.
  5. Check the "Allow non-logged-in postings" checkbox.
  6. Click on the "SUBMIT" button.

Issues submitted without logging in will show a submitter of "Nobody/Anonymous (nobody)". Issue submitter cannot be changed after Tracker item submission.

Past Due (Overdue) Issues

To help control issue response times, Tracker includes two mechanisms to help notify Technicians when an Tracker item is past due. The first is a visual cue added to the Browse view. The second is a Tracker report which lists past due Tracker items.

Tracker items which have been open longer than a certain number of days will be considered overdue. Overdue Tracker items will be marked in the Browse view with an asterisk (*) and "Open Date" value in bold. Projects may factor this in to their support process as a way for Technicians to spot issues which are not meeting desired response times.

To set the deadline for issue closure (after the deadline, a Tracker item is considered overdue):

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Update preferences" link.
  5. Set the "Days till considered overdue" value to the desired number of days.
  6. Click on the "SUBMIT" button.

We encourage projects to set "Days till considered overdue" to a value of at least 7, as to provide sufficient time for Technicians to respond to issues. SourceForge.net staff use a setting of 14 days on their Support Request Tracker.

A finer-grained mechanism for tracking response times is provided as a Tracker report. The "Past Due by Technician" report will provide a list of Tracker items, grouped by Technician, which either have not received an initial comment from the Technician since submission or have not received an update, within a certain number of days. This report is a helpful tool for establishing and enforcing an effective support policy for your project.

To configure the intervals for the past due Tracker report:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Update preferences" link.
  5. Set the value of the "Days assignee has to make initial comment (before past due)" and "Days assignee has to post update (before past due)" fields to the desired number of days.
  6. Click on the "SUBMIT" button.

SourceForge.net staff use values of 2 days for initial response and 7 days for update frequency within their Support Request Tracker. SourceForge.net staff make regular use of this report and review the past due counts per developer on a weekly basis as a means to evaluate support response.

Report Generation

The Tracker system allows a project team to generate a number of different reports related to the handling of Tracker items. Reports are generated for a particular Tracker, covering issues from a specific time period.

Report options include:

  • Distribution by Technician (Present Techs/Admins) which shows the number of Tracker items (currently open, and in total) per Technician. Shows only current Tracker Technicians. This report allows you to determine how many issues are assigned to each Technician.
  • Last Closure/Comment by Technician (Present Techs/Admins) shows the Tracker item ID and date of the latest Tracker items to be closed or updated by a Technician. Shows only current Tracker Technicians. This report allows you to quickly check up on the latest activity by a Technician.
  • Past Due by Technician: Provides a listing of the Tracker items which have not been updated within the number of days specified for the Tracker (overdue Tracker items).
  • Tracker Listing with Last Comment/Update Detail - Open Items: Provides a view similar to the Tracker Browse view, but includes extensive detail that may be used to check on the handling of every issue in the Tracker. View is limited to open Tracker items.
  • Tracker Listing with Last Comment/Update Detail - Pending Items: Provides a view similar to the Tracker Browse view, but includes extensive detail that may be used to check on the handling of every issue in the Tracker which is currently waiting on end-user response. View is limited to pending Tracker items. Useful for checking on updates before automatic closure of pending status Tracker items occurs.
  • Aging Report which shows the average issue life, from submission to closure.
  • Distribution by Technician (Past and Present Techs/Admins) which shows the number of Tracker items (currently open, and in total) per Technician. Shows current and historical Tracker Technicians.
  • Distribution by Category
  • Distribution by Group
  • Distribution by Resolution

Preferred Support Mechanism

To ensure your users know how your project would like them to report issues, the project administrator should set the Preferred Support Mechanism for the project. The Preferred Support Mechanism may be used to direct users to a Tracker, mailing list, or forum for issue reporting.

Details on project-provided support resources are provided on the "Get Support" page (link in left navbar when viewing project pages, and on the Project Summary page). The Get Support page will show which resource a project has selected as their Preferred Support Mechanism.

SourceForge.net staff designate their Support Request Tracker as their Preferred Support Mechanism. This helps to direct users looking for site support to submit a Support Request, rather than trying to contact the SourceForge.net staff some other way.

Tracker Options

Trackers may be configured to provide maximal benefit to their project. Configurable options include:

  • Tracker visibility, which may be set for public display, limit display to project members, or disable Tracker access.
  • Authentication may be required of issue submitters, or you may elect to accept unauthenticated (possibly anonymous) Tracker items.
  • Automated emails to the project team may be set up for better oversight and historical tracking.
  • Deadline for user response to Pending Tracker items before automatic closure by the system.
  • Deadlines may be established, allowing the tracking of past due issues.
  • Instructions to users may be provided for display on the Tracker "Submit New" and "Browse" pages.

To configure the options for a Tracker:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Update preferences" link.

Please note that the "Name" and "Description" values for a Tracker may be changed for Custom Trackers, but not for the Standard Trackers.

If you need to change the name of a Standard Tracker, create a new Custom Tracker with the desired name, then disable the Standard Tracker. Note that replacing the Standard Tracker in this manner will remove the link for the disabled Standard Tracker from the project menu.

Providing User Instructions

Instructions may be provided to users who are submitting or browsing items within a Tracker.

To add instructions:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Update preferences" link.
  5. Text to be displayed at time of issue submission may be placed in the 'Free form text for the "submit new item" page' text area.
  6. Text to be displayed at time of issue submission may be placed in the 'Free form text for the "browse items" page' text area.
  7. Click on the "SUBMIT" button.
  8. Access the "Submit New" or "Browse" link to verify that the text is shown as desired.

SourceForge.net staff provide instructions on the issue submission page for their Support Request Tracker which direct users on the best way to report issues. Instructions are provided on the Browse page of their Support Request which ask users not to post comments to requests that are not their own. An example of instructions for issue submission may be seen on the issue submission page of the alexandria project Support Request Tracker.

Mass Reassign

When removing a Technician from a Tracker, or when a Technician is changing job roles, it may be necessary to reassign all issues assigned to a Technician. Performing updates to each Tracker item is time consuming and will generate unwanted email. The Mass Reassign feature allows you to transfer these issues in one operation, without generating email.

To mass reassign Tracker items from one Technician to another:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Click on the link for the desired Tracker.
  4. Click on the "Mass Re-assign Tracker Items" link.
  5. Select the desired Technician to transfer Tracker items from within the "Reassign Tracker items currently assigned to" pulldown menu.
  6. Select the desired Technician to receive these Tracker items from within the "To new assignee" pulldown menu.
  7. Click on the "SUBMIT" button.

Removing a Technician

To remove a Technician from a Tracker:

  1. Mass reassign any Tracker items assigned to the Technician you plan to remove.
  2. Click on the "Tracker" link for the project.
  3. Click on the "Admin" link.
  4. Click on the link for the desired Tracker.
  5. Click on the "Add/Update Users & Permissions" link.
  6. Check the "Delete" checkbox next to the desired Technician.
  7. Click on the "Update Developer Permissions" button to remove the Technician from the Tracker.

Disabling a Tracker

Project administrators are encouraged to disable unused project services, such as unused Trackers, to avoid user confusion. Our Data Preservation Policy provides step-by-step instructions for disabling a Tracker.

The SourceForge.net staff use the Support Request Tracker and Feature Request (RFE) Tracker, but disable the other Standard Trackers. In our case, we have decided that the Support Request Tracker will be used both for support issues and bug handling, since there is significant overlap between these issue types for our project (support of SourceForge.net via the alexandria project).

Removing Tracker Data

Per the SourceForge.net Data Preservation Policy, no means is provided to completely remove a Tracker. Trackers may be disabled, which will prevent their use.

Individual Tracker items may be removed by SourceForge.net staff.

Sensitive Issue Removal

Tracker items are generally visible by all site users. No means is provided for a project team or issue submitter to remove a Tracker item.

Per the SourceForge.net Data Preservation Policy, SourceForge.net staff will consider the removal of Tracker items if they include sensitive information, such as telephone numbers or addresses.

Custom Tracker Creation

Each project is provided the same standard set of Trackers upon project creation. Projects may also create their own Custom Trackers, allowing handling of issue types specific to a project.

The project used to manage support for the SourceForge.net site, the alexandria project, uses Custom Trackers to manage special groups of data that fall outside our support handling procedures for what we regard as normal support requests. These include the reporting of project takeover requests, priority support requests from subscribers, and issue reports related to donations.

To create a Custom Tracker:

  1. Click on the "Tracker" link for the project.
  2. Click on the "Admin" link.
  3. Enter values for "Name" and "Description" in the "Create a new tracker" section of the Tracker Admin page. All other fields in the form are optional.
  4. Click on the "SUBMIT" button.
  5. Add Technicians and Admins to the new Tracker.
  6. Set up Categories, Groups and Canned Responses for the new Tracker.
  7. Configure Tracker options.

While Standard Trackers will appear in the project navbar menu (Bugs, Support, RFE, Patches), Custom Trackers will not appear in the project navbar menu. Custom Trackers are accessible from the Tracker listing of a project.

Tracker Item Moves

Tracker items may be moved between different Trackers on a project. No means is currently provided to move Tracker items between different projects.

You may move a Tracker item to a different Tracker if you are a Tracker Admin on both Trackers, or if you are a project administrator.

To move a Tracker item to a different Tracker:

  1. Access the desired Tracker item.
  2. Select the destination Tracker in the "Data Type" pulldown menu.
  3. Click on the "Submit Changes" button.

If a Tracker item has moved to a new Tracker, old URLs referencing that Tracker item will be incorrect. If you access a Tracker item using a URL that references the old Tracker, a message will be provided similar to: "ERROR: Artifact: Invalid ArtifactID; this Tracker item may have moved to a different Tracker since this URL was generated -- [Find the new location of this Tracker item]". This message will include a link to the new location of this Tracker item. We provide this link rather than redirecting to the new location of the Tracker item as that users may know that they need to update any documents that reference the old link.

During a Tracker item move, the values of the "Category" and "Group" fields will be preserved if a category or group of the same name is found in the destination Tracker. The value of the "Assigned To" field will be preserved if the designated assignee is a Tech or Tech/Admin in the destination Tracker. If these fields cannot be preserved, they will be reset to values of None or Unassigned; issues may need to be reconfigured after transfer if this occurs.

External Links to Tracker Items

You may link directly to a Tracker item using the following URL format, where TRACKERID is the identifier for the Tracker item to access: https://sourceforge.net/support/tracker.php?aid=TRACKERID

Use of this link format is encouraged when referring to Tracker items from within Forums, Mailing List posts and project web pages.

Patches

The Patches Tracker is one of the Standard Trackers provided to each project.

Patches are used to merge changes from an updated file in to the original version of that file. Patches allow these changes to be distributed without requiring the user or developer to retrieve a full copy of the file, saving download time and disk space. Patches also allow the easy review and comparison of an updated version of a file to the unmodified version of that file.

There are several common formats of patch files used by software developers. These include:

  • diff files, which show changes between text files, such as source code files. On Microsoft Windows machines running Cygwin, Linux machines, and Apple Mac OS X machines, diff files are generated using the 'diff' tool, and may be applied using the 'patch' tool. On other Microsoft Windows machines, diff files may be generated using DiffUtils for Windows and applied using Patch for Windows. On all platforms, CVS clients may also be used for the generation of patches.
  • xdelta files, which are used to create patches to binary file data (diff is designed to work with text data, such as source code, not binary data). xdelta files are generated using the xdelta tool.

The Patches Tracker accepts file attachments. Any patch format accepted by the project may be used. We encourage projects to use the diff format for source code patches, and xdelta for binary file patches.

Users should contact a project team to find out which source code materials should be used as the basis of patches which are going to be submitted to the project team. Some projects prefer patches to be generated from official stable file releases. Other projects prefer patches to be generated from development file releases, source code within CVS, or nightly snapshot releases.

Statistics

SourceForge.net maintains statistical information about each project. Included within these statistics are the total number of Tracker items opened and closed for each of the Standard Trackers.

Within the statistics for a Tracker, a listing of "100 (20)" would represent 100 newly opened Tracker items and 20 closed Tracker items within that Tracker for the referenced time period. Note that there may or may not be overlap in these numbers, depending on the time period selected.

More granular statistics on the breakdown of Tracker items between Groups and Categories may be obtained using the Tracker report tool.

Coping with Bad Submissions and Abuse

Projects are encouraged to provide instructions to their users and designate a Preferred Support Mechanism. These actions will help users to properly report issues to your project. Proper issue reporting will reduce aggravation both for your project team and for your users.

On occasion, you may encounter users that are difficult to deal with. This may be due to unreasonable expectations on their part, lack of understanding of how your project operates, or a language barrier. We encourage all projects to try to deal with support in a patient and understanding manner. If possible, designate a willing and patient team member to handle review of new and existing requests.

You should always try to work out any differences you might encounter with your users. Be empathic, think about how you would react if you were in the user's position. Try to be clear in your instructions to the user and approach the issue from a purely technical perspective, even if the user expresses displeasure or hostility. If you are unable to suitably resolve the user's issue, let them know, and suggest either a workaround or an alternative software product which might better meet their needs.

If the problem continues to escalate and the user becomes abusive, or fails to observe your request not to re-open the issue report after closure, you may report the abuse to SourceForge.net staff for review. Such cases of abuse are reviewed on a case-by-case basis; we will try to either diffuse the situation or ask the user to leave.

As a developer of an Open Source project, you are an ambassador to the Open Source community. While you may not be able to resolve every user-reported issue, conducting yourself with integrity and understanding will help the user to work through issues on their own, either by solving the problem themselves or in finding an alternative software solution to meet their needs, and continue to regard Open Source software in a positive light.

Coping with Long-Standing Issues

Issues that take more than a few weeks to resolve place a special burden on both the project team and the users who reported the issue. SourceForge.net staff use a few techniques within their own Support Request Tracker to reduce this burden:

  • Move long-standing Support Requests and Bug Reports to the Feature Request Tracker, if appropriate. Longer-standing bugs and support issues are often related to features that are not currently present in the software -- these are really Feature Requests. By moving these Tracker items to the Feature Request queue, where issues tend to be have longer response times, you reduce the impact shown in Tracker Reports within the Support Request and Bug Report Trackers, such as that shown in the Aging Report. Reducing clutter in your most actively-used Trackers will help to improve the focus of your support staff. Preventing dilution of stats by long-standing issues will give support staff better indication of their actual issue handling performance.
  • Provide regular updates as comments to the Tracker item. If the issue is not going to be processed for several weeks or months, add a comment to the request designating when the next update will occur (provide an estimated timeframe). For added reminder, change the Summary of the Tracker item to reflect the date you specify for next update. This will help your support staff to more readily know when an issue is past due. SourceForge.net staff generally provide updates once every two weeks on long-standing issues, unless a specific response deadline is specified on the Tracker item instead.
  • Use the "Tracker Listing with Last Comment/Update detail" Tracker report for better oversight of the support process. Periodically review all open Tracker items using this report and provide updates as needed. SourceForge.net staff review all Tracker items in their Support Request Tracker