These pages about different languages / apis / best practices were mostly jotted down quckily and rarely corrected afterwards.
The languages / apis / best practices may have changed over time (e.g. the facebook api being a prime example), so what was documented as a good way to do something at the time might be outdated when you read it (some pages here are over 15 years old).
Just as a reminder.

Workflow for handling a reported bug

process to keep track of a bug and have them under control

See also Release cycle workflow and Release/test server setup.
The workflow processes have overlaps and are meant to be working together.

This is an example process for handling bugs in Mantis, note that it is generic though, so can be applied to any issue tracking tool. See full description below the diagram.

Bug reporter
reports bug
reviews bug
More info needed?
Already fixed?
Duplicate bug?
Will not fix?
Assign to "DEVELOPER"
Developer picks bug
More info needed?
"Resolves" bug
- enter mantis # in git comment
- paste github history url
in mantis note
Release manager puts code on test server
For all "Resolved" bugs:
- set "Fixed in version" to tag
- assign to "TESTER"
A tester
tests the bug
Bug fixed?
Set status "Closed"
Set status "Closed"
and add note (if necessary)
Assign back to Reporter
and add note
Assign to "FAILED"
and add note
review "FAILED" bugs
Should bug be fixed
before release?
Assign to "DEVELOPER"
Assign back to the developer
that handled the bug
Bug handling process
  • Reporter - the person creating the bug (can be anyone with access to mantis)
  • Bugmaster - reviews the unassigned bugs and rejects or passes them on to the developers
  • Release manager - (see release.txt) the person reviewing and putting the code on stage / test server
  • Tester - tests the resolved bugs and closes them or rejects
The bugmaster and release manager have to work closely to sync when the code goes on server and the testers can be informed, as well as exchanging info if the testers found any problems.

Virtal users
  • DEVELOPER - virtual user, where all open tasks are that the developers can take on
  • TESTER - virtual user, the tasks we want the testers to test
  • FAILED - virtual user, where testers assign all bugs that failed when testing
  • New - new bug, needs to be reviewed
  • Feedback - something needs to be clarified (missing info or other questions)
  • Assigned - neutral status when assigned to a user
  • Resolved - the bug has been corrected, not yet tested
  • Closed - the bug has been fixed (or alternatively will not be fixed / is duplicate of other bug)
The reporter reports a bug, the bug becomes the status "new" and is not assigned to any user.
The reporter also gives the bug an initial severity / priority (how critical and how urgent is the bugfix), alternative leaves that to the default settings.
Bugmaster reviews the bug, either closes it (e.g. it is duplicate, not a problem / will not be fixed), assigns it back to the report for more information or assigns it to the virtual user DEVELOPER.
The bugmaster might also adjust severity/priority.

The developers takes the bugs themselves from DEVELOPER, they will take the bugs in the order of priority / severity (a pre-created filter that sorts the bugs in this order exist).
If it is clear that only a specific developer can handle the bug, the bugmaster or someone else, can assign the bug directly to that developer.
If the developer needs more information, e.g. cannot reproduce the bug or some clarification is needed, he will make a note regarding what he requests and assign it to the appropriate user (could be the original reporter, but could also be some other user, e.g. developer that worked on similar problem)

When the developer has completed a bug, he will set the bug status to "Resolved" and in the code commited to git he will mention the mantis number, e.g. "corrected spelling, bug #1234" and he will copy the github url to the commit in the note in mantis when changing the status to "Resolved"
This will make it easy to track why a specific code change took place, and in case the bug (or a similar bug) reappears later we can back trace what code changes had been made to fix the bug

When the release manager puts code on the test server, he takes all "Resolved" bugs and change them to Fixed in version "rel_XXX" which is the tag set for releasing the code.
That way we can keep track when we fixed which bugs. Mantis will automatically give us a change log for every version.

The release manager assigns the resolved bugs to the virtual user TESTER

The release manager informs the testers that there are bugs to be tested.
The bugs that have fixed are set to status "Closed" by the tester.
The bugs that still have not been fixed / not completely fixed / or related problem has appeared due to the code change, will assign the bugs to the virtual user FAILED.

After testing has been completed, the bugmaster will review all bugs that has been assigned to FAILED and handle them;
- assign back to "DEVELOPER" in case the bug does not need to be fixed in this release
- assign back to the developer that fixed it, so he can fix the bug straight away

Additional notes
Any person can add notes, attachments, connect a bug as related to other bugs etc, the only field that should be left alone is priority which is solely handled by the bug master (to make sure the priority of bugs are not changed randomly).

More programming related pages

Workflow: Release process
Workflow: Bug tracking
Teambox (Redbooth) - Mantis connector
Design Patterns
Git & Github
Go / Golang
CVS backup script
Distribution process
Installation script
Java Server Faces
Perl tips
Perl links
Python / py2app
Shell scripts
Facebook / Opengraph
PHP developer notes
Redbooth API through php
Website optimization
jqTableKit demo
Javascript / html / css links