wiki:org/meetings/2011TorAnnualDevMeeting/FirehoseOutput

2011 Summer Tor Dev Meeting, Waterloo Canada, Session 1, room A, 14:15 - 15:30

This page documents the ideas expressed at the meeting called "Firehose!". The meeting's purpose was to talk about managing the high volume of data on the various channels of Tor communication. Moderator and minute taker: tomb

I am not a stenographer, and I have tried to strike a decent balance between abstracting what you said and quoting some of what you said. Please edit this if you have an improvement over or clarification of my notes, especially if you are someone who is named and you don't like my poor interpretation of what you were trying to say.

high level output

  • tor-assistants is trying to do too much on one list
  • we will split off tor-support from tor-assistants
  • we will publicize tor-support and let support traffic on tor-assistance wind down naturally
  • a community support person will be acquired if possible
  • community development
  • support response
  • FAQs could use more improvement
  • emails containing action items should have the target actor in the TO: header

Minutes

tomb: A concern is that if communication is completely flat (which it isn't) communication will scale linearly with organization growth. O(n)

Runa & arma: tor-assistants has two functions. it is high volume. perhaps we should separate support and assistants.

A community coordinator would help reduce communication overload on dev and similar lists.

nickm speaks about how he organizes his communications: tor-assistants: looks at subj line, throws into a folder to see if someone else has dealt with it, checks back and acts if nobody else did tor-dev: important i read it tor-talk: look at topic, catch up every few days

if not email or IRC use trac to communicate with nickm nickm likes to sift tickets into the right milestones and prioritize new tickets nickm likes to be explicit about when he is on or not on IRC

Q: on trac does nickm check tickets CC'd to him? A: nickm treats every status other than "closed" to be something to read. Important factors: look at milestone, is it in need review? what is its priority? if it higher than major than assume that it either needs to be fixed in 2 days or is from clueless user

Q: how can we make nickm aware of things CC'd to him (sometimes from different components) A: send email or make tor ticket for liaison between projects

nickm: Tor components could be better organized.

Q: how can we make it better? A: nickm is really fast at going through a large inbox where 10% require action. it is small portion of workload.

nickm: When we are actually generating mail, try to pick better subjects. Make it clear who needs to read it.

observation from crowd: it would be nice if there was some way to get through nickm filter other than tor component. there are sometimes discrete tickets from other components.

Erinn speaks about her communication filtering approach Tried not filtering any tor email for a while. Found was sometimes deleting everything. Now filter it and empty cache once a week don't read IRC backlog

like 1 to 1 email, good for productivity not as good at transparency

nickm: add "need information" status to trac to distinguish tickets waiting for a user to reply. may help avoid eternally open tickets. nickm: tickets can have RSS feeds. Paul: give user a better indication that more info is needed.

tomb: so need information state is for our internal trac organization. the user needs more feedback at time of bug report. eg. if you make an account you will get email feedback.

nickm: we should have a good sense of who can/should purge which kinds of tickets? sebastian: too many trac updates can cause signal to be lost in noise

nickm: make people aware when doing triage on many tickets. helps avoid losing signal of important trac changes in noise of many trac changes

blanu: use a separate input stage from users. don't have them put bug reports directly into trac. send them to list where someone extracts useful bugs. sebastian: danger: we sometimes get severe bug from just one user

atagar gave flowchart of his communication filtering strategy which is now attached thanks to rransom.

roger: let's think more about tor-assistants there is some sort of coordination list needed orig idea of tor-assistants was flat communication when we had 7 people. should we stop coordinating en-masse? we should also bring in monthly reports

Sebastian: I want the raw input. want request tracker system. i'm not in favor of dumping all tor-assistants into public, there may be sensitive requests from users. an issue tracker system might be good.

Karen: i need to know about translation needs so i need the full firehose

Nathan: i use structured tracking where bugs can be moved to more and less public areas. people can be copied by email i have liked being on tor-assistants it gave me scope

James Ransom: you need to have someone who can judge what is sensitive information before declassifying. This is difficult. rransom: remember that identification by writing style can happen even in innocuous communication.

someone: should someone be dedicated to splitting general questions and someone bringing things to dev attention?

nickm: this is not a trivial task. need deep knowledge. roger: could be easier than nickm thinks

someone: we could have someone filter for importance on all the lists and IRC

phobos: what conclusions have we come to?

  • proposed community support person
  • mail list splitting
  • pull support out of tor-assistants
  • better yet: move other stuff out, leave tor-assistants in place

roger: great we publicize tor-support

end of meeting


post meeting discussion

rransom: want to recognize CN strings if they cut and pasted from our chinese text? rransom: improve instructions in GetTor e-mail messages

someone: it would be well to have canned responses in many langs. ['kaner-bot'? --rransom] for people with lang. skills and little tech knowledge

roger: do FAQs need to be improved? Sebastian: some people do get confused about stuff on wiki; I know this because some fraction of them asks for help on IRC

Roger: if an issue comes up a whole lot, funnel it to Karsten for potential escalation of priority on that task

nickm: we must not lose existing persona that we have really thought about user questions

tomb: can we compartmentalize emails? nickm: we do that on trac nickm: [reiterates] action items should have actor in To: header, please also use good subjects

phobos: look at redmine, look at rt

Last modified 6 years ago Last modified on Jul 25, 2011, 6:21:22 PM

Attachments (1)

Download all attachments as: .zip