Difference between revisions of "User:Gdk/Trac For Dummies"
< User:Gdk
Jump to navigation
Jump to search
| (One intermediate revision by the same user not shown) | |||
| Line 5: | Line 5: | ||
= Developers: Resolve Tickets for Current Milestone (0.84) = | = Developers: Resolve Tickets for Current Milestone (0.84) = | ||
| − | Engineers should care only about tickets that have | + | Engineers should care only about open tickets for the upcoming release, ordered by priority: |
| + | |||
| + | [http://dev.sugarlabs.org/query?status=accepted&status=assigned&status=new&status=reopened&max=400&order=priority&col=id&col=summary&col=type&col=status&col=priority&col=component&milestone=0.84 open tickets for 0.84] | ||
| + | |||
| + | When developers believe that they have a fix in git, the bug should be CLOSED. Not ideal, but we do not yet have the resources to retest changes in nightly builds. | ||
= Triagers: Find New Tickets and Put Them In A Bucket = | = Triagers: Find New Tickets and Put Them In A Bucket = | ||
Latest revision as of 10:12, 5 February 2009
Introduction
The goal of "Trac for Dummies" is to have a single place where we all agree how to use Trac to get our work done. It is a work in progress for now.
Developers: Resolve Tickets for Current Milestone (0.84)
Engineers should care only about open tickets for the upcoming release, ordered by priority:
When developers believe that they have a fix in git, the bug should be CLOSED. Not ideal, but we do not yet have the resources to retest changes in nightly builds.
Triagers: Find New Tickets and Put Them In A Bucket
Triagers: Eliminate Bad Tickets
We should always be on the lookout for bad tickets -- tickets that are inherently confusing because they fall outside of the process. Examples: FIXME.