wiki:org/meetings/2017Amsterdam/Notes/HowcanTorbemorewelcomingtodevelopers

Facilitator/note taker: Garrett Robinson.

Start with introductions. Go around in a circle, sharing: name, preferred pronouns, and relationship to Tor Project.

Attendees:

Gabriella (Biella) She/her Alex He/his Joined network team of Tor in February Steven Murdoch He/his Researcher at University College of London Worked on Tor Browser Supervises students who want to work on Tor, but end up dumped in the deep end Taylor They/them Just joined as a Tor core developer Filippo He/him Works for Cloudflare Main interest is from experience at Recurse Center, internships at Cloudflare. How can we get those communities contributing their efforts towards Tor? Ivan He/him ThoughtWorks Ask: how many people have successfully contributed code to the Tor Project? About 1/2 of the group. Go around and ask them to share their experiences

Alex, who recently joined Tor as a core developer on the network team, shared: when Alex joined, he started by having an initial chat with Nick on IRC, then built up a tree of interconnected issues to work on. Since he was hired as a core developer, he expects to be working on codebase for a long time, so he also has long-term maintenance tasks in mind.

Development decisions are primarily driven by the specific goals of Tor's sponsors (e.g. the specific deliverables attached to grant funding). Alex said the network team basically considers external contributions to be equal to internal ones. Informal strategy: employees must work on sponsor's deliverables, try to use external contributors to do important things that are not covered by specific grants/sponsors.

Alex mentions that some Trac issues are tagged as "easy", and this is meant to indicate that they are good "first issues" for external contributors. Filippo: this is a good thing to advertise, aka "help wanted." Alex says he does not think these "easy" issues are well-advertised or easily discoverable.

Filippo: One thing that makes it difficult for external contributors to get started is they are accustomed to the mental model of contributing code on GitHub, GitLab: pull requests. Make a fork, code on stuff, do the review, all on one website. Debate: are these lower quality contributions? Maybe, but that's also how you get any contributor (including potentially excellent ones) started.

How does a review go right now? Alex: For the core tor daemon: Use gitlab.com for "big" patches (~ over 100 lines) Otherwise, in-line comments on diffs in Trac Sylvia (sysadmin) working on setting up Gitlab for Tor. Would a self-hosted GitLab be ok? Maybe not as good as GitHub, but better than current state of affairs. One way to get people to get visible "credit" for their work: mirror repos on GitHub. Apparently Tor already does this?

Tor does not have a review tool right now.

Steven: shared his experience of working on Tor Browser. SVN was bad news, but has since been replaced with Git. Tor Browser underfunded. Testing was not great. There was not CI at the time, there is now(?).

Steven often assigns his computer science students to projects that involve modifying Tor. It's usually a challenge, primarily because most university students don't know C very well. None of his students stuck around as long-term contributors. Google Summer of Code are better to analyze in terms of who sticks around and who doesn't. Tor is doing GSoC again this year (yay!)

Ivan shared his experiences of trying to contribute to Tor while working on a team of 3-4 ThoughtWorkers who were assigned to contribute to Tor as part of their work at ThoughtWorks. They explored the website and source code repositories, found a project aimed at increasing test coverage, thought it looked interesting and well suited to their skills/experience. They used call graph analysis to rank most heavily used functions, then wrote tests for them. Opened a ticket for each function and the associated tests. Each ticket was waiting for 2-3 months before review started - at which point the contributors had mostly moved on, and it was difficult for them to go back and work on them/merge them. Submitted about 10 tickets, only 3-4 eventually ended up being merged.

This was a frustrating/disappointing experience. Side note: documentation for running integration tests with chutney could be improved.

The Thoughtworks team also attempted to specs: guard selection for hidden services. Took a draft spec, made a bunch of changes, added support for chutney scenario. Feedback process for spec changes also took a lot of time. Tried to go IRC channel a lot to chat. Eventually they got a ton of really good and useful feedback on the mailing list, but they were waiting for > 2 months again

First time for tests: just picked that work up from scanning the website. Did not ask people on mailing list or IRC if that work was wanted at that time. For the hidden service spec project, did ask around first: "we want to work on hidden services, what should we do?" Near the end, George/asn started helping and his feedback enabled them to make progress.

General complaint: list of projects/tasks online is out of date. On the wiki/website: it's often very difficult to figure out what information is out-of-date.

nickm has this "review group" concept. Since he builds up so many patches that need review, needs to coerce others into reviewing his patches.

Idea they are considering in networking meeting: weekly rotating role to triage new bugs.

Some people are so focused on specific tasks that they can't really be interrupted to work on other things, do reviews, etc.

Team has been underpowered and has made this problem a lot worse. The more and sooner that the team can upskill and take over some skills from nick (review, merge), the better.

More people contributing to the fuzzing project would be awesome.

Humans (nickm) run tools like valgrind, static analysis. Suggestion: couldn't we automate this? Request: up-front automatic CI upon submission of patch/pull request. Currently there is automatic CI, but it only runs after merge. Sylvia is going to hold a whole session about this whole process.

Low-quality review comments about code style are not a problem in main Tor. Have some nice tools for: make check checks for code style issues, there is a nice automated release notes generator.

Question: how can we attract people to come to Tor in the first place? Biella: Tor developers give talks in CS departments, especially to first years, or seminar for students about to graduate. Filippo: Recurse Center. A 3-month retreat for programmers in NYC. Free, pretty structureless. In every batch of programmers, there is a running joke that at least 1 person will always write a BitTorrent implementation. Also, every time, people ask: how can I learn to contribute to open source projects? Strong alumni community. Something that would be useful: introductory documents. "This is where you start. We use Trac. This is where you submit something. Here is a walkthrough of the codebase." Filippo would be willing to write an outline of what would be useful. "Where should I go with this specific type of query?" A lot of this info exists in written form, but it's not well-organized. Steven: A harder, but potentially useful thing to do: restructure the code so it is easier to document/understand/change. Did a call graph analysis, almost every file talks to every other file.

Taylor: weird trend, people tend not to want to move code from one file to another

Some discussion about creating a "developer portal" for Tor Project. Would be a good place to host introductory documents for new contributors, links to good first bugs, etc.

Alex: Idea from Gentoo: regular "bug day." Dedicate a time/day (e.g. Sunday afternoon) where core contributors can have a kind of "office hours." Challenge: writing tests for code that is not very modular, and modularizing code that does not have enough tests. (Classic chicken-and-egg problem)

Nice to have, for talking about Tor at universities: a shared "template slide deck" about what's going on in Tor development would be helpful. Most useful thing would be a single slide deck that is regularly updated. Slides would have to have quite extensive notes, or links to detailed notes elsewhere.

---

Hope this helps! These are mostly my original notes, lightly edited for organization and clarity. If you have questions, or would like me to try to summarize/digest this into a more concise set of recommendations/suggestions/ideas, let me know!

Last modified 20 months ago Last modified on Mar 27, 2017, 6:37:07 PM