[this post is available online at https://s.apache.org/dkffj ]

by Marvin Humphrey

I "arrived" at the Apache Software Foundation in 2005, unreasonably angry about 
a bug in Apache Lucene.  By "arrived", I mean that I sent the first few emails 
among several thousand I would go on to send over the next 15 years — the ASF 
didn't have a physical office where I could show up to buttonhole and berate 
some unlucky customer service representative.  An unreasonably patient Lucene 
contributor named Doug Cutting talked me down.

Because the ASF has always been a virtual organization, the Coronavirus 
pandemic has had minimal impact on its day-to-day operations.  While individual 
contributors may be personally affected, at the collective level there's been 
no mad scramble to adapt.

Others have not been so fortunate.  All around the world organizations have 
been struggling to revamp their processes and infrastructure to comply with 
"social distancing" protocols.  Sadly, many have already laid off workers, or 
even closed their doors for good.

And yet, there is a huge pool of work which could conceivably be performed 
remotely but isn't yet — or which is suddenly being performed remotely but 
inefficiently.  If we can accelerate and streamline the transition to remote 
work, many jobs and businesses could be saved.  With some creativity, our 
interim "new normal" could be more propsperous, and perhaps sooner than we 

Are you an Open Source contributor?  If so, you possess expertise in remote 
operations which is desperately needed in today's challenging economic 
environment.  Let's talk about what we know and how we can help.

The Internet Turns People Into Jerks

People type things at each other over the internet that they would never say to 
someone's face.  In person, we calibrate our language based on feedback we 
receive via facial expressions, tone of voice, and body language.  But when all 
communication is written, the feedback loop is broken — and all too easily, 
vicious words fall out of our fingertips.

Suddenly-remote workers may find themselves exposed to this phenomenon as 
conversations that once took place in the office migrate to Slack, email, and 
other text-centric communication channels.  But it can be tricky learning to 
recognize when a conversation being conducted via a text channel has gotten 
overheated — it takes an intuitive leap of empathy, possibly aided by dramatic 
reading of intemperate material a la Celebrities Read Mean Tweets 
https://www.youtube.com/playlist?list=PLs4hTtftqnlAkiQNdWn6bbKUr-P1wuSm0 on 
Jimmy Kimmel.

Open Source communities have grappled with incivility for as long as the 
movement has existed.  Over time, "ad hominem" personal attacks have gradually 
become taboo because of their insidious corrosive effect; there exists broad 
cultural consensus that you should attack the idea rather than person behind it.

Defenses have become increasingly formalized and sophisticated as more and more 
communities have adopted a "code of conduct".  While the primary purpose of 
such documents is guard gainst harassment and other serious misconduct, they 
often contain aspirational recommendations about how community members should 
treat each other — because serious misconduct is more likely to occur in an 
environment of constant low-grade incivility.

Regardless of whether your organization adopts a code of conduct, it won't hurt 
to raise awareness among remote team members of the suceptibility of text-based 
communications to incivility — so that they may identify and confront it in 
themselves and others and shunt everyone towards more constructive patterns of 

Keeping Everyone "In The Loop"

Coordination is a troublesome problem even when everyone works in the same 
office, but the difficulties are magnified in remote environments where it 
takes more effort to initiate and conduct conversations.  Teams can become 
fragmented and individuals can become isolated unless a culture is established 
of keeping everyone "in the loop".

At the ASF, the problem is especially acute because its virtual communities are 
spread out across the globe.  Due to time zone differences, it is typically 
infeasible to get all stakeholders together for a meeting — even a virtual 
meeting held via conference call or videochat.  Additionally, many stakeholders 
in ASF communities do not have the availability to participate in real-time 
conversations regularly because they are not employed to to work on projects 

"Synchronous" communication channels like face-to-face, videochat, phone, text 
chat, and so on are good for rapid-fire iteration and refinement of ideas, but 
they effectively exclude anyone who isn't following along in real-time.  Even 
if conversations are captured, such as with AV-recorded live meetings or logged 
text chats, it is inefficient and often confusing to review how things went 
down after the fact.

The solution that the ASF has adopted is to require that all meaningful project 
decisions be made in a single, asynchronous communication channel.

The channel must be canonical so that all participants can have confidence that 
if they at least skim everything that goes by in that one channel, they will 
not miss anything crucial.
The channel must be asynchronous to avoid excluding stakeholders with limited 
Synchronous conversations will still happen outside this canonical channel —and 
they should, because again, synchronous conversations are efficient for 
iterating on ideas!  However, the expectation is that a summary of any such 
offline conversation must be written up and posted to the canonical channel, 
allowing all stakeholders the opportunity to have their say.

At the ASF, the canonical channel must be an email list, but for other 
organizations different tools might be more appropriate: a non-technical task 
manager such as Asana, a wiki, even a spreadsheet (for a really small team). 
The precise technology doesn't matter: the point is that there are significant 
benefits which obtain if a channel exists which is 1) canonical, and 2) 

Decision Making

In an office, decision makers can absorb a certain amount of information by 
osmosis — via overheard conversations, working lunches, impromptu 
collaborations, and so on.  That source of information goes disconcertingly dry 
on suddenly-remote teams, leaving only information siphoned through more 
deliberate action.

A canonical, asynchronous communication channel can compensate to some extent, 
providing transparency about what is being worked on and how well people are 
working together, and facilitating oversight even while most of the work gets 
done solo.  Because properly used asynchronous channels capture summaries 
rather than chaotic and verbose real-time exchanges, the information they 
provide is more easily consumed by observers watching from a distance.  The 
canonical channel also provides an arena for gauging consensus among 
stakeholders and for documenting signoff.

"Lazy consensus" is a particularly productive kind of signoff, where a proposal 
is posted to the canonical channel and if there are no objections within some 
time frame (72 hours at the ASF), the proposal is considered implicitly 
approved.  Provided that the channel is monitored actively enough that flawed 
proposals get flagged reliably, "lazy consensus" is a powerful tool for 
encouraging initiative — a precious quality in contributors collaborating 


Organizations are adapting in myriad ways to the economic crisis brought on by 
the Coronavirus pandemic.  In the world of Open Source Software where countless 
projects have run over the internet for decades, we've accumulated a lot of 
hard-learned lessons about the possibilities and pitfalls of remote 
collaboration.  Perhaps our experiences can inform some of the suddenly-remote 
teams out there straining to find their way in these difficult times.  Let's 
help them to do their best!

Marvin Humphrey is a Member Emeritus of the ASF and a past VP Incubator, VP 
Legal Affairs, and member of the Board of Directors.  These days, he is 
focusing on family concerns and consulting part-time.

= = =

"Success at Apache" is a monthly blog series that focuses on the processes 
behind why the ASF "just works" 

# # #

NOTE: you are receiving this message because you are subscribed to the 
announce@apache.org distribution list. To unsubscribe, send email from the 
recipient account to announce-unsubscr...@apache.org with the word 
"Unsubscribe" in the subject line.

Reply via email to