I think I would disagree with this. Perhaps it is better to first see how #24422 (moved) turns out, after which I'll probably advocate for splitting Metrics/Website as opposed to merging.
I think I would disagree with this. Perhaps it is better to first see how #24422 (moved) turns out, after which I'll probably advocate for splitting Metrics/Website as opposed to merging.
Yes, this ticket is a reminder for the final step after the integration. I updated the description accordingly.
To me, finding useful names for Trac components has (at least) two purposes: 1) good component names guide our users to file new tickets in a place where we expect them, and 2) they help us organize our work. But I'm not even sure whether this change would make either of them easier or harder. Maybe?
Let's revisit this idea when #24422 (moved) is resolved. Thanks for creating the ticket!
It looks like we're not going to do this. By now, we have all user-facing services on the Tor Metrics website. This includes ExoneraTor and, in this case, Relay Search. Doesn't mean that we should put all ExoneraTor and Relay Search tickets into the Website component. Furthermore, we have code for processing the data behind Tor Metrics graphs which even lives in metrics-web and for which we have an own component Statistics. These are all good reasons for keeping the Relay Search component. And if #24422 (moved) convinces us that we should split up the Website component even more, we'll do that then. Closing as wontfix.
Trac: Status: new to closed Resolution: N/Ato wontfix