In Open Source – Walk a Mile, See a Mile
This is #2 of 5 ‘Draft’ posts I identified as worth wrapping-up vrs. ‘forever a draft’ status.
I wrote this post in April-ish, based on notes I took attempting to reach my goal to contribute to 10 open source projects by July. Some unexpected challenges in my life made this goal impossible, but I still learned a lot… maybe next year.
In January, I set a personal goal of contributing to 10 open source projects by July. A research project of sort, I wanted uncover tools, processes, community engagement, and unknown magic existing beyond my own knowledge and experience. By exploring and researching the modern day experience of contributing to open source, I imagined I could get much better at designing for, and teaching it…
I pledged to myself that I would be select a projects where I could answer the following questions
“I can understand the value of the project on things I care about”.
“I can see how my time might help impact the outcome of that project’s goals, however small”.
Walk a Mile, See a Mile.
I also promised myself, that I would release all arrogance, bias and (most) opinions of how a project might be setup. I adopted “Walk a Mile, See a Mile” to remind myself that the journey towards designing better for people, means being open for what comes next – I would grow with the experience.
In this, my first three months of contributing I’ve already had plenty of adventure.
Searching & Finding
My search started leveraging Github ‘Trending Repositories‘ – something I’ve heard recommended for new contributors. The search is limited to filter for language, which already limits this function to technical contribution – which is too bad.
Suggestion to Github – allow projects to tag their repositories with types of contribution available.
I also wanted to find SQL/PLSQL contribution opportunities, but the top trending project had a commit from two years ago. Maybe that’s just my old timey- skill-set speaking ;)
Suggest to Github – define ‘Trending’, or limit results. Wasting time on a dead or old project isn’t a good experience.
Finally, to fulfill my goal of ‘understanding the value’ of a project I am limited to project descriptions, which was hard.
Suggest to Github – provide optional description that states value of project for contributors, or FOSS projects agree on a CONTRIBUTE.MD standard field any query on the web can pull from (omitting Github as a search). We really need better standards for participation. Blarg.
I went through a lot of repos, opting to select only one from Trending, and the rest from referrals or personal interest, which shows you how much we still suck in OS at surfacing projects people can find in their own. I’ve landed on these 5 to start:
- React Native
- Curious about Facebook community engagement. Assume there are good first tasks I can handle.
- Rust is an inspiring project, with a strong community. Want to learn more.
- Free Code Camp
- Teaches coding, for free, with an angle on helping non-profits. Almost like participation wrapped in a project to help multiple projects? Sounds like my thing.
- Teaches many languages, including Rust, think I possibly I could amplify my Rust knowledge while contributing to framework that teaches it.
- Know Jekyll quite well, assumed could be a quicker one, and a contribution to a project I’ve used a lot actually.
Learning so Far
Including a link from your repo, to your project webpage, or demo is important.
I hated wandering through code, and issues looking to see what a project looks like, or does. I wanted to get in there and play.
9 out of 10 times I will opt to join a chat channel over forums. I’m in a rush like everyone else, so if I can :
a) see conversation
b) ask a quick question, I’m more likely to stick around for a bit.
Free Code Camp does this well, having both on the main page. I’ll have another post on the different chat software I saw, and liked.
Forums felt like a ‘community resource’ (which has a place) when I visited them vrs a way to engage with people.
Welcome bots, that say hello to new users are awesome, but one of the reasons I also use an alias when lurking. Chat should allow for lurking.
Project-specific newsletters are awesome. I didn’t realize how helpful it would be to have a project news letter (for times when I am too busy to contribute). Rust does this well!
Environment builds are still the worst part of ‘sticking’ to a project.
Marc was almost ready to implement his "hello world" React app pic.twitter.com/ptdg4yteF1
— Thomas Fuchs 🤦♂️ (@thomasfuchs) March 12, 2016
I am familiar with many technology stacks, and debugging but I have so far found myself stuck on obscure issues that even the most helpful people can’t get me over in a short period of time. Thinking of limiting build-problems to max of 6 hours before abandoning project. Main reason I seem to get stuck – outdated docs, missing dependencies, or worst (in one situation) building the WRONG environment because Google search brought me to an outdated wiki that had not been noted as so…
I like the idea of Virtual Machines, but I’ve found outdated ones of those as well. Perhaps Facebook and React will provide a new way to help overcome environment first-builds.
Too many ‘Garbage Tasks’
I’ve called these out before. A good first task should not look like this. Remove this label when it’s not longer true. Good first tasks are basic like – changing an error message, or debugging CSS alignment.
‘Help-wanted’ tags aren’t enough to invite new contributors – I needed to see ‘beginner, quick task, or something similar’. Maybe I have less patience than others.
Non-Technical Contribution Is Hard to Find
Really, really difficult to imagine the ways you can help if the project is not specifically about that skill. There’s an entirely different highway for non-technical contributors, and that sucks especially if you are interested in both.
I realize if I wanted to contribute in other ways, that would be different research altogether.
Good Documentation & Support
Free Code Camp has a great contribution page – and I LOVED their Gitter had help commands that allowed people to learn more about contributing, and that they have a specific chat just for contribution which is less intimidating than joining a project team chat head-down in a crisis. I know IRC does this, as well, but IRC is a blocker for many.
Jekyll is also really clear.
I LOVED finding this post ‘Diving into Rust’ from community-member Flaki. Describing ‘use cases’ really compelled me to get more involved in a project that had felt a bit abstract to me still. Found via Google-search. I found this page on Rust documentation a bit too much for getting, although I expect it’s a great resource to come back to.
Again, chat channels not forums were my go-to for project questions.
Code of Conduct Matters
Seeing a code of conduct, like the ones in exercism.io and rust made me feel welcome, not just because it’s there, but because the community decided it should be. I’m glad Jekyll had a COC, but without a clear path for resolution, other than project maintainer – it felt only half-way there. There are people much better than me to review CoC but I’ll say personally, I prefer to know who is behind an alias as well.
And that’s what I’ve learned, and experienced so far. Next post will dive deeper into evaluation of chat channels.
Open Has Walls
An update on one other project, I am very interested in (eventually) lending my skills to beyond this experiment is with #OpenCancer. Creative Commons has joined forces with Moonshot to end cancer in our lifetime. The simple question of ‘how can I help scientists, and others using my technology/open/participation/data skills hasn’t yet been answered. Is open science limited to teaching researchers, or is there a bigger movement to get the rest of us involved? I hope so in this case. Another research project perhaps.
I realize .. we’re only really at the beginning of making participation in open projects feel as accessible for everyone. Its hard climbing the walls of open some days, but we’ll get there.