Mike Hoye, Introduction
Our process reflect and reinforce our values - this is true as much in their failings as in their successes:
- if something is hard, we don't value making it easy.
- if something is slow, we don't value making it fast.
- positive feedback, thanking contributors
- most important point of all discussion. gratitude keeps people engaged.
Mean people suck.
- cost of toxic people is high (either volunteer or employee) Framework
- comparison to wheelchair ramps
- return on investment - built for people with many difficulties, benefits people with a few
- life easing -- carrying groceries, strollers, luggage
"Many eyes make bugs shallow" - after Nth (about 3rd) person inspecting code, return value disappears. bystander effect - enough people think code has been inspected, don't bother themselves.We want people to care about their part of the code.
- Code that is not owned by a small number of people rots on the vine.
"Open source is meritocratic" Accessibility
barriers to participation - how hard is it to get to the point of effectively making a change to part of the code? what documentation is there, and is it out of date?
make sure to avoid "secret knowledge" - out of date docs.
one step from 0 - ready to help
human error compounds with each step in preparation
justify each additional step
- Q about data re: mach bootstrap usage - how many?
- feedback from mhoye and the room (jdm?) suggest that |mach bootstrap| has a lot of users
- don't do this. functionally identical to "we will accept your work. don't ask us anything"
Igor Steinmacher research - "barriers to participation in open source projects"
- not being matched with something to work on
- receiving timely/accurate responses to queries
- solutions: good first bugs (narrow in scope, address localized change, biggest challenge is getting set up to make change and understanding process). advertise (twitter!).
People want to work with us, admire us. People follow us; talk to them, talk about ways they can work with us.
Bugzilla is a social network, and we should leverage that. Biggest reasons for first patches failing:
suboptimal solutions 24.6%
incomplete fix 22.3%
including unnecessary changes 11.9%
test failures 5.3%
avoid 2/3 of patch rejections with this one weird trick
- link to previous similar guidelines/patches, link to source, describe changes necessary, tests to run (and how to run them)
- is it good to entirely avoid the first review cycle? details forthcoming.
- ~8000 patches never reviewed in bugzilla
- different flags mean different things (r- vs. feedback+)
- 11% of first patches have formatting issues
- The MozReview team is working on this. Talk to smacleod, mconley, gps, mcote. Come join us! (#mozreview) Retention
why participate in our projects vs. another one?
toxic members have a huge impact: actively mocking, condescending
- corollary: response to mocking sends message to what is acceptable
need a code of conduct for events (that's another discussion)
we're pretty good at this, but we can be a lot better at this
- Q: if toxic interaction occurs on bugzilla, is it better to address in public or offline?
- A: need to deal with bad actors in public. if we deal privately, need to make sure it's visible that we dealt with it privately.
- "This is what I think about what you did." Don't just come in and poop on it. You can then go back in the bug and say "This other person didn't do X; here's the X that was expected."
- do a quick feedback loop without shaming that person
Some communities have active, contributing member with toxic behaviours who refuses to address behaviour. Often large belief in meritocracy, can fragment the community.
- If you fragment, make sure all toxic people on one side. Alternative to excising bad actor is community falls apart.
- How to excise without alienating people who don't see bad behaviour, just good contributor being treated badly?
- Paper trail. Show attempts to deal with behaviour in past.
The person with the most authority in a room. How that person acts sends a very clear message to the rest of the community of what's accepted. If that's you, you need to step up. Gratitude
David Eaves talked about state of the community. Get back to people within 24 hours of making contribution (even just "we got the contribution. thank you", or "while we look at X, want to do Y?")
very likely to come back for future contributions.
If you let it rot even as long as a week, then they go. Unlikely to come back.
Q: what do I do when someone's posted a bug in the original bug filing a patch; I come along and ask if they want credit, no response. Do I credit them, if I need to finish it up?
A: that's a policy decision. Mention of original contributor, but as long as the code is in bugzilla, it can be landed. Victory Conditions
instead of "can you look at this bug", "can you help someone look at this bug?"
recently had volunteer contribute their 100th bug
next level is not just doing work with us, but representing us
spending too much time getting new people, instead of specific people who could takeover ownership of ...
need to focus on the growth process of individuals
dropoff rate of 2-3 patches is severe. need to identify prominent contributors and give them a chance to do more.
this is what sustainability looks like; reinforce the culture Q: does it make sense to invest in staff resources for support for non-US working hours and answering questions/supporting contributors? most non-employee contributors are active after 5pm and weekends.
A: mozillians has timezone information. we want to find contributors with solid engineering information to spell each other off. asking employees to work weekends is a tough sell. a solution to the problem we need to address, but maybe not the right one.
Q: many contributors prefer to contact via private channels. any suggestions for helping shift to public venues?
A: demonstrate acceptable behaviour, including that it's okay to ask in public. Explain why it's better to ask in the public channel (other people can answer, other people can hear the answer)
Community Building Tips
- X-Bugzilla-Mentors - set yourself as a mentor on a bug, mark them so it's the first thing you check.
- Can have multiple mentors
- engaging someone with an unknown skillset
- be gentle, probe sensitively; be careful about being too technical, welcome them into the community
- assume they're starting from zero, but be ready to ramp up if they show they've got a greater understanding
- can treat like a job interview
- assume positive intent. They're nervous and want to be cool.
- Be available. Yes, point to documentation, but also leave yourself available for questions.
- Ask questions - be curious about how they're doing and if they're having fun.
- Fun is very important.
- Hand-hold, but then start to release..
- after their first patch, point them to a new one
- get them connected with other mentors as well, so they have multiple connections
- if possible, get them into IRC and talking to the team, not just PM'ing you
- IRC channel is really scary for a first-timer
- Recognition - badges are effective, but emphasize praising the work they've done rather than the contributor directly ("This patch for X was great, and it was done by Y")
- Off in the weeds?
- contributor usually knows it
- possibly not as interesting as originally though
- try offering alternatives?
- break problems down into smaller pieces
- poorly spec'd solutions are heartbreaking. be truly confident when suggesting solution, or warn early if not 100% confident.
- Underlying - they belong here.
- have list of "things to get done", and then have "should be mentoring people"
- community is everybody's job, so it's nobody's job.
- restructure the way we work on projects, community pieces become part of project, especially important for QA
- in list of things to do that day, incorporate community activities
- folding contributors into projects is more valuable. longer-running, has continuity, reduces falloff effect since further work is related. When organization thinks something is important, it has a budget, a calendar, and someone is accountable for that thing. If Involving Community does not have those things, it is not valued or a priority.
- What makes a mentored bug effective?
- give information up front. Is there enough information to get started? Ideally, should not have to ask any questions in order to get started.
- Corollary: in providing information to get started, forces mentor to think about proposed solution. will it work? this provides value for all parties involved.
- address mentor bugs first - helps retention, helps contributor goodwill
- invite questions from assignees. Asking even if it was clear. Invite non-comprehension, show that it's ok.
- ask questions/make suggestions. Suggest other things to work on something else, but that seem like more work to the mentor. Thank them, and invite them to contact you or team via IRC, etc. Offer to provide suggestions for future work if they want them.
- Q: It feels like for easy bugs, it would have been faster to solve the patch myself.
- A: It doesn't matter. It's a vehicle for getting more contributors. How much value does fixing it yourself actually provide, vs. `providing a clear path for someone new?
- Q: Assumption it takes more time to help contributor. After one patch, they disappear.
- A: There are strategies like suggesting upfront on other things to work on. Showing a path to keep going.
- Comment: There are costs and benefits. This should be engineering treating engagement as part of their work.
- project ascend - stipend for volunteers who learn about open source contributions, and getting treated like employees
- safari books access, got HR coaching, got treated like coddled employees for 6 weeks
- created class agreements of behaviour and interaction
- 20-56 year old, low-to-no employment, needing access to technology
- contacted youth and outreach services to attract participants
- OSBridge keynote got word out
- examples of interaction rules: do not take over someone's keyboard
- 3 weeks of ramp up on workflow, safe learning environment for interaction with things like git, travis, blogging, etc. Researched Mozilla projects, ways of contributing, what you could do in one day, one week, etc. Made small changes to projects to see effects. Getting used to regular communication.
- 3 weeks of working on fixing bugs
- template of making comment for claiming bug - here's my understanding, here's what I've found, am I on the right track?
- If you don't fix a bug in 2 weeks, or at least keep participating with it, then you're giving other people the okay to work on it.
- Wide range of prior skills brought to Ascend
- for people having harder time, github was better environment than bugzilla
- webmaker was a great project, because had a lot of small/easy bugs
- Role was to step back, organize check-ins, check-outs and beginning/end of day respectively
- share exciting stuff, headspace/mood
- each person had an etherpad: what are you working on, what are you stuck on, what will you work on next?, other priorities if bugs are no longer in their control
- pulling back and left them to do the work, started and continuing using IRC
- they became their own community that supported each other
- what worked:
- in-person was very important
- created safer space attempting to deal with inappropriate behaviour/actions/speech with path of escalation
- leader pulling away and seeing structure stand on its own
- things to improve:
- identified mentors/community contacts on every team; can curate bugzilla, but shouldn't be necessary and isn't always possible with unfamiliar teams.
- auto-populated form on bugzilla for good first bug: why is this good? what do you expect?
- "new to bugzilla" isn't a perfect signal - get treated differently without it, easy for it to disappear. outreach on how to treat new contributors.
- grow more paid contributor internships ($6332 for three months, or $5500 without admin overhead)
- dispel myth of open source contribution out of goodness of heart
- Creating a culture of everyone on team being a mentor
- Creating welcoming space; have had feedback from contributors that team is fun and nice and helpful
- Mentoring bugs isn't zero effort for engineers doing it.
- How do I balance spending hours on a thing that's not a priority for the team?
- Over time you get better at being a mentor. Mentors mentoring mentors is important.
- Communication channels for asking "how do I help this person?" and getting feedback are important.
- Develop effective practices that everybody uses ("Hi! Welcome to X! Here are the things you need!") and it lowers the mental barrier the more often it's used.
- Like mentoring a new intern/junior engineer.
- Mentoring is not zero-benefit to the mentor. It's development of a skill.
- Comment: went on bug filing spree, got burnt out on mentoring because couldn't provide what was needed. Manager said "you don't have to do this alone; you don't have to be the mentor for all these things." Can ask other people directly to help. Not great to hand off something in progress, but things waiting to be done are things you could slow down on.
- Comment: Several teams have one person who is tapped as the community person. If you're not that person, watch them for burnout. Lots of internal resistance - "my team's really busy, don't want to burden them."
- Q: Do teams have an assigned position?
- A: It's self-assigned.
- Comment: It's usually degrees of interest. QA has community champions; small group has stepped forward for things that are important and will support rest of team in efforts.
- Honest, clear communication. Setting expectations in bugs. It's not your job to lay out every single step; can ask people to step up and do things in a nice way with high expectations.
- You should be having fun too.
- food for thought: systemic difficulties with onboarding. difference between technical concerns and social atmosphere. managing contributor flow (newcomers, returning contributors, ownership) is customer relation management. Doesn't sound fun, but next evolution of engagement work will look like relationship management.
- how do we integrate this into teams? rather than letting the few amazing people with lots of energy taking it on.
- comment: people talk about bad experiences. good experiences get talked about less. we should broadcast the good ones more. Lots of things in Mozilla are only noisy when they fail.
- different ways to look at community that may be effective
- not everyone is going to make it a priority, not everyone is a good mentor
- don't try to make everyone be a mentor
- what to do after a bug is solved? identify larger projects. define why project exists and what it is supposed to do. find the good first bugs related to this feature. find the good next bugs related. contributors then know where to find things to work on that are related; continuity is good.
- recognizing people: if contributor fixes a bug, tell them "you just saved me 5 minutes per day with this change". Identify value of work. Knowing that work is beneficial, sense of ownership. Bugs filed against contributor's work yields ownership.
- Not everyone's a mentor, but everyone needs to participate:
- chat on IRC as a team, they can be an observer and learn
- define the work you're doing, in a way that someone can understand the goal and how to contribute
- good first bugs and mentors - small subset of team should be good mentors, and every bug should have multiple mentors
- We talk about community, but no one makes it a goal. Let's make it actionable. Vision and direction is not enough.
- Make it a quarterly goal - 3rd Q in a row for Ateam with community building goals.
- Contributors that are coming believe you are unbelievably awesome. They equate that you being untouchable. They feel they should jump through a bunch of hoops before they can talk to you. They feel like they're wasting your time and you're busy enough.
- putting your face out can be more welcoming
- be conscious that the contributor might be very intimidated
- but some just want to remain anonymous
- Q: what do you do when even really simple instructions don't work?
- A: just be nice about it.
- 3 first-level bugs, 10 good bugs, then should become independent
- break it down and get them do small parts of a bigger thing
- maybe find a way to work together, treat others as equals
- the goal is to build a web we want to see. Showing others what they can do, and what they can control is part of that mission.
- can plan for things to be done upsteam
- put up bugs that you want, not need
- part of showing people how the web works means showing how the internal bits work
- show people how easy it is to fix bugs, the small set of skills needed
- sites coming: whatcanidoformozilla.org, bugsahoy
- is it ready for contributors? give yourself a 2 hr limit; can someone not familiar with the project fix a first-level bug
- Visual Studio Community Edition: http://www.visualstudio.com/en-us/news/vs2013-community-vs.aspx
- Can this be helpful in getting folks building on Windows faster, more easily?
- I couldn't find a direct link to the referenced paper, but http://utfpr.academia.edu/IgorSteinmacher has multiple such papers:
- http://slides.com/elvis314/synergizing#/ <- a few ideas in here
- how to find work for folks to do: https://wiki.mozilla.org/Auto-tools/Projects/Everything#Project_Table