Mozilla Open Leaders: The power of keeping an open source project journal
(Photo by Easton Oliver on Unsplash)
The 6th round of Mozilla Open Leaders program is about to start. If you are didn’t have the chance to apply for this round consider applying to the next one since it is a great and very educational experience. If you are participating in the 6th round, congratulations for joining the Work Open Lead Open (aka WOLO) movement :)
During my training in the previous round I had the chance to learn a great deal of stuff and also experiment on tools and processes with the aim of effectively managing open source projects. One tool that helped me during the 3 month training program of Mozilla Open Leaders was keeping a project journal.
Why create and maintain an Open Source Project Journal?
When you begin working on your project you will be advised to create a project road map. This road map will have to initially include goals for the Mozilla Open Leaders 3 month program and, as time passes, you will be extending it to the future by closing some tasks and adding new ones. Mozilla Open Leaders is a human centric program with lots of interaction (with fellow trainees, coaches, mentors, etc.) something that makes you continually evaluating your project’s goal and adapt appropriately.
So the road map is a sequence of actions we would like to — ideally — follow in order to see our amazing project come to life. But, since usually things aren’t going as planned, you might find yourself held back from those goals. Keeping a journal with the tasks you actually accomplish help you be able to reflect on your original vision and the things you actually accomplished and effectively plan your next steps. Moreover, when contributors start joining your project you will have a well formed summary of what happened to date to share with them and get them quickly up to speed.
TIP: If you decide to create a public open source project journal, try to keep it up to date or your contributors might get the feeling that the project is being abandoned. Remember that, in some cases, your team doesn’t have a view, as clear as the leader of the project, about the project’s status. Keeping an up to date journal can give clarity and transparency to the project.
How to create an Open Source Project Journal?
A journal is nothing more than a dated document with bullets. It works as a summary of how the project is moving forward and its main purpose is to inform anyone working on the projects on what has been accomplished. Therefore it can be a document on your Google Drive or Dropbox, part of your Github project, etc.
I would suggest to create your project’s journal to accompany your project core files. During your Mozilla Open Leaders training you will be introduced to Github. Github is a control versioning system originally created to serve open source software projects but, as you are going to find out soon, it can be used to host open projects with the need of collaborative access to files.
If you work with Github you can use the Wiki feature to create your journal (and other project related pages you might need such as the roadmap, documentation, etc.). In the following image you can see Github’s Wiki environment for my project, HealthyWP, part of the 5th Mozilla Open Leaders round :)
Github’s Wiki Functionality
Part of HealthyWP project’s journal
What to write on an Open Source Project Journal?
The basic goal of your journal is to be a summary of your project’s evolution over time. Imagine it as a ship logbook. Here are some thoughts on what information your journal can contain:
- Events / Information to log
- People involved
- Tags (if you have different types of events you can use tags to easily differentiate the log entries)
For the needs of my journal (kept during Mozilla Open Leaders program) I used the following, pretty simple, structure:
- Record 1
- Record 2
- Record 1
- Record 2
My journal for the Mozilla Open Leaders 5th round
Following you can find the journal I kept during my training in the 5th round of Mozilla Open Leaders.
May 10–11, 2018
- Mozilla Global Sprint 2018.
- Documentation added as a wiki page.
May 9, 2018
- Mozilla Open Leaders Interview: Crowdsourcing WordPress experiences for “healthier” WordPress installations A spotlight on HealthyWP, a 2018 Global Sprint project
April 30, 2018
- Basic business logic of the WP plug-in.
April 24, 2018
- Results from UX workshop.
- Started working on https://healthywp.wordpress.com/
April 2, 2018
- Working to WordPress plugin data extraction.
- Waiting for the results from the UX workshop (soft deadline: April 15)
March 29, 2018
- Participated in 5th UX Thessaloniki Meetup where I pitched the project (and got additional feedback). Also made an open call for volunteers. During the meetup we had the chance to practise UX Research and Design methods:
- User Interview
- Empathy Mapping
- User Jouney Mapping
March 26, 2018
- Repo related documents updated with the new name of the project (README, etc.).
- WordPress plug-in code initialized using: WordPress Plug-In Boilerplate Generator
March 19, 2018
- Project renamed from WordPress Plug-In Observatory to the more “humane” :P HealthyWP.
- Created a minimal website for the project at: https://healthywp.wordpress.com/ using the free plan of WordPress.com service.
- Revised code of conduct using https://www.contributor-covenant.org/version/1/4/code-of-conduct.html
- Contributing (v1.0) using http://oss-watch.ac.uk/resources/meritocraticgovernancemodel
March 17, 2018
- Participated in 12th WordPress Thessaloniki Meetup where I pitched the project (and got quality feedback). Also made an open call for volunteers to help with the project and / or participate to the UX design experiment that will happen on March 29th in Thessaloniki
- The presentation / elevator pitch is available at: https://www.slideshare.net/krap/healthywp-elevator-pitch-at-the-12th-wordpress-thessaloniki-meetup
March 11, 2018
- Changed license to GNU GPL 3.0 in order for our WordPress plugin to comply with WordPress.org’s plugin guidelines (https://developer.wordpress.org/plugins/wordpress-org/detailed-plugin-guidelines/).
- README.md (v1.0)
- Code of Conduct (used Mozilla Community Participation Guidelines).
March 4, 2018
- Github projects added to the project in order to track tasks & milestones.
- During the week, contacted local experts / meetup organizers for help.
- WordPress Plug-In Observatory Project will be presented to the 12th WordPress Thessaloniki Meetup.
- WordPress Plug-In Observatory Project will be featured as the case study (for hands on experience) at the upcoming 5th Thessaloniki UX Meetup. The results of this meetup will be “donated” to WordPress Plug-In Observatory for its UX design and will be applied with the help of the meetup’s organizers (Anthi Malteza & Ioannis Feneris) who kindly volunteered to help.
February 25, 2018
- Open Canvas (v1.0)
- Roadmap (v1.0)
- Github project created to host the code and (probably serve) be used as the project management tool.
Originally published at Apostolos Kritikos.