In Whistler earlier this year, we gathered together a group of code contributors to better understand what barriers, frustrations, ambitions and successes they experienced contributing code to Mozilla projects. Above all other topics, the ‘task description’ was surfaced as the biggest reason for abandoning projects.  This, the doorway for participation is given the least attention of all.

As a result, I’ve paid close attention recently to how projects use tasks to invite participation, and experimented a bit in our own Participation Github repository.  Probably the best opportunity to understand what makes a task truly ‘open’ is to  to witness in ‘real time’,  how contributors navigate issue queues.   I had such an opportunity this week at the ‘Codeathon for Humanity’ at Grace Hopper Open Source Day, and previously leading an Open Hatch Comes to Campus Day at the University of Victoria.

Based on all of these experiences I want to share to my thoughts on how we’re currently using tasks, and how ‘How to Write a Good ‘Open’ Task’. The act of creating tasks in an open repository is not itself an invitation to participation. Lets be honest about the ‘types of tasks’ we’re creating, and then just design properly for those we intend for participation.

The Garbage or ‘Reminder to Self’ Task :  I see these everywhere – and witness the havoc they play on contributors.  Garbage tasks create a lot of noise in issue queues, they are the expired, the ‘now irrelevant’ and the ‘notes to self’ variety of tasks that were are no longer, or never where –  intended for participation. Often because these issues are so low in priority lists, their descriptions are often non-existent.

Meta Task: Contains a broader picture of goals, and contains more than one action. Could also be called a Feature Task as completion is usually a collaboration between individuals and extends beyond a single milestone or heartbeat.  Meta tasks are a great way to track how smaller tasks can lead to bigger impact. For a project they make sense, but for a contributor it’s hard to understand how to break off a piece of work, and what’s already being done.  The Participation Team prefixes Meta task descriptions, but perhaps we can be even clearer.

Storytelling Task: I see lots of these as well: tasks already assigned to, or implied as tasks for certain individuals or groups.  You can recognize these because comments are more of a conversation, and place to share status and invite feedback.  Storytelling tasks are a great way to bring the story of a team’s work to the center of all activities, to make room for questions and feedback but it seems important we recognize them as just this. If a task is not actually open to participation (other than commenting), I think we need to provide mechanisms for filter here  as well.

Open or Contributor/Volunteer Task:  Is a clear ‘ask’, with action items suitable for completion by an individual.   Components of a good open task are:

 

Appropriate Tag(s)

Helping people filter to Open Issues is a huge win for project and contributor.  We’ve been using a  tag called ‘volunteer task’ for this purpose, although we may change the name based on feedback.  It’s our most viewed tag.

Clear Title

Far too many task titles look like placeholders for work someone means to do themselves: ‘Upgrade theme’, ‘Fix Div Tags’.  Better titles avoid jumping to assumptions: ‘Upgrade X Theme to use version x.x Jquery Library’.

Referenced Meta/Parent Task

Creating and referencing a Meta Task Is a great way to connect open tasks to the impact of the work being done. They also help generate a sense of collaboration and community that makes work feel meaningful.  I’ve heard over and over again, that the most compelling contribution opportunities are those that clearly show how an individual can have impact on a bigger picture.

Prerequisite

What skills, knowledge or personal goals should someone attempting this task possess?  This can be skill-level,  time commitment – but also a mechanisms for outreach to those with personal goals that relate to the opportunity.  It can also act as a filter, helping people recognize personal limitations that might make this task mismatch.

Short Description

Think of this as the Tweetable, or TL;DR version of the longer description.  Challenge yourself to bring the key points into the short description.  Use Bullet points to break down points vrs writing long paragraphs of text.  Link to longer documentation (and make sure your permissions allow anonymous view)

Participation Steps

I’ve written a lot about designing participation in steps, and believe that breaking things down this way benefits contributor and project.  I know this probably feels tedious especially for smaller bugs, but minimally this means linking to a template explaining ‘how to get started’. Example steps might be:

• Read Documentation
• Build your local environment
• Update the README with any issues you found during the build
• Introduce yourself on Discourse
• Self-Assign yourself this task and leave a comment.

Value to Contributor

I sometimes include this, and my opinion is this is where ‘mentored bugs’ could plug in vrs a bug being only about mentoring.

Although some of this might feel like a lot of work, it actually filters out a large number of questions, helps contributors connect more quickly to opportunity and helps build trust in the process.

Here’s one I used last heartbeat
I also consider Participation Personas when I design in case they help you as well.

---

Image Credit: Welcome by Stav

 

http://tiptoes.ca/how-to-write-a-good-open-task/