Present: phw, cohosh, dcf, arlolra.
What did not work well?
phw: Roadmapping, updating the roadmap, keeping it in sync with Trac, tracking time and points, all this management takes more time than we like. Many are unhappy with the way we use Trac and Storm.
Regarding BridgeDB, phw needs to get changes reviewed by someone on the network team, but they are not always available for a quick turnaround. This kind of problem is hard to fix.
- The original plan was to have both phw and cohosh knew BridgeDB well enough to do reviews for each other.
- Is the BridgeDB code that complicated? Somewhat, not too bad.
What went well?
phw: The weekly meetings are smooth. It seems like people get the reviews they need.
Question: how to do reviews? Inline as Trac comments is not very good. cohosh and arlolra have done some on GitHub using GitHub's review tools. cohosh: the plan was to move repos to torproject Gitlab and do all review there, but Gitlab is blocked on anonymous ticket creation. phw: But is everything blocked on that? Could we do review on Gitlab, while still creating new tickets on Trac? Sounds possible.
A big plus about Gitlab: the ability to create your own repos without asking (and waiting for) an admin. Had ideas for repos on git.torproject.org, but never bothered with them because of the hassle.
cohosh: I agree regarding the difficulty of points tracking. phw: Everyone invents their own mechanism for it. What do people use? phw uses Hamster Time Tracker. dcf uses a text file and some scripts to compute time differences.
Quality of code reviews is good.
phw sends assorted emails to various parties; whom should he Cc? He would like to use the team list, but that is not always appropriate when the contents should not be public.
How is it, having the team split between Tor-employed people and outside volunteers? So far, not bad. It was more hectic at the beginning. The anti-censorship team interfaces with many other teams, and many pieces of infrastructure... took a while to figure out what we were even supposed to be doing.
We want to have better outreach/interface with the wider PT development community. For example httpsproxy: there was not anyone in charge of responding to its developer, which can be frustrating. We should strive to at least reply stating that we do not have time, rather than be silent. cohosh: It would be good if we had a document about the PT integration pipeline, for the benefit of outside developers. With coherent steps, e.g., "you must make your code build with Tor Browser," and "we will test a limited deployment to see that it passes traffic."
Question: Is 2 people enough? Answer: No. The small team size is a problem. There's lots of working through technical debt and understanding legacy codebases that prevents innovation. We have longer-term goals that at this point are so far out they're not even roadmapped. For example, rapid response.
On the topic of rapid response, something is better than nothing. I thought there were some documents related to this; are there?
Challenging but not too bad: working with other teams. Recently with the metrics team and the browser team. Idea: teams could send monthly reports, not only of what they did the previous month, but of what they plan to do next month. Would help other teams to plan and work with them. Sounds like a good idea.
The time needed to prepare monthly reports is pretty okay. It helps when team members can contribute some bullet points, but if it's too much of a hassle it's not necessary.
Deliverables vs. desires. S28 and S30 deliverables are reasonable and reasonably well-aligned with what the team wants to accomplish. (But there are also other reasonable things that are not funded.) cohosh is a bit concerned that we'll have to spend a lot of time executing S28's validation requirements.
There are some things we cannot ignore, whether there is funding to fix them or not. Things like BridgeDB being broken, or suppose hypothetically if obfs4 stopped working. Some current sponsors are relatively open-ended, which allows for some freedom. May need to watch out more in the futre.
phw to volunteers: we want to know if you feel overwhelmed maintaining something that you maintain. We appreciate your effort, but we are willing to take things off your hands, especially if you are taking care of it and not being paid for it. arlolra: I'm trying not to agree to too many tasks, in order to avoid getting into that situation. At the same time, we have some time to offer and would like to contribute in a way that is meaningful for the team. cohosh: Any tickets without an owner are fair game. Use the owner field to claim tickets for yourself.
What's the state of our ticket pool? We identified some during roadmapping today that are duplicates or can be easily closed. The ticket pool feels okay. Maybe we should go through once in a while to clear out the duplicates and vague ones.
- Some tickets are not actionable; you don't know when they're done. Some are missing background or motivation explaining why they should be done.
Does the network team do bug triage? How do they do it? It might be good for us to have a process to go through new tickets from the past week (filed by other than team members) and prioritize or respond to them. Maybe talk to the network team to see how they do it. One thing they do is have someone to assign code reviews outside of their meetings.
phw: Do you feel you know enough about what's going on, or do you feel left out? We want people to know what they need to know. dcf: I appreciate not being informed about things I don't need to know about. Communication within the anti-censorship team is fine. Sometimes interacting with the network team, it can seem like decisions come out of nowhere.
P.S. The IRC status: messages, where do they go? Get logged somewhere?