What I’m Learning from my Open Source Contributing ExperienceReading Time: 4 minutes
I’m rolling up on 5 months of contributing to Oppia, the open source tool for creating personalized explorations. It’s really been an awesome experience and I hope to keep going strong for a long time to come. A lot of instructional designers think about learning to code but it can be difficult to understand how it can fit into the work you do every day. There are a multitude of benefits, I think, and I figured it was about time to think about what I’m learning from this experience and how it might apply to my day job.
Here are three things I’ve learned contributing to an open source project.
This experience started with a simple email to one of the project creators, Sean Lip. He then scheduled a google hangout with me and asked me about my interests (imagine that!). He was super interested in helping me to get what I wanted out of the experience and matching my skills to the project Oppia had on board. He even recommended a beginner project (which, by the way are clearly tagged in github). Then, once I got started, I was able to communicate with other project leads, and I had a followup conversation with Sean to ensure that everything was going smoothly.
So to recap:
- There was prompt, positive communication from a project manager;
- I was given agency in what I wanted to work on;
- I was matched with a project that was within my skills; and
- I was supported during the process.
Awwww man, that’s some good onboarding!
So how does that apply to a learning experience? I think the takeaways are agency and support. Whether you are welcoming new employees, or welcoming students to an online learning experience, or welcoming new product users, you can make everything awesome by both creating pathways that you can lead them down (pushing information) and giving them the agency to figure out what most applies to them (letting them pull information), and then supporting them on their journey, however they design it.
As a side note: They are now taking it a step further and have implemented some office hours for newbies using Gitter. I’ll admit I had some concerns about being able to help other folks, considering my extreme newbie status, but when I expressed those I was met with a really thoughtful and helpful reply that, really, even the computer science students and the professionals are still learning; that it was likely that we all would run up against stuff we had no idea how to do and I was encouraged to do my best and ask for help if I didn’t know. Awesome, right?
Open Book, or Looking it Up isn’t Cheating
In the higher ed environment I’m in now (and even in the professional development environment I was in previously), there remains this idea that multiple choice tests rule, that every student should be able to answer these questions with all the knowledge they should have memorized from the course presentations. But the bottom line (which all my colleagues are very passionate about) is that the real world doesn’t work that way.
There may be some things that you need to own in your own head, but many times, declarative-type knowledge is stored away in other forms (notebooks, note-taking apps, documents and documentation, job aids, etc.). The piece the humans have to get good at is synthesizing knowledge from various sources, collaborating with a variety of other people not like them, and solving problems. In other words, not multiple choice test stuff. Of course multiple choice is easy to grade; I can certainly see the appeal in that. But it’s generally super inauthentic and your learners know it.
Whenever possible, we should opt for authentic assessments that allow people to apply their new knowledge. In academia, that could look like making every test an open book test and/or collaborative test, because the questions students have to answer can’t be found by looking it up in the book. Or it might look like creating assignments that have students putting work out into the world (for example, writing and or editing Wikipedia articles and going through their peer review process or contributing to open efforts to transcribe historical letter – both actual assignments created at my institution, by the way!).
Sustainability is Key
The last takeaway is more inward facing than the other two. Oppia has a set of pretty strict styling rules that they enforce both with automated tests and with the code reviews. At first glance, this seemed a bit trivial, but I pretty quickly began to understand the reasoning behind it. Every suggestion to style a comment properly or to move a code snippet into its own document is a move towards sustainability. Make the code easy to read. Make the code modular. Make the code standardized. This is a really important part of software development and project management and the Oppia folks have been doing an awesome job.
But what about us? How many horror stories can you think of where the files for a course or a document left with an exiting employee or were just plain lost? What about all of the proprietary tools we use? Microsoft Office, rapid elearning tools, Camtasia and their camrec files. What happens if we can’t access these anymore? How are we designing experiences that can be rapidly and easily updated, are well documented and accessible? What are we doing to create repositories that get knowledge out of our heads for a time when we are promoted, retire, or move on to a different opportunity? How do we ensure that we leave our organization in an awesome place when we leave? These are not easy questions but the systems we can create to build sustainability into our efforts benefit us as well as our organization and we need to think hard about them.
What do you Think?
Onboarding, open book, sustainability. I’ve been into this stuff previously but this experience brought them all into stark relief. What do you think about these takeaways? How do you act on them in your work?