Introduction

Some work within a software project is celebrated. Designing and building a new project from scratch, or adding big features to an existing project, is enjoyable and often prestigious work.

Other work is visible but less celebrated, like adding tests or documentation to a project.

Some work that happens in a project is invisible - only a few people know it's even happening. For example, a community manager might have a a one-on-one conversation with a community member who has been causing trouble, to find out what's going wrong.

Some work is not just invisible but missing entirely. Maybe a project is difficult to use. They need help from someone who can do user research and user design. But no such person exists in the community, and no such work is being done.

Finally, there is work that isn't done and doesn't need to be done. For example, an open source project probably doesn't need a gardener's help getting it planted (unless it's some kind of open source gardening project). We can call this work unnecesary.

The Exercise

Below is a list of kinds of work you might find in an open source software project. Go through and place each item into one of the five buckets listed above (celebrated, visible, invisible, missing, and unnecessary). Feel free to break kinds of work into subparts or add things I haven't listed here. (Also feel free to let me know what you changed so I can potentially update my list!)

Note that you are listed where the kind of work currently is, not where you want it to be.

Don't stress too much over which bucket each kind of work goes in. I use the metaphor of a spectrum because the categories bleed together - something might be kind of visible and kind of invisible, or kind of missing and kind of unnecessary. You can make a mark if something is borderline for you.

If your project has multiple contributors, I recommend each person do this exercise individually at first. You can then do the final step together.

The final step: once you've got your sorted list(s) go through each item one by one and ask:

• (If doing the exercise as a group) Do we agree on where the item is sorted?
• Are we happy with where the item is sorted, or do we wish it was in another bucket?
• What steps can we take to move the item from its current bucket to where we'd like it to be?

The List

(sorted alphabetically)

• accessibility
• accounting
• adding features
• architecture/software design of project
• answering questions (publicly, like in an issue tracker)
• answering questions (privately, like with emails)
• cutting releases
• designing logos
• events (can break into planning, publicizing, and facilitating)
• events (running)
• fixing bugs
• giving talks about the project
• governance (ie making decisions about how the project will be run)
• grant-writing
• handling CoC violation reports
• issue triage
• legal
• marketing
• mentoring existing contributors
• onboarding new contributors
• pull request review
• refactoring code for reliability / improved contributer experience
• setting up CI and/or packaging
• soliciting donations
• task prioritization
• technical decision-making
• user research
• user support
• UX design
• website admin (paying for hosting, renewing registrations, etc)
• writing blog posts
• writing documentation
• writing tests