Features and Use of the SourceForge Software Development Tracking System

From Bibledit

This is a guideline of how to use SourceForge for development tracking in bibledit.

Contents

[]

Features of the SourceForge reporting system

From the SourceForge tracking the following tools are used:

  • Tracker: (Bug, Support Request, Patches, Feature Request) is for
    • bugreports and proposals/requests,
  • Mail: (only one Data Type) is for:
    • appreciations and qestions and procedural requests.

The Tracker tool has the following subsystems/dimensions:

  • Data Type: Bug, Support Request, Patches, Feature Request, are split (filtered) into four sets from beginning (when clicking Tracker)
  • Category: general, None, check, find ... : Can be filtered out, open set: (items can be added/changed)
  • Assigned to: None, <developer> : Can be filtered out, open set: (items can be added/changed)
  • Status: Open, Closed, Deleted, Pending : Can be filtered out
  • Group: None, v1.0(example) : Can be filtered out, open set: (items can be added/changed)
  • Priority: 1 - Lowest, 2, 3, 4, 5 - Medium, 6, 7, 8, 9 - Highest,
  • Resolution: Accepted, Duplicate, Invalid, Later, None, Out of Date, Postponed, Rejected, Remind, Postponed, Wont't fix, Works for me.
[]

How the SourceForge reporting system can be used

[]

Initial information/reports

Tester: sends in a report and choses one of the following:

  • Bug: Bug
  • Support Request: --- (e.g. Installation of Bibledit in Suse 10.1, Include Unicode characters in counting characters in a project)
  • Patches: (only for programmers to submit a patch: programmed part of the program)
  • Feature Request: Proposal (e.g. build in a formatted view in BE)
  • Mail: for Appreciation or Question

Remark: The initial (Tracker)-reports have only one Status:Open

Programmer: uses

  • Mail: to announce new features (of new releases)
  • (Bug/Support/Patches/Feature/Mail as a personal reminder?)
[]

Feedback information/reports

Programmer has to work on it: Status:Open:

  • Check Data Type: Bug, Support Request, Patches, Feature Request
    • and change, if necessary
  • Resolution:Invalid: feedback from tester, continue to work on it,
  • Resolution:None those are initial reports: Check and tag them
  • Resolution:Postponed: Fix bug or comply with request in later version
  • Resolution:Remind: Fix bug or comply with request in next version/nightly built

Tester has to work on it: Status:Pending:

  • Resolution:Duplicate, check if report corresponds to previous one
  • Resolution:Fixed: check in newest released nightly update version,
  • Resolution:Later: Check at a later time
  • Resolution:Out of Date: Solved long time ago
  • Resolution:Rejected: check progammer's refusal to request
  • Resolution:Won't fix: check progammer's refusal to bug-fix
  • Resolution:Works for me: Check it again

Resolution:Accepted (only for Status:Patches) changes to Status:Done

No more work needed any more: Status:Done:

  • There is nothing to do (any more) on this subject.

Status neither Open, Done or Pending: Status:Deleted

  • This is only for marking a report, that it does not belong to one of the other 3 categories: Open/Done/Pending
[]

General Remarks

Category dimension: Categories are produced along the development and testing of the program. Categories cannot be deleted, but changed (renamed).

Group dimension could be used for marking versions, the problem is that nightly builts are released nearly every day, so only main version should be marked (0.9, 1.0, 1.1 ...)

Priority dimension should be marked: high for urgent things and low for less important things.

Personal tools