Closing Loops (Greg Sutcliffe)

Link to talk

This talk was more about raising questions and figuring out best practices based on audience participation rather than offering The One Solution. In this context, a "loop" means an RFC still undecided, a discussion dying out, patches unreviewed. How do you decide when a topic has come to a conclusion?

It's important to remember that everybody has the best interests of the project at heart, this is more about blaming the systems we use.

Say, in a Request For Comments discussing significant changes on a mailing list, the discussion tends to peter out after a while, and it can be difficult to track how a proposal evolved. Foreman (Greg's project) decided to move the discussions to an RFC repository instead, but 6 months later it seems to have only moved the problem.

From the audience:

• For Debian, the discussion ends "when someone starts the work" :)
• LibreOffice has a "technical council" type meeting/discussion with about 40 people, on the phone. A wiki documents the process to join.
• In the PHP world, the RFC author gets to choose when to call a vote and the deadline for it (at least 2 weeks ahead). Greg wondered if that might get divisive if there are too many 50/50 situations, but the audience member indicated that it wasn't the case, because most problems get solved during the discussions that precede the vote so they are usually overwhelmingly accepted. Every contributor gets a vote from a certain contribution threshold.

The speaker seemed interested in trying out the technical council direction for his project.

Data science for community management (Manrique Lopez)

Link to talk

Communities need to have a common vision and self-awareness to see if they are walking toward it: what kind of people are part of the community, what are they doing... This helps with governance and transparency (fairness, trust).

What is the role of a community manager? Do communities even need to be managed? "Manage" is a strong word.

A community manager is interested in keeping their community alive, active, and productive. Having visibility into community health is important. There are a lot of tools out there with data relevant to this: JIRA, git, IRC, slack, StackOverflow, ... A lot of places, which individually are only one part of the bigger picture.

Rather than cobling a bunch of scripts together to get to all that data, GrimoireLab does all the work for you and presents it nicely using graphs. One example was the "Pony Factor," which I hadn't heard of: who's doing 50% of the commits? For example in the kernel, the pony factor is about 200 people/10 companies. That's a lot of people!

When you have that data you can see the evolution of the project over time: reviews, gender, demography, pony factor, etc, etc. Cauldron.io, in beta, lets you try it out for free for up to 5 Github organisations.

Getting your issues fixed (Tomer Brisker)

Link to talk

I think anyone trying to get help or start contributing as a user to an open-source project needs to watch this. Tomer summarised a ton of best practices that experienced open-source people "just know" and would likely never think to document.

A super rough summary:

• Try to ask for help on IRC
• Try the mailing list. If no one replies and you solve it yourself or find a workaround later, please self-reply. (Mandatory xkcd link)
• Search the bug tracker. If there is a bug, add your input, your use case. If there are none, create a new issue and include as much information as possible: traces, logs, version (including of the plugin if relevant), screenshots... Anything to help the developers reproduce the issue. If this is a feature request, explain your use case.

Patches:

• Tabs vs spaces: follow the coding guidelines for the project. If there aren't any follow the standards and conventions of the existing code base.
• Make the commit message good. Explain "why" as completely as possible. Apparently Github even lets you include screenshots, so that the patch can be reviewed without having to pull the code. "Why" did you do it this way and not another way, explained in such a way people in the future can understand the decision.
• Include tests. This protects against regressions, so that you don't have to fix the same bug two releases later.
• Be kind. We're building a community. No one wants to be shouted at. Be patient.

Handle conflict, like a boss! (Deb Nicholson)

Link to talk

Conflicts often come from a piece of information that is missing. Conflict is natural. If you don't handle it, it will come back worse.

How do we minimise it? Try to understand the other people, where they're coming from.

For example:

• Passion. When people get so excited about something they forget why they're doing it. Mismatched goals.
• Identity. When someone's identity is linked to a task, not a goal. For example, the person known to be super helpful with wrangling the complex bug tracker, who'll end up sad when you finally upgrade to something better.

Don't leave conflict unattended or you'll end up in a snake pit. You don't owe your mental health to any FOSS project.

There are 3 styles of handling conflict. We tend to use them all, depending on the circumstances.

• Avoidance. This is not good in a project! It festers. It looks like you don't care, like you're not connected to the community and its concerns.
• Accommodation. Doing stuff you don't really want to in order to keep the group happy. For bigger issues it can make it look like you don't mind the way things are going. It works for small things.
• Assertion. Can also be called Aggression. Name calling, etc. Not a good strategy. It wears out other contributors.

Conversations happen in many places. Document the decisions so that it doesn't feel like they're coming out of nowhere.

If you notice in passing a problem in the community you're probably missing some information. Gather more info in order to understand the source of conflict: misunderstanding goals, stepping on toes (e.g. that person always writes the release notes but someone else went ahead and did it this time instead, without asking), ... Is it new members clashing with the old ones? Go back to the historical vision, step out of the tactical discussion. Are there sekrit goals underway? For example a motivation you're not aware of, someone with different goals for their participation like a new job or internal deadlines...

If the conflict is based on fear, it can be harder to get at, e.g. someone afraid they can't learn a new skill if switching language. Create a back channel where it's safe to discuss, to try to deal with it.

Planning for future conflict:

• Assume the best.
• Have a code of conduct. Set expectations.
• No name calling/ad hominem, only discuss technical merits.
• Set an example.

We could do so much more in the FOSS world if we didn't spend so much time slagging each other :)

Some references:

• Everything is workable - Diana Musko Hamilton.
• Contempt Culture - Aurynn Shaw.

Mentoring 101 (Brian Proffitt)

Link to talk

This was a lively talk on both formal mentoring via programs such as theGoogle Summer of Code as well as daily mentoring.

Onboarding is important. This is not just about keeping people in but helping people get in.

As software project, should you want to participate in formal mentoring: have a plan. Formal programs have their own rules and structure.

As a participant, be a member of the community, pick a project that interests you. Be ready to commit. Be flexible - it takes time but is rewarding. Be ready to ask for help.

Undermentoring is a problem. Have clear, set goals for the mentee. Keep an eye on them while also giving them space.

Issue with mentees disappearing... They really should keep a line of communication open, even if only to say, "sorry, I cant' participate anymore." (From personal experience mentoring, this is quite stressful and it was a relief when the mentee admitted they could no longer participate.) You need to proactively mentor to avoid this.

• Be consistent. E.g. your style may be authoritative (do it this way), democratic (collaboration) or coaching (guidance). Stick to one. (...with Brian noting that the last one is best for mentoring!)
• Set expectations. Make sure the goals are aligned, define the process, avoid confusion.
• Take an interest in the mentee. Listen actively. Build a relationship. Learn their style. Don't be a stalker though.
• Wait before giving advice. It's easy to try to fix things when someone comes at you with a problem. You might be able to solve it but that won't help them. Hit the pause button. Ask more question, get to the heart, guide them to the solution. It takes time. You may not solve the problem. As long as it's not time-sensitive that's ok.
• Don't assume anything. Avoid stereotypes. Learn the details of a situation. Emphasise communication.

Remember this one thing: they aren't you!! Understand the mentee. This is not only about getting the project done.

A question from the audience was, how can I help my mentor as a mentee? Once again it's about being proactive: this is what I want to do, how do you help me do this? If it isn't working, reconsider the relationship.

How to recruit mentors? Some projects are easier to get in than others. In oVirt, there's a separate mailing list and no formal process. Spread the word, see who's interested. What about a project where there's a lot of mentees yet no one ever answers the call for mentors? If this is part of a corporate project, a solution could be to make it part of the job.

Impromptu community talk

One of the talks was cancelled, so a couple of people started a conversation around community and community events (too many pizzas, too much alcohol is the feedback I remember from that part).

The need for "cruel empathy" was brought up: sometimes meeting organisers should be jerks for good reasons. Loud, demeaning people are toxic and need to be called out. Tell them, in private: "I appreciate that you're here, etc, but you're sucking air out of the community." They may not realise they are doing it, so be nice about it.

The Shotwell community was brought up as one with great first contact.

Overcoming culture clash (Dave Neary)

Link to talk

This was a very interesting talk, mainly summarising information and graphs from books, which I'm going to list here. And hopefully read soon!

Basically a lot of what we do and how we interpret things depends on our upbringing (country, culture, ...)

• The Tragedy of the Commons - Garret Hardin.
• Moral Tribes - Joshua Greene.
• Culture and Organizations - Geert Hofstede. That one brings up 6 dimensions of culture, for example tending to be uncomfortable with silence and filling it instantly, vs. leaving a couple seconds pause to make sure the person is finished.
• Getting to Yes - Roger Fish. This is more psychology-based than about hard negotiation.

There are no easy solutions. Focus on the relationship. Take small steps: one conversation at a time. Encourage local user groups - though keep them connected e.g. via sending mentors/leaders to these meetups to avoid silos. Have short mentoring programs. Learn about the cultural norms and sensitivity of the community. Avoid real-time meetings.

I contributed! But what now? (Bee Padalkar)

Link to talk

Based on the Fedora community, this talk was about improving contributor retention rates by finding patterns about successful contributors.

Why do people stay? According to a survey they ran, usually thanks to the strong, positive and inclusive community. Other reasons were identifying with the Fedora foundations (core values), giving back, constantly learning.

No matter how interesting the project is, if the community is poor people don't stick around.

• Have a defined onboarding process.
• Encourage people to speak up.
• Assign action items early on, to create a sense of responsibility.
• Let people know they are doing good work, give feedback (e.g. IRC karma).
• Use inclusive and motivating language.
• Encourage attending events to meet people in person.
• Encourage consistency over activity. Let people contribute according to their own time.
• Inspire, interact, give feedback.
• Help people identify with your mission.

~

Looking forward to next year's event!