= Trac Project Ticket Triage = This page lists guidelines and conventions used within the Trac project for [http://en.wikipedia.org/wiki/Triage triage] of tickets. As a matter of fact, we happen to mainly focus on the Milestone information to decide whether a ticket has been triaged or not. Therefore, still to be triaged tickets can be found in queries specifying an unset milestone, like query:status!=closed&milestone= or report:20. There are currently: - [[TicketQuery(status!=closed,milestone=,keywords!~=needinfo,format=count)]] untriaged tickets - [[TicketQuery(status!=closed,keywords~=needinfo,format=count)]] tickets for which we're waiting for feedback - [[TicketQuery(status!=closed,milestone!=,format=count)]] valid tickets to work on... == How to help? == First, there is a good deal of tickets which are not yet triaged. Anyone with some knowledge about the Trac project can help us to apply the triaging rules, in order to detect duplicate requests, eliminate invalid tickets and identify the real issues by assigning them a milestone. For the tickets that are waiting for user feedback, anyone can help as well: close tickets which haven't received the requested feedback since a few months or further process them if they received some feedback. Finally, among the valid tickets, [http://trac.edgewall.org/query?status=new&status=assigned&status=reopened&group=milestone&milestone=%21&keywords=%21%7Eneedinfo&type=defect&order=priority many are categorized as defects]. Those should probably get the most attention or be recategorized as enhancements if they are not real defects. == Milestone == * If resolution is `fixed`, the Milestone should be set accordingly to the Roadmap. * If resolution is `wontfix`, `invalid` or `worksforme` the Milestone 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.5). * If there's no milestone corresponding to a past or future Trac release which seems to be adequate, but the ticket is nevertheless valid and has to be processed further, then the milestone can be set to [milestone:"not applicable"]. This rule is needed as long as we don't have a better way to distinguish among triaged and non-triaged tickets. * //If the feature is more or less a blue sky idea, then use ![milestone:2.0]// * //If the bug or feature seems doable in a reasonable time frame, but doesn't seem to fit in the current schedule, use ![milestone:1.0]// // Note: the above two points are no longer true, as we're redefining the triaging rules between milestones; see RoadMap and googlegroups:trac-dev:fcf1de28cc8a9c49 // See also report:35 and report:36 for the tickets that ''don't'' fulfill the first two requirements and that should be corrected one day. == 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 could be opened with the requested API changes. If it's not very clear what that change should be, it is preferable to keep the request for change next to the use case (i.e. keep that ticket opened for the purpose of the API change). `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. * Finally, if it's the n^th^ time such a duplicate has been created, it's about time to list it in the ticket duplicates hall of fame, i.e. the MostFrequentDuplicates page. And also, don't close or reopen a ticket without a reason. == 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. == Ticket Description == Only administrators can edit ticket descriptions. They are only edited to fix formatting errors, not the actual content. Occasionally, we may also add editorial notes, in order to not spread misleading information, e.g. #4297 or to summarize the current status of a long running issue, e.g. #4132 or #2611. In all cases, it should be quite clear from the formatting what's coming from the original author and what has been annotated afterwards. == 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~=needfixup needfixup] - waiting for corrections from the patch author * [query:group=status&keywords~=verify verify] - the ticket looks to be a valid bug report, but it would be worth that someone actually reproduces it, mainly because the person doing the triage can't reproduce it himself for some reason (different platform / browser / database, etc.) * [query:group=status&keywords~=consider consider] - interesting tickets, mainly for enhancements requests, that are worth to consider in the scope of a given milestone, but for which there's no commitment yet * [query:group=status&keywords~=helpwanted helpwanted] - tickets which are looking for contributors * [query:group=status&keywords~=bitesized bitesized] - bite-sized work items, ideal for new contributors to dive in * [query:group=status&keywords~=review review] - peer review requested * [query:group=status&keywords~=patch patch] - same as review keyword, but when a patch is created by a third party * [query:group=status&keywords~=documentation documentation] - things that need to be better documented * [query:group=status&keywords~=tobedeleted tobedeleted] - "noise" tickets that could eventually be safely deleted one day - 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], [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~=svn14 svn15]), [query:group=status&keywords~=svk svk], [query:group=status&keywords~=mercurial mercurial] - Python compatibility issues: [query:group=status&keywords~=python25 python25], [query:group=status&keywords~=python26 python26] - Other Python packages used: [query:group=status&keywords~=pygments pygments], [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] - Presentation issues * [query:group=status&keywords~=layout layout], issues with the organization of the pages * [query:group=status&keywords~=navigation navigation], main and meta navigation issues * [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~=iexplorer7 iexplorer7], [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~=memory memory] - Out of memory condition, most probably involving memory leaks. * [query:group=status&keywords~=security security] - Security issues with Trac * [query:group=status&keywords~=weird weird] - Bugs from outer space See TracDev/Topics for an expanded view of the above. ---- === Development Notes === (section contains notes about 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''' (suggestions subjecting ticket-close-policies) * 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 * 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) [comment:ticket:4174:15 see #4174] * core developers have final authority to close tickets