I’d like to thank to Oliver Quinlan for his reminder about sharing the ordinary:
It’s easy to get caught up… in your own area. When you are striving to keep improving and you are getting better and better, you focus on the small improvements, how you are as compared to the next best person. Often it’s easy to forget how far you have come and how valuable it could be to share that journey with someone else. When the thing you are working on is niche it’s easy to forget that others might be treading the same path, or might decide to if only they knew the path existed.
I write my weeknotes both for my own benefit (what I did, when) and for the benefit of others (especially colleagues) who might be interested in my work.
The problem is that these weeknotes don’t explain how I work and how it all fits together. Given that this changes on a regular basis, it’s worth documenting regularly. I’m definitely a believer in the Clay Shirky school of workflow:
I know people who get everything in their work environment just so, but current optimization is long-term anachronism. I’m in the business of weak signal detection, so at the end of every year, I junk a lot of perfectly good habits in favor of awkward new ones.
Before I start, and by way of context, it’s worth saying that this week Mozilla – and the #TeachTheWeb team in particular – has launched Webmaker Training. This is a four-week course to help people learn four strands of related to web literacy and contribution: Exploring, Building, Facilitating, and Connecting. More about that in this blog post.
I’m currently working on Webmaker and Web Literacy badges. This isn’t an easy process – even within the organisation that spawned them! I’m currently looking at ways in which we can ‘breadcrumb’ contribution for participants throughout Webmaker Training so that they end up with a newly-redesigned Webmaker Mentor badge. Behind all that, however, is technology that’s shared across Mozilla and a newly-formed Badge Alliance, cultural differences, various assumptions and experiences, a distributed workforce, and attempts at a co-ordinated visual design. I’m doing my best!
Something that I’m still getting used to in a product-driven environment is the idea of an issue tracker. We use Bugzilla (fugly, but efficient and open-source) and, to a lesser extent, GitHub (closed-source itself but supports working in the open). You can see an example of working in Bugzilla with this ‘bug’ and a similar situation in GitHub with this issue.
Speaking of issue trackers, if you’re interested in implementing one, probably the easiest thing you can do is to set up a Trello board with cards in three columns: To Do, Doing, and Done. At the end of the week, you simply ‘Archive’ everything in the Done column.
(click on image to see live Trello board)
Perhaps once I’m at one with the Matrix (i.e. can use Bugzilla more effectively) I won’t have to use Trello as well, but for now it’s saving my sanity: I just link the Trello card to the relevant bug. You’ll notice that I’ve also added another column for Stalled and References (current). That’s just so I don’t forget stuff. 🙂
The great thing about whatever system you use – Trello, GitHub or Bugzilla – the ideas underlying them are the same.
- Work openly
- Anyone can file bugs/issues/tickets
- People can opt-in or opt-out of getting updates
- Bugs/issues/tickets can be assigned to people
- You can link out to relevant resources/context
- Bugs/issues/tickets can be closed when done
It takes a bit of a shift in thinking, but I can’t help but think this would benefit every organisation I’ve ever been part of. Imagine, for example, a school where not only staff, but parents and students could file bugs/issues/tickets to make the community stronger? Wow.
Do YOU or your organisation use issue trackers? I’d be interested to find out more. 🙂
Image CC BY-NC-SA Giorgio Fonda
