Monthly Archives: April 2019

breaking up

Just as technology has entwined itself with the act of falling in love, it also has an inescapable role in the act of breaking up. Ending a relationship is hard enough, and made even harder by computing technology.

Clearing an ex-lover from your life is one of the first steps in getting over a breakup. This act is cathartic — it gives you something to focus on in a dark time, a thing to do when you want to do nothing. So, you delete their number from your phone. You archive or delete the text thread you’ve had running for however long. You leave groupchats. You remove their photos from your devices — maybe deleting them, maybe storing them somewhere far away and safe. You hide the emails they’ve sent, the playlists they’ve made for you, and that file of recordings of them reading their favorite book to you.

Then you stop following them on social media.

And immediately social media suggests you follow them.

You’ll continue to see reminders of these people — whether through their activity with your shared contacts or the friendly reminders, the helpful notices, from the algorithms at Facebook and Twitter that think you might possibly know this person with whom you are no longer entangled.

Twitter lets you block people. However:

…please note that you may see Tweets or notifications in your timeline for the following:

  1. Tweets from others you follow that mention accounts you have blocked.
  2. Tweets that mention you, along with an account you have blocked.

These little reminders might be more than you want. You might want a feature to just hide them from you — or to replace every mention of their name with a photo of a kitten. You might want to not see their blog in a shared feed, or to mute them in a social IRC channel.

One of the things we do when it comes to using the internet and web is wind our lives in and out of infrastructure we share with others. We put huge amounts of ourselves into these spaces. The strength and resilience that gives our networks power also gives them the opportunity to tear us down.

FLOSS is about choice (among other things). One of the things we get from developer freedom is the ability to specialize or have specialized technology — the development of features and tools, the fixing of bugs and anti-features.

Would I go as far as to say that seeing someone mentioned in a timeline is a bug, or that the recommendation I add someone I don’t want to think about to my social network is an anti-feature? Yes. It’s a stance I am taking because, due to the proprietary nature of many of these technologies, we’re waiting for a company to decide to give us the freedom to break up and break off contact.

Breakups are traumatic. They can be deeply and devastatingly traumatic. We can be in positions where we need our networks that are now inaccessible to us, because they are too tied into those we loved and still love, even when we wish we didn’t.

A few quick notes:

Generous friends who read through this before I posted it made the following points, which are valuable:

  • There are people who stay away from web sites like Facebook because the people who abused them use that site, and the risk of being triggered it too high.
  • People also stay away from these sites because they are hiding from abusers, who would be given access to them, whether they’d like it or not.
  • This is also applicable to basically any person, regardless of the reason(s) you may want to avoid them.


I became a Debian Developer towards the end of 2018. I started the process in August 2017 at DebConf in Montreal. Over the course of 17 months I wrote emails, searched the Debian wiki, and learned a lot about the project.

What’s a non-uploading Debian Developer (DD)?

A non-uploading DD is one who does not upload packages to the Debian code base. A non-uploading DD:

  • is member of the Debian project;
  • is allowed to vote about issues regarding the whole project;
  • can log in on most systems that keep Debian running; and
  • has access to the debian-private mailing list.

Why become a DD?

I had two main reasons for becoming a DD: I was told debian-private was mostly vacation notices and baby pictures. I also wanted to vote in the DPL elections.

It turns out -private contains ZERO baby pictures, and choosing who to vote for in DPL elections is hard work.

There are other reasons to become a non-uploading DD. I found that the most compelling one, from my perspective, was the authority and respect that comes along with it. When representing the project, which I have done on several occasions, it’s easier to get things done when you have a title or formal affiliation attached to your name.

I joined the A-H team with the understanding that I would become a DD — they preferred someone with official status in the project be on that team. In addition to empty promises of baby pictures, I became a DD because I wanted to take on more responsibility in the project.

There’s also a certain amount of the feeling of belonging that goes along with becoming a formal member of a project. There’s a lot to say about the value of the recognition of your peers — that they consider you a part of the team.

What do you do for Debian?

I’m on the Outreach and Anti-harassment teams.


The Outreach team coordinates Debian participation in internship programs, specifically, and currently, Google Summer of Code and Outreachy. We participate in Outreachy twice a year, and GSoC during the Northern Hemisphere summer. This mostly includes a lot of paperwork, emailing people to make sure they’re on task, and talking with the home organizations of Google and Outreachy.

Since I do not mentor any projects, this work is fairly condensed, though very demanding. It’s time sensitive, with externally imposed deadlines not of our own creation.

During a period of several weeks — and application periods overlap in March — we:

  • confirm with the Debian Project Leader funding for Outreachy;
  • put our calls for mentors;
  • assist mentors in finding co-mentors when appropriate;
  • evaluate projects, separating them into “approved” and “unapproved” categories, based on whether they meet the Debian participation criteria;
  • fill out the application forms for GSoC and Outreachy;
  • make announcements, calls for mentors, calls for projects, and calls for applicants;
  • field questions and requests from applicants;
  • keep up with mentors during the application period;
  • make formal decisions about the number of interns and who they are based on requests from mentors, available funding, and an amorphous process of reading mentor reports and trying best to judge who will not only be a successful intern, but who will be a successful mentor for a project;
  • keep up with mentors and interns during the period of the internship;
  • make sure everyone gets invoiced and paid appropriately;
  • make sure everyone has a good time; and
  • general other things as they come up.

As a total process, it’s quite consuming at times, but relaxed at other times. I would say that administering for Outreachy is an “easier” process, as the mentors are (generally, overall, usually) more experienced and self-managing. GSoC is also a much bigger program.


I could, and likely will, write a much longer post about this. I gave a talk at FOSDEM on the activities and operating procedures of the team. The quick summary is that we meet every fortnight, discuss reported incidents, and either: make recommendations to other teams about how to proceed or send personal emails to the individuals involved, pointing out inappropriate behaviors, and asking people to be more professional in their project participation.

What did your process include?

Mostly emails. A lot of emails, and back and forth with my AM (application manager). I’m sure many people say this, but my AM was great.

I went through the initial steps — deciding to apply after many, many people convinced me of the validity of my contributions to the project; getting my keysigned by an appropriate number of DDs; recruiting advocates for my application; etc.

Then came the questions and the tests. A big chunk of questions were around philosophy, policy, and procedures of the project. We covered licensing questions, the DFSG, the philosophy of user freedom, how different things within the Debian project are decided, and a bunch of other sections.

There where a technical section of my application, which covered more policy and procedure around how things are done within the Debian project. I worked on a bug (one on a piece of web site content) and submitted the edit on salsa, Debian’s instance of git. I collaborated in documents on, logged into servers using ssh, and encrypted and decrypted a number of files over the course of the procedure.

Why did it take so long?

I started my application in August of 2017, and got my welcome email December 26, 2018. I joked that I was going for the longest application period.

It took so long largely because my AM and I were both very, very busy. When faced with free time, we both frequently agreed to make the decision to instead work on our respective Debian work, rather than the application process. I think I speak for both of us when I say we agreed a lot of the other projects we were working on were more timely than my application.

At DC18, I did a personal sprint on my application, and my AM kindly did a personal sprint reviewing it. We met over IRC to handle final steps later that fall. I finished in November, days before the November keyring update, and my application was reviewed in December.

v** honey cake

V* usually means “vegan” in my world, but this also has a foot note: If you consider honey non-vegan, then this cake is not vegan. It includes a lot of honey. It’s based on the Moosewood Six-minute Chocolate Cake recipe.

A double layer cake, featuring peaches and blackberries!


  • 1 ½ cups unbleached white flour
  • 1 teaspoon baking soda
  • ½ teaspoon salt
  • 1 cup honey
  • ½ cup vegetable oil
  • 1 cup water, juice, or almond milk
  • 2 tablespoons cider vinegar

A photo of cake ingredients, including (left to right) almond milk, apple cider vinegar, baking soda, oil, honey, and flour.


  • Preheat oven to 375 F.
  • Mix the flour, baking soda, and salt in a bowl
  • Mix the honey, vegetable oil, and almond milk (or whatevs) in a bowl
  • Pour the dry ingredients into the wet ingredients.
  • Mix thoroughly.
  • Add vinegar, and watch it bubble.
  • Bake at 375 F for 20-30 minutes.

That’s it! I like to make this when I’m in a rush to make some dessert, because it takes 5-10 minutes to prepare.