Honeymooning with Atom: The Search for Issues Begins

Includes: Diving into Wikipedia and Why You've Gotta Do Things Yourself

Up and Atom

With the first (and probably only) season of The Contributor: Project Search fully behind me, it is time to fully get into the main task for this semester: working with my team to make some contributions to Atom, and maybe even infiltrating the community along the way. Everyone had struggles with the installation, but together we all managed to successfully install and run a development build of Atom from source. Go team! Now, it was time to step back and try to figure out Atom’s bigger molecular picture.

Packages All the Way Down

The first thing we learned was that what most people consider ‘Atom’ is actually just a bunch of separate packages in a trench coat. Having actually read a good amount of the flight manual, Daniel mentioned several important things about this system: when a user downloads Atom from the site for the first time, the packages included with it are called the default distribution. This is a collection of core packages maintained by Atom, and a starting point for using the IDE.

The Root of the Issue

With such a wide search area for issues, we did what any post-algorithms CS major would do when looking for the shortest path to a contribution: try a breadth first search. We thought up a general approach of first determining the core packages under Atom that have the most potential for beginner contributions, adding those to the queue of potential packages to contribute to, then working through each package in the queue by creating issues or searching for and resolving them. Of course, much easier pseudocoded than done.

After going through several different packages and not really being able to agree on a good entry point, Daniel steered us toward the idea of working on the flight manual first instead of Atom packages specifically. We already had experienced problems trying to use the documentation to install, so it would be much easier to dive in and start contributing.

The Wikipedia Game

I’ve finally started peeking into the huge ecosystem of everyone’s favorite encyclopedia, Wikipedia. They have a very strong philosophy on openness stressed on all the beginner help pages.

Wiki, Wiki, on the ‘Net, How Do I Get My Feet Wet?

Contributing to Wikipedia seems as simple as it is made out to be, though it may also seem like there’s a lot going on. The help pages are extensive, thorough, and abundant, so I expect a gentle learning curve with a relatively quick time getting into actual edits.

Much I Know About Nothing

The challenge for me might be trying to figure out where exactly to make contributions. I have a shallow, passing knowledge of several things, and to me it seems Wikipedia edits will come much easier to people with a deep knowledge of specific fields, like a hobby or deep interest. Nevertheless, there are definitely places where I can make edits, so I will be allowing myself to go down some Wikipedia rabbit holes in the upcoming weeks to find them.

What We Owe To Each Other

In some ways, Open Source is more of a philosophy than just a model, but when it comes down to concrete definitions, the key practical factors essentially boil down to licensing and redistribution. This piece by the fed up creator of Clojure — aptly titled “Open Source is Not About You” — on entitlement in the Open Source community, though highly abrasive, brings us back to re-examine what that means in the context of community. In the gist Rich alternates between emphasizing the idea that users and contributors are not entitled to having their complaints heard, and making it clear that he and the other Clojure maintainers do actually care deeply about the project, care about the community, and encourage and appreciate contributions. I can only wonder as to what kind of arguments led him to write this, but I don’t think this is simply about criticisms of the project. It seems like a response to any argument that would ensue after maintainers ignore/close/dismiss a criticism and a person who believes they wrongly did so attacks them for that. From the language of the post it appears someone made a claim about maintainers not truly caring about community. Rich makes an interesting argument that besides the claim being wrong, it is entirely irrelevant. The beauty of Open Source is that if you ever disagree with an implementation, design choice, or vision, you can simply copy the project and do it your way. The important point here is that you do it yourself, because you can not force the leaders of the project to do anything the way you want (and you should obviously never harass them about it). This isn’t to say community isn’t an essential part of open source projects, but it is to say no one is ever necessarily entitled to a community that accepts everything a person says/does/codes.

Open source is a no-strings-attached gift, and all participants should recognize it as such. -Rich Hickey

If open source is the gift, then maybe welcoming community is sort of like the gift wrapping: a nice addition that most people believe should be used, and most people do use.

For me this raised a lot of thoughts and questions on the ‘social contract’ between founders/leadership/maintainers and contributors/users of a project. What do they owe, if anything, to each other? For example, are maintainers entitled to contribution proposals that meet their standards (i.e following a pull request format, or following the style and conventions of the project) ? And if not (since projects often receive many that don’t), are would-be contributors with contributions that actually meet some guideline owed any more than would-be contributors that don’t? If maintainers are for some reason ignoring a severe security issue in their project are complaints related to it entitled to a response ? (Legally, depending on the license, no, but should they be??)

Someone made a fork of the gist that applies the piece to art in general. It’s interesting that the ideas apply in a similar way there.

const change;

Classes were canceled this week due to the heightening COVID-19 situation, and with so many things changing so rapidly I didn’t get to much of my planned periodic contributions from last week. I did manage to organize my thoughts for an issue in the DuckDuckGo Privacy Extension project’s CONTRIBUTING doc.

---

It is said that the only thing is constant is change, but what can we depend on from our software, and from each other?

export default Boubascript;