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