Contributor Experience: Plan

Contributor Experience Plan

Topics

Theme 1: Build up working groups
Theme 2: How to develop modules
Theme 3: PR(/issue) backlog
Timeline

The Contributor Experience had a wide remit, though is currently focusing on the following:

Theme 1: Build up Working Groups
Theme 2: Make it clearer how to develop modules
Theme 3: Reduce issue/PR backlog

Discussion welcome in #ansible-community or in Contributor Experience Etherpad

Theme 1: Build up working groups

Objective: This is about scale and empowering others to do things themselves

A well functioning group should be able to:

Welcome new members into the group
Provide a variety of items (not just coding) for people to get involved with
Keep on top of their backlog
Set direction

Measure existing working groups

Goal: Find out if we are building up and maintaining active groups.

aka If we don't measure, how do we know if we are improving

Possible Metrics

Interested in participation not just people idling

Unique people active in IRC meetings
Number of people active on agenda issues
How do people find out about the groups
Why do people stay
Why do people leave

Blockers & pain points: Identify & document

Goal: Make life easier

Asking a wider range of people for pain points allows us to spot common issues and address them
Review previous Contributor Summit docs
Important to get input from new contributors

Share any best practices

The various groups have found things that work for them, we should review, document and roll out for other groups what works. If something doesn't work then analyse why not

AWS: Monthly status
- Simple to do
- Shows progress
- Motivates
Network: track actions on agenda
Network First Gamification Exercise - Earn Ansible Swag!

Ensure each group has some way of showing what it's achieved

Goal: Showing progress keeps motivation

Motivates existing and new people
Such as AWS's boto3 porting and testing monthly stats

Ensure each group has a task list

Goal: Ensure that new people that want to get involved have something to help with

MUST include non-Python tasks
MUST include some well defined simple items

Identify and invite others to join

On hold till till above items have been done, we don't want to invite more people till the groups are in a better state

~~Ansibullbot to promote IRC Working groups #820~~ DONE
Standard slide and promotion to include in Meetups

Blog posts series on the cool things the groups are doing

On hold till till above items have been done

Series of blog posts, one per working group, showing what they've achieved and how to get involved.

Theme 2: How to develop modules

Objective:

Docs: dev_guide reorg to make it easier to create and write content (acozine is working on this)
Docs: Real examples on how to document your module
Docs: fix module checklist
Docs: How to write a good integration tests
Continue to spot common issues with new PRs and doc/automatically test them

Theme 3: PR(/issue) backlog

(Will partly be addressed by Theme 1)

Where ever modules live (ansible/(ansible, modules-core, ...) there will always be issues and PRs raised. Understanding how the backlog builds up and empowering people to reduce it is key.

Break PR workflow into a flowchart, stats on where on the workflow PRs are
Attack these areas as individual items

Focus on new_contributors

Thanks to Ansibullbot we know if a PR is from a new_contributor

Analyzing new_contributor's gives us a good insight into how clear our docs, process and tests are. This is important as we often get sidetracked by regular contributors that have been through these issues before and overcome.

New contributors that receive feedback on their first PR sooner are more likely to contribute again Mozilla research
CI Issues
- Are issues found valid
- Are the error messages obvious
- GitHub Checks API should help this - Waiting on Shippable and Zuul
Spot trends, do RCA, fix at source

New Contributor experience

We can count/track many things, though we need to ensure that: * Can we influence what we track, if not is this useful - Without * Some metrics as just "general trends"

Aim

How can measure the new contributor experience in a quantitative manor to allow us to identify bottlenecks in the process

Definitions

new contributors: GitHub users that haven't had any PRs merged into ansible/ansible
experience: The workflow process that the contributor goes though from PR creation to PR being merged

Possible Metrics

"Number of days from PR being open to merged/closed" - Gives us an overall number, though no idea what the bottlenecks are

To identify the bottlenecks we need to define the workflow and track the progression though

PR open to close (not merged) - a PR being closed at triage means the PR is invalid. This may indicate bad PRs (duplicate, already fixed, not an applicable fix/feature)
repeat contributions
Time to fix CI issues

All of the above multiplied by: * Type (feature, bugfix_ * Module, plugin_type (callback, lookup, inventory, etc) * Support: Core, Network, Community * SIG: If the PR has been tagged with a specific working group list of working groups (SIGs)

Foo

Example results