Hi Nusenu. For the past few days we've been having an internal discussion about how to revamp our process for flagging bad relays. Its been dysfunctional for years and it's high time we fixed it.
These discussions are where the wiki you mentioned came from...
https://trac.torproject.org/projects/tor/wiki/doc/ReportingBadRelays
I was planning to make an announcement after we got our other overhauls in place but you make some good points so might as well discuss this now.
If you are implying that the current process starts with 'let the relay operator handle it', I'd suggest to set the badexit for confirmed bad "properties" *first* (no matter whether they are caused by the relay operator itself or its upstream/ISP) and give the relay operator the chance to request a badexit flag removal upon repair (not the other way around).
Ideally I agree. Trouble is that BadExiting requires manual intervention by the directory authority operators, so adding then removing flags would each create churn for them.
It can range from one hour to several days. It's clearly not good enough at this point and we are trying to get better at it.
Are there specific trac entries for this?
Nope. Trouble is the manual intervention, and actually in the past bad relay reports have often never been acted upon. A particularly bad instance of this is what's prompting us to finally fix it.
The page states several times "let us know" (even in bold) but there is no information on how you are supposed to contact "them".
Those are email links. Is there something we can do to make that more evident? The text previously cited the address but that felt needlessly bulky...
What do you think about creating one where every scanner sends its alerts to? (something similar to the consensus-health ML)
We plan on making a closed list for bad relay reports. That might be a good spot for ExitMap's output too.
[ most of the rest of the questions Philipp will best be able to answer ]
Cheers! -Damian