[metrics-team] Trac housekeeping

[Damian Johnson]

Hi Karsten. Just quick food for thought that for my projects I make a
'bugs' landing page. This does two things...

a. Provides nice instructions to users for how to cut a ticket.
b. Embeds a chart with all my component's issues.

Here's an example...

https://trac.torproject.org/projects/tor/wiki/doc/stem/bugs

The only reason I mention this is because 'b' might be handy so all
Metrics folks can refer to that page rather than a more arcane trac
ticket search url.

Cheers! -Damian


On Fri, Sep 1, 2017 at 2:10 AM, Karsten Loesing <karsten at torproject.org> wrote:
> Hello team,
>
> I have been looking through the tickets under Trac's Metrics/*
> components, and I feel we could do a better job keeping only those
> tickets there that we actually plan to work on as a team.
>
> Here's the list:
>
> https://trac.torproject.org/projects/tor/query?status=!closed&component=^Metrics&group=component&max=400&order=changetime
>
> In total, there are roughly 300 tickets on that list, many of which
> haven't been modified in years.
>
> I'd rather want us to use tickets for things we're currently working on
> or that we think we might be working on in the next 6 months. Longer
> term plans could instead go into some "vision" section on the wiki.
>
> But honestly, I believe that a fair number of the open tickets has long
> been forgotten by their reporters and owners. We can probably just close
> 50 or 100 of these tickets without losing much information or without
> risking running out of ideas what to work on in 6 months from now.
>
> How do we start this? Some ideas:
>
>  - We ask the network team whether they mind us closing any of the
> tickets in Metrics/Analysis, and if they do, we kindly ask them to
> either touch the ones they care about and ping us afterwards. Obviously,
> having a sentence or two on the tickets why they still care about
> something and what particular aspects they care about would help. Maybe
> they even want to adopt some tickets into Core Tor/*.
>
>  - We ask ticket reporters and/or owners of tickets in
> Metrics/Censorship analysis whether they still need to keep these
> tickets open. It seems that most of these analyses don't require open
> tickets anymore, and the contained analyses are still useful in closed
> tickets when linked from the appropriate wiki pages. And while we're
> talking about these tickets, we might want to discuss merging this
> component with Metrics/Analysis. After all, censorship analysis is just
> one aspect of analysis, and censorship folks could easily use a tag to
> say that they're looking at metrics data with the primary focus of
> censorship.
>
>  - We make a plan what to do with Compass, so that we can finally close
> some of the tickets in Metrics/Compass. I still believe it's a useful
> service, even though it seriously needs some love.
>
>  - The following doesn't close any tickets, but I'd like to split up
> Metrics/Metrics website into two components: 1) Metrics/Statistics for
> aggregating descriptors and producing CSV files and 2) Metrics/Website
> for everything that's visible on the Tor Metrics website. This doesn't
> imply splitting up the code base yet, though that'll be a useful next
> step. But for now, I'd just like to separate issues/tickets. (Feel free
> to remind me what places need an update when renaming or creating
> components.)
>
>  - Again, this doesn't close any tickets, but I'd like to rename
> Metrics/metrics-lib to Metrics/Library, reflecting that we renamed the
> library a few weeks back.
>
> What else could we do to become the masters of the Metrics/* components
> again? ("Wait, what do you mean, *again*...?")
>
> All the best,
> Karsten
>
>
> _______________________________________________
> metrics-team mailing list
> metrics-team at lists.torproject.org
> https://lists.torproject.org/cgi-bin/mailman/listinfo/metrics-team
>