I find it interesting to watch how individuals manage their workload and how leaders manage the workload of a team. I find it more interesting to observe the productivity of individuals and teams (what did they actually produce?). I find it even more interesting to learn how individual workers and leaders of teams perceive their productivity (are they aware of what they’re actually producing or only focused on being busy?).
I’m going to share some background on my motivation to create a system within MediaWiki to track actions and relate those actions to wiki content. Then I will give you a brief overview of how this works and how you can use it in your wiki.
Prioritization of work
One of my pet peeves is when someone says “I didn’t have time to do that”. We all have the same amount of time. The better phrase in this case would be “I deemed that task lower in priority than these other tasks and so I chose not to work it.” Pedantic? Possibly. But at least it’s more honest.
Several years ago I read The 5 Choices. One concept from that book that stuck with me was a simple grouping of tasks into four categories. Franklin Covey calls it the “Time Matrix”.
I’m sure many people have already seen this and have talked about it, so I’ll keep my thoughts on this brief. But if you haven’t read the book, check it out.
Put simply, we should be deciding which tasks are unimportant and we should be declining those. For important tasks, we need to minimize the volume of urgent work that falls upon us so we can prioritize focus on long-term, important work. One way to stay ahead of schedule deadlines, to minimize panic, is to plan better.
Sure, there will always be emergencies, things that break, chaos. But it’s those self-inflicted crises that could have been avoided if you had only planned better.
This seems super simple and obvious, right? Focus on important work and plan ahead. But I see so many people perpetually in reaction mode. It baffles me.
Action tracking in a wiki
Semantic Actions is an extension for MediaWiki that I created. It has a few dependencies, but otherwise it’s a pretty simple thing to install. My goal was to have the action/issue/ticket tracker functionality of GitHub and GitLab, but in MediaWiki.
The attributes of an action are simple, by design. Actions are meant to be discrete tasks completed in a brief amount of time. An action shouldn’t have a due date 6 months out because it takes 6 months of work to do this one thing. It should be to indicate that this action doesn’t need to be started until 5 1/2 months from now.
The two fields in this form that are likely not intuitive are “Labels” and “Related articles”. Let me elaborate on how to use these most effectively.
Labels are generic descriptors intended to be used to filter actions (e.g. "Low priority", "In work", "Bug", etc).
Related articles are literally any page in the wiki. The generic footer can be configured so actions automatically show up in the footer of the wiki page for each related article. Related articles are also used to define which actions are displayed in an action board.
In this example action board, we don’t want to see all the actions in the wiki. We’re on the page “Pump module” and only want to see actions about the pump module. So in the action board, we filter by the related article field and only show actions that have “Pump module” in the related article field. Note how each action block has “Pump module” in a gray box. This indicates each action shown here has “Pump module” tagged as a related article.
Then there are labels and action board columns. The labels for each action are indicated by the colored rounded-corner rectangles. We configure the action board to filter the actions based on labels into columns. In this way, we can use labels to outline a workflow.
Your workflow could be something like a timeline sequence: Backlog, In work, In testing, Ready for review, Ready for production.
Or your workflow could be based on sub-teams: Hardware, Software, Operations.
By using these related articles and labels, we can now allow multiple teams using one wiki to filter their actions based on project (related article) and further filtered by workflow (label).
A brief aside on design choices
I’ve received some criticism on these fields. A few people have come to me with suggestions on how it could be better if only it had more values for “Status” or if it had more fields to track discussions, updates, the background story, blah blah blah get back to work.
No.
Recognize the difference between an action and a project. You will have multiple actions to complete a project. Actions are not meant to be drawn-out over lots of meetings. They are meant to be done swiftly.
The only status options are “open” and “closed” because labels provide the flexibility for you to create your custom workflow status indicators without requiring a software developer to modify hard-set options.
There are no unique fields for ongoing status updates because these are actions, not projects. Divide your workload appropriately and use this tool to track getting specific work done.
More details on use case options
See the Semantic Actions repository README on GitHub for more details on how you could use this extension.
If you find this sort of thing interesting please provide feedback in the comments.