[Live-demo] Rethinking the OSGeo-Live communication strategy

Cameron Shorter cameron.shorter at gmail.com
Thu Jun 8 14:27:54 PDT 2017


Bas has made a valuable and pointed comment comment about OSGeo-Live's 
communication strategy (and my involvement in particular):

On 7/6/17 8:39 pm, Bas Couwenberg wrote:
> On 2017-06-07 12:33, Cameron Shorter wrote:
>> Of late, Vicky has been a fireball of energy helping OSGeo-Live, from
>> setting up translations, to helping reach out to communities.
>>
>> I propose we should invite her to become one of the OSGeo-Live PSC 
>> members.
>
> Agreed.
>
>> (If we get all +1 votes, I will share this email thread publicly,
>> otherwise I'll keep it private)
>
> Communication in open source projects should be public by default. 
> Your tendency to keep threads private and then halfway during a thread 
> add the list into the loop is highly annoying. I delete such partial 
> threads, because the community was not involved from the start 
> diminishing its value.
>
> Kind Regards,
>
> Bas 
Bas is right. His comments align directly with the Producing Open Source 
Software handbook [1]:
"As slow and cumbersome as public discussion can be, it's almost always 
preferable in the long run. Making important decisions in private is 
like spraying contributor repellent on your project."

The challenge I see with the OSGeo-Live project is that we generate a 
lot of email traffic, most of which is specific to only a few. As such, 
I think that many of the project-points-of-contacts for OSGeo-Live 
projects are not following the general OSGeo-Live email list.
To address this, we send out private emails to each project point of 
contact (which results in private conversations). There are also 
one-on-one conversations between people, usually on IRC, but sometimes 
or private media such as skype or email many of which we could bring 
back into the public.


To address this, I think we should rethink our communication strategy, 
with an aim of:
1. Being transparent
2. Keeping signal-to-noise ratio high for each category of people involved
3. Ensuring key people (like project-points-of-contact) read our emails 
when we need to reach out to them.

So what main groups of emails do we send?
A. General OSGeo-Live business (such as this email), with both technical 
and organisational content. Typically involves the core OSGeo-Live team. 
This is what our main discuss list is being used for.
https://lists.osgeo.org/pipermail/live-demo/

B. Announcements: Notices of key milestones, kick off of releases etc. 
We do have an email list for this, but we haven't been using it:
https://lists.osgeo.org/pipermail/live-demo-announce/

We create and then store announcements within our wiki:
https://wiki.osgeo.org/wiki/Live_GIS_Disc#Press_Releases

These announcements are then published to our OSGeo-Live discuss list, 
and the general OSGeo Discuss List.
They are also published via twitter:
https://twitter.com/osgeolive?lang=en

And I blog about it, which gets picked up by https://planet.osgeo.org/

C. Emails to project Points of Contact. I've been using a crude, home 
grown mail merge type feature which I've put into a private Google 
spreadsheet. Over the last release, Astrid and Vicky have started using 
this too. With this mail merge, we have been sending emails like "Hi Joe 
and Jone, as project points of contact for XYZ project, I'm hoping you 
can tell us what version of XYZ we should include in the next OSGeo-Live 
release. Version 1.1 of XYZ was installed on the last release."
~ 50 of these emails get sent out at each milestone, so we probably 
don't want to CC a main public list (although we could CC a high 
bandwidth public list to ensure transparency).
About half of projects reply to a first email sent out this way. Other 
projects require a number of manual follow ups.

D. Auto emails from our Issue tracker are emailed to our discuss email 
list every time an issue is updated. This could potentially be moved to 
be sent to a high volume email list in order to increase the 
signal-to-noise of the discuss list.

E. Github sends out auto emails for merge/pull requests which I receive 
directly to my email address. This information is already public within 
the github system, so I suggest doesn't need to be additionally added to 
an email list.

F. I sometimes reach out to people one-on-one in the first instance 
related to OSGeo-Live. I do this because in my experience people are 
more likely to respond, and respond openly and frankly to an individual 
than to a group (especially if they don't know who is in the group). I 
think it is appropriate to do this occasionally, but noting Bas' 
comment, it may be happening more often than it should. I'd be 
interested to hear other opinions on this.

G. We don't currently have a separate list for PSC members. To date, I 
don't think we've needed it. We could potentially set up a private list 
to discuss sensitive points. For instance, should we discuss whether to 
invite someone join the PSC privately first (allowing people on the PSC 
to object and not hurt the person's feelings)?

So what should we change?
1. I think that we start using our OSGeo-Live announce email list again, 
and expect all project points of contact to subscribe to this list, and 
ask all points of contact to ensure they don't hide this list in an 
obscure email folder they don't look at.

2. I think that we should stop sending auto-emails to our discuss email 
list in order to increase the signal to noise ration.

3. I think we should create a "high volume" list, and any emails sent 
directly to project points of contact should be CCed to this high volume 
list. This will address the current transparency issue raised. I'm open 
to also having auto emails being sent to this list as well.

Thoughts?

[1] http://producingoss.com/en/setting-tone.html#avoid-private-discussions

-- 
Cameron Shorter
M +61 419 142 254

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/live-demo/attachments/20170609/c79e46b1/attachment-0001.html>


More information about the Live-demo mailing list