Published: Mon 27 February 2017
In Tech .
tags: contributing events fosdem open-source
A few weeks ago I happily went off to FOSDEM .
Saturday I caught up with people, Sunday I spent most of the day in the
incredibly busy Community
devroom - right
until I had to give up my seat for food. I really enjoyed the talks and
hope the track manages to get a bigger devroom next year, dozens of
people had to be kept out after every session ended (fire safety
regulations).
Most talks lasted about 30mn and the videos should be available on the
FOSDEM website. Here are some of the highlights from my perspective and
notes.
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.
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:
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.
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!
