[tor-project] [important] Trac usage and alternatives survey

[Nick Mathewson]

On Wed, Mar 8, 2017 at 5:37 AM, Peter Palfrader <weasel at torproject.org> wrote:
> On Thu, 02 Mar 2017, Silvia [Hiro] wrote:
>
>> The idea of the survey is to identify what we actually need from a
>> ticketing/wiki tool and eventually identify a solution that has all
>> that we want (or that we can work with).
>
> I forgot to put that on the original survey answer, but something I
> use extensively is this:
>
> o Define my own, personal queries and reports, and have all their
>   results show up on a (personal) page that I look at.
>     https://trac.torproject.org/projects/tor/wiki/user/weasel
>
> Also, it'd be nice to have a ticket/issue state that does what RT's
> stalled does.  /Stalled/ is a state that a ticket can be in, and any
> future action (in particular a reply) by any person moves it back into
> its previous state (or maybe just Open).
>
> In most bug overviews one would hide stalled tickets.  The idea being
> that things that aren't actionable until you get some more input from
> the user should be set to stalled when you request that info.  Until
> you then get that info, there's no point in having the ticket clutter up
> your overview.  (We might also be able to get that with trac, if we
> configure the workflow just right.)

+1 on both of these ideas.

And here is, I think, a must-have for me: It needs to be possible to
make a URL that corresponds to a query.  I don't know of any
bugtrackers that _don't_ allow that, but it sure would be sad if I
couldn't paste a link to a query for (eg) "All tickets in milestone X
in state needs_review".