Over and above what’s detailed in these posts, I’ve been splitting my time between working on projects for We Are Open and Outlandish this week. For the former, my ‘home’ co-op in the CoTech network, I’ve been mainly focusing on work for Catalyst and the Social Mobility Commission. We’re working with Erica Neve and Pedram Parasmand on three contracts, helping charities who are rapidly undergoing digital transformation. We had a really successful retrospective on Friday with UpRising, who we’ve been helping in more depth.
With Outlandish, I’m helping with some productisation of similar projects they’ve worked on for a range of clients. I find this really interesting as it’s simultaneously about meeting user needs and about organisational development. I’m also advising around ways in which they can develop the workshops they offer.
I’m fortunate to work with organisations which are so emotionally intelligent, and which go out of their way to be so. One of the reasons for working with Outlandish is to give them some short-term help with project management while they’re a bit stretched. But another reason is to learn from their processes and procedures; although they’ve only been a co-op for as long as us (four years), they’ve been together and honing things for a decade.
When I was at Jisc, one thing that always impressed me was their internal knowledgebase. They used PBworks for that, while Outlandish uses a WordPress installation with a theme called KnowAll. I’ve been wanting to experiment with wiki.js and so this week Laura Hilliger and I set up an instance at wiki.weareopen.coop and copied over existing pages from our GitHub wiki. I’ve set user permissions so that only logged-in members can edit the wiki, and indeed see any pages that are ‘internal’ only.
Other than that, I’ve just been reviewing a document Laura put together for some work we’re doing with Red Hat, doing a small amount of work for our ongoing work with Greenpeace, and contributing to a ‘playback’ of some recent work we did for Catalyst.
Next week, I’m tying up work for We Are Open on Monday, and for Outlandish on Tuesday, before turning everything off and going on a family holiday for 10 days. As my therapist said in our meeting on Friday, as I’m a bit of a perfectionist, there’s no guarantee that I will actually relax during my holiday just because I’m away from home. So I’m actively trying to cut myself some slack. I deliberately went for a slow run this morning and I even had an afternoon nap yesterday. Small steps.
Header image is a selfie I took on a family walk in the Northumbrian hills last Sunday. Inspired by Low-tech magazine’s solar powered website, I loosely followed this guide to create the ‘stippled’ effect. This reduced the size of an 8.6MB image to a mere 36.6KB.
Like Clay Shirky, I think that over-optimising your setup and workflow for now can lead to long-term anachronism. He says:
[S]ince every tool switch involves a period of disorientation and sub-optimal use, I have to make myself be willing to bang around with things I don’t understand until I do understand them. This is the opposite of a dream setup; the thing I can least afford is to get things working so perfectly that I don’t notice what’s changing in the environment anymore.
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.
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. 🙂
Shirky, as ever, makes some really good points but the key for me is the way how well he explains the significance of Git version control software – perhaps most commonly used via Github. It has democratic features built into its core.
Watch the video through to the end and you’ll understand why we at Mozilla are trying to create a generation of Webmakers – people who can tinker with the web and, by extension, engage in participative, democratic activity.