= Trac Project Ticket Triage = (document status: under development - please provide feedback to increase clarity and completeness) This page lists guidelines and conventions used within the Trac project for [http://en.wikipedia.org/wiki/Triage triage] of tickets. == Status and Resolution == `fixed`:: is used when the resolution of the ticket can be linked to some change in the repository, a code change, a primary documentation fix, a contribution script added, etc. For ticket type '''task''', fixed is used even if there was no trackable change in the repository/documentation. `worksforme`:: the problem reported was not really a problem; the requested feature is already implemented or can be obtained in a different way `wontfix`:: the problem reported is not really Trac's problem; the requested feature won't be implemented because we don't think it fits in the scope of the core of Trac, or the feature is implemented as a [wiki:TracPlugins plugin]. * ''Note'': In some cases however (e.g. #2611), we let the issue open even if the cause of the issue is not directly Trac's fault, so that workarounds and user experience can be collected. * ''Note'': If an API change is required to get a feature to work (that is intended to be implemented as a [wiki:TracPlugins plugin]), then a new ticket is opened with the requested API changes. `invalid`:: the ticket was a test ticket, intended for another Trac, etc. `duplicate`:: there's already another ticket about the same issue * If marking as `duplicate`, include referring ticket #s in both duplicate and duplicated tickets. - In duplicate ticket: ''This ticket is duplicate of #1234'' - In original request: ''#2345 has been marked as duplicate of this ticket'' * We usually let open the ticket which contains the most up-to-the-point discussion about the issue, the one which contains an appropriate patch, or other than that, the oldest ticket. And also, don't close or reopen a ticket without a reason. == Milestone == * If resolution is `fixed`, the Milestone should be set, otherwise it should be blank. * Don't assign a milestone without a reason or patch. * Don't modify a milestone as ''anonymous'' and without a reason. * If adding an enhancement request ticket, don't set the milestone to a bugfix only release (e.g. 0.10.2). == Ticket Title == * [PATCH] prepended - if you are the original ticket creator, then adding `[PATCH]` to the ticket title indicates a patch attached to ticket for review and integration that works for you. == Ticket Type == When the ticket is neither about something that requires a modification to the documentation or the code, use the `task` type. == Keywords == The purpose of keywords is to be able to generate pertinent and focused [TracQuery TracQueries], so use them appropriately. - General indications - influencing the ticket workflow * [query:group=status&keywords~=needinfo needinfo] - waiting on information from the reporter * [query:group=status&keywords~=tobedeleted tobedeleted] - "noise" tickets that could eventually be safely deleted one day * [query:group=status&keywords~=helpwanted helpwanted] - tickets which are looking for contributors * [query:group=status&keywords~=review review] - peer review requested * [query:group=status&keywords~=documentation documentation] - things that need to be better documented * [query:group=status&keywords~=patch patch] - same as review keyword, but when a patch is created by a third party * [query:group=status&keywords~=refactoring refactoring] - indicates a refactoring step (e.g. patch) which changes structure but not functionality - Related to work done in branches: [[br]] [query:group=status&keywords~=setuptools setuptools], [query:group=status&keywords~=workflow workflow] (see WorkFlow), [query:group=status&keywords~=permissions permissions] (see PermissionPolicy), [query:group=status&keywords~=xref xref] (see TracCrossReferences), [query:group=status&keywords~=tracobject tracobject] (see GenericTrac) - Related to some technology/APIs used: [query:group=status&keywords~=datetime datetime], [query:group=status&keywords~=unicode unicode], [query:group=status&keywords~=genshi genshi], [query:group=status&keywords~=wsgi wsgi] - wannabee components: [[br]] [query:group=status&keywords~=attachment attachment], [query:group=status&keywords~=authz authz], [query:group=status&keywords~=config config], [query:group=status&keywords~=custom custom] fields, [query:group=status&keywords~=diff diff], syntax [query:group=status&keywords~=highlight highlight]ing, [query:group=status&keywords~=milestone milestone], [query:group=status&keywords~=mimeview mimeview], email [query:group=status&keywords~=notification notification]s, [query:group=status&keywords~=plugin plugin], [query:group=status&keywords~=query query], [query:group=status&keywords~=session session] - Related to backends and other 3rd party software - ["DatabaseBackend"]s: [query:group=status&keywords~=mysql mysql], [query:group=status&keywords~=postgres postgresql], [query:group=status&keywords~=sqlite pysqlite] - ["VersioningSystemBackend"]s: [query:group=status&keywords~=svn svn] ([query:group=status&keywords~=svn12 svn12], [query:group=status&keywords~=svn13 svn13], [query:group=status&keywords~=svn14 svn14]), [query:group=status&keywords~=svk svk], [query:group=status&keywords~=mercurial mercurial] - Python compatibility issues: python21, python22, [query:group=status&keywords~=python25 python25] - Other Python packages used: [query:group=status&keywords~=docutils docutils], [query:group=status&keywords~=enscript enscript], [query:group=status&keywords~=silvercity silvercity] - Platform specific issues: [query:group=status&keywords~=windows windows], [query:group=status&keywords~=solaris solaris], [query:group=status&keywords~=macosx macosx] (''TODO: there are some Macintosh OS X to fix'') - Presentation issues * [query:group=status&keywords~=layout layout] * [query:group=status&keywords~=css css], [query:group=status&keywords~=javascript javascript], [query:group=status&keywords~=xhtml xhtml] * Browser specific: [query:group=status&keywords~=opera opera], [query:group=status&keywords~=iexplorer iexplorer], [query:group=status&keywords~=firefox firefox], [query:group=status&keywords~=safari safari] - Other kinds of grouping * [query:group=status&keywords~=crash crash] - There's a segmentation fault or other serious OS level error implied. * [query:group=status&keywords~=security security] - Security issues with Trac * [query:group=status&keywords~=weird weird] - Bugs from outer space == Ticket Description == Ticket Descriptions should be treated as "original content". Such content should not be modified, except if the modification is trackable. In the 0.10 version, this can be achieve only by leaving a remark in the ticket description, or by adding a comment of what has been changed. (automated diff is implemented in the 0.11dev version. Until t.e.o has this functionality, ticket-admins should avoid to modify the content, see #4299). ---- === Development Notes === (section contains notes subjecting the development of this document) '''Policy for closing tickets for outdated Trac releases''' * ''eblot'': Following the update Matt did on #4222, I think we also need to document what is / would be the policy for outdated Trac releases (criteria to declare as wontfix, etc.) '''Policy for closing tickets''' * User intentions should be taken in account * Avoid closing tickets without a comment of the reporter * This is especially true if the reporter is an active contributor * Take care of the "wontfix/worksforme-arrogance" * be open minded, and accept that the existent processes have some deficits (for sure there are documentation deficits, that's why this document was initiated) http://trac.edgewall.org/ticket/4174#comment:15