[tor-project] Moar Project Ideas!!

[Tom Ritter]

On 23 February 2016 at 18:15, Lunar <lunar at torproject.org> wrote:
> David Goulet:
>> On 23 Feb (14:13:15), Tom Ritter wrote:
>> > See https://www.marc.info/?l=tor-dev&m=145440925917524&w=4
>> > (Don't count this as a commitment to mentor, but we can talk about it.
>> >
>> > Custom Alerting
>> > Effort Level: Low-Medium
>> > Skill Level: Low
>> > Likely Mentors: Karsten, Damian
>> >
>> > Tor has a lot of services that run in complicated ways. Bandwidth
>> > Authorities and Metrics archives are two large examples. While DocTor
>> > and DepicTor (consensus-health.torproject.org) provide alerting for
>> > certain DirAuth related concerns - these other parts of the Tor
>> > Project lack them. Improving the alerting around these systems would
>> > give greater confidence in their operation and help resolve problems
>> > faster.
>>
>> Network monitoring GSOC! Very very very good idea! :)
>
> In some ways, that's the case. But if an intern works on monitoring
> software, then we need to think from the beginning about who's going to
> run it and who's going to pay attention to its results.
>
> Otherwise, even if it's the best code ever, it's likely to be a waste at
> the end of the Summer. (Please remember TorBEL.)

Truth. Since I run a bwauth and a collector instance, I'm incentived
to learn, run, and maintain it (and pay attention to the results.)
Especially if I can add my own tests into it easily enough (for making
sure my bridge node/mixminion nodes are still running, etc)

I have crappy tests running now, and while I get more emails than I
like, I know how to tell when things are really breaking.   In my
ideal world they'd improve the skeleton framework I have. If they wind
up picking a language I'm not familiar with, or something that
requires dependencies I'm unhappy with - I'm not gonna lie it's
unlikely I'll maintain it. Just too little time to go around.

-tom