Last Updated 13 Dec 2022

                                   * * *     OBSOLETE NOTICE    * * *
	 
	 In July 2020 we disabled the old STR bug system from accepting new bugs, as this was           
	 made obsolete by use of the new "GitHub Issues" system. Old bugs can still be managed
	 and closed with the old STR system using the below instructions, which were moved out 
	 of the CMP to prevent accumulation of old info.

	 The following info is here just to help developers manage bugs still in the old system.
	 The techniques here will be phased out at some point in the future when we either fix
	 all old bugs (ha ha) or migrate them to GitHub Issues.

Software Trouble Report (STRs) Management

Software Trouble Reports ("STRs") are submitted every time a user or vendor experiences a problem with or wants a new feature in the FLTK software. STR reports are maintained in a database with one of the following states:

1. STR is closed with complete resolution
2. STR is closed without resolution
3. STR is active (waiting for feedback from submitter)
4. STR is pending (additional information available)
5. STR is new

Trouble reports are classified at one of the following levels by the submitter:

1. Request for enhancement
2. Low, e.g. documentation error
3. Moderate, e.g. unable to compile the software
4. High, e.g. key functionality not working
5. Critical, e.g. application crashes

Level 4 and 5 trouble reports are resolved in the next software release. Level 1 to 3 trouble reports are scheduled for resolution in a specific release at the discretion of the release coordinator.

The scope of the problem is also identified as:

1. Specific to a machine
2. Specific to an operating system
3. Applies to all machines and operating systems

New STRs are posted to the fltk.bugs forum for priority 2 to 5 and the fltk.coredev forum for priority 1 STRs. FLTK developers then discuss the STR and vote to form consensus as to a proposed resolution.

If a general usage question is posted as a STR, any developer may immediately close the STR without resolution using the canned "support is not available" response which directs users to the fltk.general forum.

During discussion, developers propose possible resolutions for the STR and vote to approve them. Each developer posts one vote of +1 (approve), -1 (veto), or 0 (abstain). At least three developers must vote on the proposal, and the total of all votes must be greater than 0. Once consensus is reached, the STR is assigned to a developer that volunteers to resolve the STR.

The assigned developer summarizes the proposed changes in the STR and makes the required changes, attaching a diff of the changes to the STR as needed. The developer then notifies the submitter that the change has been applied and closes the STR when the resolution is confirmed by the submitter or after two weeks, whichever comes first.

If the proposed changes do not resolve the problem, the developer may unassign the STR to continue discussions on the corresponding forum or privately discuss additional modifications with the submitter in order to resolve the STR. When closing the STR, the developer must set the fix version and the first Git revision number which contains the changes.

STR Management: Assigning an STR to yourself

When a developer decides to fix a particular bug in the STR system, the first step is to assign the STR to yourself, so that other developers don't also try to work on it at the same time. If you decide you can no longer work on the STR, unassign yourself from it and add a note accordingly.

To assign an STR to yourself, be sure the website has you logged in to your developer account. Then, when viewing the STR, choose "Modify STR" and modify these fields:

Status: New	Change this to "Active"
Assigned To: Unassigned	Change this to yourself if you'll be fixing this
Subsystem: Choose..	Change; 'Core library' and 'Documentation' are common

Also, check that the following fields are correct according to what's best for this particular STR:

Published:	Change to No if this is a private security issue
Priority:	Change as needed. Unsolved priority 1-3 bugs will prevent a release.
Summary:	Change only if OP's original summary is really misleading
Software Version:	Take note of what the OP supplied

When attaching patches, use 'diff -Naur' or 'git diff', the latter preferred, as it includes FLTK version numbers, useful if years later someone tries to apply your patch. Try to include version#'s in patch filenames (e.g. foo_v1.patch, foo_v2.patch..) so followup patches are clear.

STR Management: Fixing an STR

When you've applied a fix to Git, be sure to update the STR:

Status:	Change to 'Closed w/resolution' if fixed and closing. Otherwise, 'Active' until confirmed closed. When closing an STR, non-devs can no longer update it or reply. (Only devs can reply to closed STRs, and can re-open STRs)
Fix Version: SVN rev#: (leave blank) Fix Commit:	Set the version of FLTK your fix will be in, and add your Git commit# (SHA1) here. Note: The SVN rev# is used only for old STR's.
Additional Text:	Change this to "Fixed in Git repository" if you applied the fix. Usually you only do this when closing.
Notes:	Add any additional details/caveats about the fix you applied here. Often the 'standard message' is enough for simple fixes.