Hello. This is an open community, synergy and online partnership. So my name is William
Brasik Ray. I'm a senior software engineer with the Linaro Developer Service. Linaro
you can see on the top left corner. Although I'm probably most likely to work on the Linux
Carod's kernel counter subsystem maintainer. And during my time I'm contributing to both
submitted patches and been a maintainer for some time. So I've come across a number of,
I'd say pitfalls perhaps that we can get in when we're doing what's open communities.
So I think it's useful to consider the engineering sector before we, because the
orient is towards where we're from. So. Hello. Hello.
This right? Right. So the engineer mindset. So engineers are very objective oriented.
So I want to get things accomplished. It's kind of orientation on a very pragmatic orientation
to your objectives. You try a streamlined process where you can see, expand through.
But there's this idea of brief. It's beautiful. You want to reduce sort of the redundancies of
your actions and try to get things done faster and basically build on mistakes so you don't make
them again. You're building up on previous knowledge. And the key worry for an engineer is
the mistakes of your past. So that creates this idea that a novice is a liability. And I think
that's sort of the wrong mindset to have when you're dealing with maintenance because maintainers
have to mitigate both established engineers in your community as well as the beginners who are
just not joining. You don't want novices to feel pushed away from that. So you heard the big,
too big challenges that online maintenance have. First of all, written speech. Typically when
you're dealing with an online community, you're not. You don't always interact in person. And a lot
of language nuances are lost in written speech. For example, in just simple tone, take the phrase,
that's a great idea. When it's written down, you're not sure is that being sarcastic or is it
being sincere? Are they serious or is it a joke? That can create miscommunication and you end up
with a lot of problems. To that end, you can mitigate that by becoming familiar with people.
And that's since a certain amount of respect is earned when you interact with people. Strangers
are normally very apprehensive to something new. So to be able to communicate with strangers,
you need to build up a certain amount of trust before you can actually get on a personal level.
So how do you build trust? Trust can be built traditionally through a gift. So gifts are
tools towards establishment of trust. What is that for the maintainers in online community? That's
typically going to be in the form of some sort of work. For example, helping bring up novices to
the environment that they're in for the community. Once you've established this trust as a baseline,
then you can actually move forward to producing the product that you're trying to complete.
Criticism becomes more easily acceptable. If you're trying to criticize a stranger than that
apprehension that they normally have is going to build up a wall and not going to be able to address
the core problem with what they're delivering. The criticism is going to be taken on a more
personal level than what you intended. When you go back to the top of where meaning is lost in the
text, your criticisms might be for the work, but the person on the other end is interpreting it
not the way that you want them to. So what I like to do is I'm a very visual kind of person.
So how about we walk through some scenarios? Here's one that probably a lot of people have been
through. You have a friend, right? Perhaps you're eating out together and you notice they have
something in their mouths. Maybe it's a piece of food in their teeth. So you say, hey, I think you
have something there and perhaps you should go check it out in the mirror and fix it up. You have
a certain amount of previous relationship with that person and the trust has already been built.
So the person trusts you and they go and take care of the issue that they seem. But think about it
from the perspective of a stranger. If you go up to a stranger in the same situation, say, hello,
madam, you're very ugly. Why don't you go back home and change your face? It's taken in a very
different way than you would as a person you've known before. And the reason why is because you
have an established trust. So your words are interpreted in different contexts than they would
be as friends. And that's the core issue with an online community, that impersonal nature of
communication results in misunderstandings like that. Engineers going back to start are very
pragmatic. Engineers want to be able to focus on the core issue. But without the established trust
beforehand, then the misinterpretation comes up and we end up creating a noise in a sense in terms
of what we're trying to achieve. And then there's always something worse when we started. So let's
go over something more specific to online communities and that's the reviewing patches. This is in
the context of perhaps programming work. But I think it could apply more generally. So let's
cover the wrong ways. So you might have come across before. I mean, if you were to say no,
just deny something but not give an explanation. They're taking again a pragmatic approach as
yes or no. But without that understanding in mind, the previous trust, then it comes off as too
abrupt. And again, that person, the novice, might just be taken back by it and I want to
contribute. Another one that we come across perhaps is RTFM. If you've never come across that,
that's read the manual. It's not very useful to you. So please don't respond that way. And I
understand why. You want the person submitting to go through the steps of trying to research
previous solutions and understand the system before trying to propose a change. And that's
understandable but that should be communicated because when we tell them to just read the manual,
it's if you ever interacted with certain manuals, they might be very large to put as an
understanding. So it's a ton to read the manual. It's not very helpful to finding the exact solution
of what you want completed. So if you respond in ways like, what even is this one earth or you're
trying to do, again, you need to be more specific. And these kind of words, they end up taking a
very personal way. In fact, sometimes maintenance do in fact take it personally. This goes bad
and you should feel bad. That ends up now moving the topic from a very technical discussion to now
a relationship discussion. And I think the last one is very sad. I'm not going to reply to you
anymore. I think at that point, we've started on a common ground of trying to produce something good.
And now we've ended in a destruction of the relationship. The reason I've used synergy as a
topic of discussion is because synergy is two more agents coming together in interaction that
produces something greater than what they can produce alone. When you burn the bridges that you've
made by replying in these ways, you've produced something worse than what you would have done
independent. So you've actually ended up worse than when you started. By the way, I really love
this picture here because I think it encapsulates the relationship that maintenance should have
with a submitter. On the left, you have someone using the wrong tool to try to achieve something.
And on the right, same situation. I think maintainers should be mentors in a sense. They should
guide an office to the correct procedures to accomplish what they're trying to do. And then
together, we can produce something greater. So here's what I propose for the right way. Let's
try these again. But it's something that I think communicates better in an online discussion.
Hi, William. Thank you for taking your time to send your patch. You address their work and you
thank them for what they're doing. This is great for a draft, but we have some comments and questions
below. So this sets up a premise where you appreciate their work, but you're prepared to
provide criticism. You're establishing trust so that you can then criticize. So let's continue on.
Unfortunately, this hardware doesn't support that function. This function is set from page 42 of
the manual. And there you point them to where they should go to try to solve it in a different way.
You start them off in the right direction and you let them take over. So you're not becoming
consumed with the task yourself as a maintainer. You're guiding them to produce what you need.
Then perhaps you might say, I'm confused about this part. Would you explain it some more? Let's
work together to figure this out. You're making sure that the discussion, the problems that you're
having is not with the relationship between them. It's with technically what they've produced. You
want to know on a technical aspect what's going wrong. You can also provide your experience as
guidance. This is a common error that I made in the past too. Here's how you can fix it and why
it's better. There are good ideas here. A little more work will be able to merge this. You keep
providing this guidance and motivation to continue on and you welcome them into the community in
that sense. I believe this becomes more effective by building up that trust progressively. They're
able to take the criticisms later on when you do have to criticize the code. A maintainer's job
isn't just to merge. As that goes, a maintenance job is to say no. It's very difficult in that sense.
Here are some guiding principles. As I mentioned before, maintainers should be mentors. No one
starts out an expert, so you can't expect that from every new patch submitter. Remember how you
felt when you were in office. You didn't know the procedure or everything. It's very overwhelming.
The maintenance should be there to guide them through that process. In fact, maintenance should
serve as ambassadors of the code. The focus should be on the code itself, not the personal issues
that you have with someone. Of course, you come across issues where sometimes submitter might be
very abrupt. What you should do in those sorts of instances is pivot back to technical discussions.
Don't get thrown off into a thread of interpersonal relationships because, again, that doesn't have
anything to do with the code in question. Boat of trust and established respect. If you acknowledge
the efforts of the patch submitter, they're more open to taking into criticism. If you do the
favor for them, they'll continue to do the favor for you. Take for tax situation. You're working
towards a common goal, so treat it as that. You're both families towards that. It's a cooperative
effort to improve the code. Not a fight for acceptance. If the disagreements are focused on
technical issues and not personal issues, then you're able to focus on improving the code. In
other words, you shouldn't have discussions about UUU, all these problems. This, this, and this are
the issues. Together, you work towards something external to produce something better. Thank you
for that. These are hard issues to take on. I think in general, people want to produce good
things. That's why they're submitting the patch in the first place. People aren't going there to
pick fights. Of course, there are people that are like that, but the vast majority are trying to
produce something. I think if we orient ourselves towards that, then we can produce an environment
that produces better things. We can increase the synergy in this sense. If you have any comments
or questions, please send me a message. I'm very open to that. I truly believe this is something
important. We should be discussing and trying to find solutions to those problems. That's my GPG
key. If you're wrestling, that needs to be signed. I'll leave it with this. I think that we can
work together to produce something better. I think that that should be our focus. Not in
terms of fights, but just focus on the code. Thank you.