(Or, in which Maria starts an internship with zero understanding of what it is she’s supposed to be doing.)
I am going to try to keep this post short, which regrettably means my .gif game will not be showing up–the truth is that I’m somehow two weeks behind with these blog entries, so in an effort to catch up, I’m going to try to stick to the main course.
This week’s blog post is explaining your project to a newcomer to your community. I think it’s going to be a relatively easy post, because although I read all the materials going into the internship, it wasn’t until we had our first sync over voice chat that I actually understood what the project even was.
(Yes, I’m laughing at myself too, right now.) I thought the project was to add some features to Tor Project’s GitLab Lobby–a web portal through which people who are interested in collaborating with Tor can request accounts to access Tor’s GitLab, so that they can then make contributions.
In the current setup, people go to https://gitlab.onionize.space/, where they can input an email address and a password requesting access to GitLab, and then a human moderator approves or rejects the request. The moderation is necessary because Tor Project, being focused on web privacy and security and crypto, is constantly under attack by budding hackers and trolls and anybody else that wants to throw a wrench in the works. Four seconds after the Lobby went up and was available to the public, people were trying to take it down.
However, I discovered during my first sync meeting that my project was actually to build an entirely new portal–because the people who keep track of numbers at Tor had discovered that a large percentage of people that request accounts on GitLab Lobby never come back to make that contribution once the request is approved by a moderator. As a result, Tor was probably losing potential bug reports–because a lot of times, when somebody decides it’s time to help out, there’s a very narrow window where you can catch them in a good, helpful mood and get that feedback/note/comment/issue/pull request from them.
Additionally, a lot of people that actually use Tor and would be great bug reporters are super privacy minded (since that is, in fact, the entire point of the Tor browser–to make it hard for companies and entities to track you.) As a result, they’re not big fans of giving out emails and signing up for accounts on a website.
So, at the end of the first sync meeting, I discovered my task was a little more something like this:
Design and build a web portal that interacts with Tor Project’s GitLab account.
Users should 1.) be assigned identifiers that 2.) do not require any kind of sign up via personal details but 3.) can be saved/booked-marked for later in a way that 4.) is instant but 5.) doesn’t create a database entry unless the user has taken an action (e.g., created a note, created an issue.)
Through the web portal, users should be able to 1.) create and update notes and issues that 2.) they can bookmark and look at later, but that 3.) don’t interact with the GitLab API until they’re approved by a moderator.
Additionally, the portal should be able to be accessed with Tor Browser as an onion site with relatively high security settings – which means a minimum of JavaScript, etc.
Oh, I thought. Is that all?
Just kidding. I just about peed my pants.
I mean, I had so many questions. I barely understood how API’s worked, having written two baby apps that did basic API calls and parsed data out of the dictionary. I really didn’t have a solid understanding of how Django handled users and groups, etc., because most of my projects to this point had only one person interacting with them on anything more than a view-only level (me. I’m the person.)
And while I felt pretty strong in my understanding of basic object-oriented programming and CRUD, the focus on security and the desire to keep the amount of hits to the database low made things really interesting for me–for example, if someone wants to put a note on an issue that exists in GitLab but not in the project’s database–should the project create a Note, foreign-keyed to a new issue? Should I have two kinds of notes–notes in the database, and notes in the API?
And the craziest part of all of this was that my mentor, having seen me code some, had complete faith in my ability to accomplish these tasks and was letting me make decisions about how to go about accomplishing them!
And the even crazier part is … he was right. We just had a sync last Tuesday, in which he advised me we were 1.) ahead of schedule and 2.) ready to move this project to a location where testers could start trying to break it–that essentially, we had our minimum viable project.
And … for the most part, it works. When a new user who is not “logged-in” (because it’s not a true login!) visits the site, they can generate a user identifier – which is a six word code-phrase that gets randomly pulled from an approved word list. Once they click “log in”, this identifier is then passed as an argument in each URL throughout the system. They can search approved projects on GitLab, make notes and issues, and leave–all without giving any of their own personal data to the system.
The system itself makes API calls to GitLab using Python GitLab once an issue or note is approved by a moderator–who are the only true “users” of the site, from a Django perspective.
I can’t–like really, really, really cannot–believe how much I’ve learned over the course of the last six weeks. Just a few days ago, I decided it was time to create the “moderator note update” view–so that moderators could make changes to notes before approving them. I think something like that would’ve taken me a few days when I started this project–looking up views and classes and objects and filter tags and trying to make tests and yadda, yadda, yadda ….
It took me an hour. An hour to create the URL path, the view, the template, attach the decorators that would check for staff and permissions, add the custom tags and filters so that everything would render the way I wanted, and write the tests. And somewhere in the middle of writing the last test, I just about had a heart attack, because, surprise, I knew what I was doing.
I, Maria Violante, know what I am doing.
At least twenty percent of the time.