[SeasonOfDocs] TheGoodDocsProject: Motion 1: Adopt "Developer Certificate of Origin"

Mon Aug 26 11:12:48 PDT 2019

Hi folks!

Bringing the discussion back up around DCOs/CLAs and licensing in general
-- our lawyer at Google (Max Sills) who answers these questions would be
happy to join one of our meetings and discuss this and other licensing
issues with us.

Is everyone okay with adding him to the call for the meeting on Sept 10?

Also, Max pointed out that there is an issue with CC-0 for templates, which
is that in many jurisdictions around the world it is not possible to "give
up" your copyright in the ways that license states. He suggests we look at
0BSD for the templates instead (https://spdx.org/licenses/0BSD.html)

He also suggested that we could use a CLA but have it be "on commit" in the
same way that we would use DCO.

I hope this helps (although I realize it might muddy the waters more)!

Thanks!

Erin

On Fri, Aug 2, 2019 at 1:37 PM Erin McKean <emckean at google.com> wrote:

> Thanks Cameron! Sorry, I didn't mean to block. I can change to a 0 for now
> and try to get more info about the disapproval of DCOs next week!
>
> Thanks!
>
> Erin
>
> On Fri, Aug 2, 2019 at 12:25 PM Cameron Shorter <cameron.shorter at gmail.com>
> wrote:
>
>> Hi Erin, would you mind expanding your reasoning for the -1. Typically if
>> you vote -1 (considered a blocking vote), then the onus is on you to
>> explain what it would take to change to vote to a non-blocking vote.
>>
>> If Google legal are mildly against, then I suggest change to a -0 ("I
>> prefer not, and this is why ...").
>>
>> I'm hoping Google legal can present us with a case which addresses the
>> concerns we have about introducing a high barrier to entry for
>> non-technical contributors, noting that we don't have a legal entity to
>> make use of.
>>
>> I'd be happy to join a hangouts meeting with them, which I suspect would
>> be helpful.
>>
>> Cheers, Cameron
>> On 3/8/19 5:04 am, Erin McKean wrote:
>>
>> -1 (Google legal prefers not to use DCOs ...)
>>
>> On Thu, Aug 1, 2019 at 1:40 PM Jared Morgan <jaredleonmorgan at gmail.com>
>> wrote:
>>
>>> +1
>>>
>>> On Fri., 2 Aug. 2019, 02:24 Stephanie Blotner, <sblotner59 at gmail.com>
>>> wrote:
>>>
>>>> +1
>>>>
>>>> On Thu, Aug 1, 2019 at 6:11 AM Clarence Cromwell <
>>>> clarencewcromwell at gmail.com> wrote:
>>>>
>>>>> +1 on developer’s certificate
>>>>> +1 on Doctopus
>>>>>
>>>>> Doctopus would be a more memorable name for the project itself.
>>>>>
>>>>> Quills and books are clear identifiers, but we can also have an
>>>>> Octopus with something more modern like a keyboard.
>>>>>
>>>>>
>>>>>
>>>>> Sent from my iPhone
>>>>>
>>>>> On Aug 1, 2019, at 2:39 AM, Felicity Brand <felicitybrand at gmail.com>
>>>>> wrote:
>>>>>
>>>>> +1
>>>>>
>>>>> On Thu, Aug 1, 2019 at 7:03 PM Sanket Totewar <sanket at totewar.com>
>>>>> wrote:
>>>>>
>>>>>> +1
>>>>>>
>>>>>> On Thu, Aug 1, 2019 at 5:59 PM Jo Cook <jo.k.cook at gmail.com> wrote:
>>>>>>
>>>>>>> +1
>>>>>>>
>>>>>>> On Wed, Jul 31, 2019 at 11:23 PM Cameron Shorter <
>>>>>>> cameron.shorter at gmail.com> wrote:
>>>>>>>
>>>>>>>> Following on from our meeting yesterday, and this email thread, and
>>>>>>>> our meeting yesterday, I'm breaking this discussion into two motions to
>>>>>>>> vote on.
>>>>>>>>
>>>>>>>> Motion 1: I propose that TheGoodDocsProject adopt the "Developer
>>>>>>>> Certificate of Origin", current at version 1.0, as our Contributor License
>>>>>>>> Agreement:
>>>>>>>> https://developercertificate.org/
>>>>>>>> (This motion doesn't extend to how we implement).
>>>>>>>>
>>>>>>>> +1 Cameron
>>>>>>>>
>>>>>>>> On Wed, 31 Jul 2019 at 06:11, Erin McKean <emckean at google.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> I did a little digging -- I think we could get a lightweight CLA
>>>>>>>>> with https://github.com/cla-assistant/cla-assistant which allows
>>>>>>>>> for signing CLAs right inside pull requests. I'm happy to volunteer to set
>>>>>>>>> it up if we decide to go this way.
>>>>>>>>>
>>>>>>>>> Cameron has an excellent point about us already having the most
>>>>>>>>> permissive license. :)
>>>>>>>>>
>>>>>>>>> On Tue, Jul 30, 2019 at 1:05 PM Jo Cook <jo.k.cook at gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> I'm in favour of 4, which could be made even better by adding it
>>>>>>>>>> to a pull request template. That way even people who contribute by editing
>>>>>>>>>> a file in the github interface will see it, whether they like it or not!
>>>>>>>>>>
>>>>>>>>>> Jo
>>>>>>>>>>
>>>>>>>>>> On Tue, Jul 30, 2019 at 7:24 PM Sanket Totewar <
>>>>>>>>>> sanket at totewar.com> wrote:
>>>>>>>>>>
>>>>>>>>>>> I like 3. Seamless... But happy with 4 or 5 too.
>>>>>>>>>>>
>>>>>>>>>>> On Tue, 30 Jul 2019 at 22:37, Jared Morgan <
>>>>>>>>>>> jaredleonmorgan at gmail.com> wrote:
>>>>>>>>>>>
>>>>>>>>>>>> I'd be OK with 4 if necessary and definitely 5.
>>>>>>>>>>>>
>>>>>>>>>>>> On Tue., 30 Jul. 2019, 21:28 Cameron Shorter, <
>>>>>>>>>>>> cameron.shorter at gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> From my recent reading:
>>>>>>>>>>>>> There are a few variants of CLAs.
>>>>>>>>>>>>> 1. Developers/Employers assign their code ownership to an
>>>>>>>>>>>>> entity - typically a trusted not-for-profit. The not-for-profit can later
>>>>>>>>>>>>> relicense as required. This appears to be the option that Google legal
>>>>>>>>>>>>> explained to Erin.
>>>>>>>>>>>>> 2. Developers/Employers own their code, but provide a
>>>>>>>>>>>>> statement saying they confirm that the not-for-profit can use under license
>>>>>>>>>>>>> provided.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Both these options require a legal entity (which we haven't
>>>>>>>>>>>>> sourced yet). Both require a system for processing CLA statements (such as
>>>>>>>>>>>>> accepting signed statements). Both are a pain to manage.
>>>>>>>>>>>>> For 1. having the ability to relicense can be both a positive
>>>>>>>>>>>>> and negative, more likely a negative as you will need to get a CLA for any
>>>>>>>>>>>>> library you depend upon.
>>>>>>>>>>>>> Being able to relicense is important if you want to make the
>>>>>>>>>>>>> license more permissive (eg from GPL to MIT license).
>>>>>>>>>>>>> By selecting the CC0 licence (for templates) we are proposing
>>>>>>>>>>>>> to be as permissive as possible, so anyone can relicense to any other
>>>>>>>>>>>>> license. So the value of relicensing is not an issue in that case.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 3. The DCO is lighter as usually implemented is lower
>>>>>>>>>>>>> overhead. All developers need do is add a "--signoff" argument to a git
>>>>>>>>>>>>> commit message. This effectively acknowledges that in the commit you agree
>>>>>>>>>>>>> to the DCO statement.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 4. We could go for a lighter version of this, by making a
>>>>>>>>>>>>> statement in our CONTRIBUTOR.md doc stating. If you submit a commit to our
>>>>>>>>>>>>> repository, then we assume that you are abiding by our DCO (which we
>>>>>>>>>>>>> reference and include on our site). This would be the easiest option, and
>>>>>>>>>>>>> has the same effort for contributors as 5.
>>>>>>>>>>>>>
>>>>>>>>>>>>> 5. Do nothing.
>>>>>>>>>>>>>
>>>>>>>>>>>>> My preference is 3 or 4. (I haven't seen an implementation of
>>>>>>>>>>>>> 4 yet and would like to confirm it is a legitimate option, but there
>>>>>>>>>>>>> appears to be plenty of 5.)
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Tue, 30 Jul 2019 at 09:06, Erin McKean <emckean at google.com>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> More answers: fwiw, turns out that the strongest argument for
>>>>>>>>>>>>>> a CLA (over a DCO or nothing) is relicensing rights:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> "Let's say the project has code samples under Apache, and
>>>>>>>>>>>>>> documentation under CC 4 (common licensing scheme). If they
>>>>>>>>>>>>>> accept a
>>>>>>>>>>>>>> patch to the docs under DCO, that patch is CC4 forever, and
>>>>>>>>>>>>>> they don't
>>>>>>>>>>>>>> have the right to put it in the Apache code section! And
>>>>>>>>>>>>>> vice-versa;
>>>>>>>>>>>>>> they'd have to ask each contribution author every single time.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> With CLA you have relicense rights."
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Also it turns out they will review a CLA (and fairly quickly)
>>>>>>>>>>>>>> from projects not already on the approved list. :)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Erin
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 3:54 PM Erin McKean <
>>>>>>>>>>>>>> emckean at google.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I heard back that given a choice between CLA/DCO, they
>>>>>>>>>>>>>>> strongly suggest an Apache-style CLA.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Am now asking about the choice between CLA and nothing. ;)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Erin
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 3:36 PM Jennifer Rondeau <
>>>>>>>>>>>>>>> jennifer.rondeau at gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> More reasons not to require a CLA. Google undoubtedly not
>>>>>>>>>>>>>>>> the only employer with this kind of limitation.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Note that although I said I'd support a DCO, my strong
>>>>>>>>>>>>>>>> recommendation is against neither CLA nor DCO.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 6:18 PM Erin McKean <
>>>>>>>>>>>>>>>> emckean at google.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> From the "big company" POV, I'm not allowed to sign a CLA
>>>>>>>>>>>>>>>>> that isn't on a (SHORT) approved list of CLAs. So it would likely be a
>>>>>>>>>>>>>>>>> barrier for a new/small project to get on that list.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I am asking about DCOs, will report back!
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Erin
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 2:33 PM Jennifer Rondeau <
>>>>>>>>>>>>>>>>> jennifer.rondeau at gmail.com> wrote:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A CLA involves signing and in the case of the CLAs I've
>>>>>>>>>>>>>>>>>> needed to sign review by the governing board before you're good to go.
>>>>>>>>>>>>>>>>>> Typically automated, but a multi-step process and more complicated if you
>>>>>>>>>>>>>>>>>> need to sign an org-based CLA (as opposed to a CLA for an individual).
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> A DCO is integrated with Git (GitHub and I assume other
>>>>>>>>>>>>>>>>>> Git servers), so you provide a `--signoff` argument to your git commits. Or
>>>>>>>>>>>>>>>>>> add it to your git alias.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Either way it's an extra step of some sort, not implicit.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Mon, Jul 29, 2019 at 5:18 PM Jared Morgan <
>>>>>>>>>>>>>>>>>> jaredleonmorgan at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> With these agreements, does anyone have to actually sign
>>>>>>>>>>>>>>>>>>> and return the agreement? Or do they take the form of "submitting your
>>>>>>>>>>>>>>>>>>> change is like signing the agreement"?
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> I'm just following along with this thread for now
>>>>>>>>>>>>>>>>>>> because (as you can probably tell) I have never heard of this before in
>>>>>>>>>>>>>>>>>>> open source projects.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Mon., 29 Jul. 2019, 07:21 Jennifer Rondeau, <
>>>>>>>>>>>>>>>>>>> jennifer.rondeau at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> It's been my experience working with the Kubernetes
>>>>>>>>>>>>>>>>>>>> community that a CLA can pose a non-insignificant barrier to entry for new
>>>>>>>>>>>>>>>>>>>> contributors, especially if they aren't already familiar with FOSS. And
>>>>>>>>>>>>>>>>>>>> it's my observation from working with a range of Write the Docs communities
>>>>>>>>>>>>>>>>>>>> that technical writers tend to be less familiar with FOSS norms and
>>>>>>>>>>>>>>>>>>>> practices than coders -- this includes writers from large companies.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> If we want to maintain a project that's an open and
>>>>>>>>>>>>>>>>>>>> welcoming for all as possible, I'd support a DCO, but I also wonder whether
>>>>>>>>>>>>>>>>>>>> we need or want even that much. My guess is that it would be enough to
>>>>>>>>>>>>>>>>>>>> drive away at least some otherwise valuable contributors. I don't have data
>>>>>>>>>>>>>>>>>>>> about how many potential contributors lack of a DCO would keep away --
>>>>>>>>>>>>>>>>>>>> anyone else?
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Related but not quite on topic: how do we want to
>>>>>>>>>>>>>>>>>>>> solicit and encourage contributions? Are we assuming only contributors who
>>>>>>>>>>>>>>>>>>>> are already familiar with a Git workflow? That would definitely keep some
>>>>>>>>>>>>>>>>>>>> good work away, based on my experience with writing day sessions for the
>>>>>>>>>>>>>>>>>>>> Write the Docs guide at WtD conferences.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Sun, Jul 28, 2019 at 2:25 PM Jo Cook <
>>>>>>>>>>>>>>>>>>>> jo.k.cook at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Personally I'm fine with the light tough DCO but happy
>>>>>>>>>>>>>>>>>>>>> to go with whatever works for people contributing from large companies.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> All the best
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Jo
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On Sun, Jul 28, 2019 at 1:15 PM Cameron Shorter <
>>>>>>>>>>>>>>>>>>>>> cameron.shorter at gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It has been ~ 10 years since I last looked into open
>>>>>>>>>>>>>>>>>>>>>> source contributor
>>>>>>>>>>>>>>>>>>>>>> agreements, so I've been doing some research. I feel
>>>>>>>>>>>>>>>>>>>>>> this is an
>>>>>>>>>>>>>>>>>>>>>> important consideration for a project which is
>>>>>>>>>>>>>>>>>>>>>> hopefully to be as
>>>>>>>>>>>>>>>>>>>>>> central as ours will become.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> It is about having contributors confirm they are
>>>>>>>>>>>>>>>>>>>>>> allowed to give to our
>>>>>>>>>>>>>>>>>>>>>> project and to agree we can distribute contributions
>>>>>>>>>>>>>>>>>>>>>> under our open
>>>>>>>>>>>>>>>>>>>>>> licenses.
>>>>>>>>>>>>>>>>>>>>>> We have a few options: do nothing, old heavy weight
>>>>>>>>>>>>>>>>>>>>>> Contributor License
>>>>>>>>>>>>>>>>>>>>>> Agreement (CLA), or lightweight Developer Certificate
>>>>>>>>>>>>>>>>>>>>>> of Origin (DCO)
>>>>>>>>>>>>>>>>>>>>>> Pros and cons are explained in Producing Open Source
>>>>>>>>>>>>>>>>>>>>>> Software:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> https://producingoss.com/en/contributor-agreements.html#developer-certificate-of-origin
>>>>>>>>>>>>>>>>>>>>>> I propose we adopt the light DCO:
>>>>>>>>>>>>>>>>>>>>>> https://developercertificate.org/
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> I'd like to hear if anyone has any opinions or
>>>>>>>>>>>>>>>>>>>>>> experience in this area
>>>>>>>>>>>>>>>>>>>>>> (especially from those of you in big companies which
>>>>>>>>>>>>>>>>>>>>>> have legal
>>>>>>>>>>>>>>>>>>>>>> departments which may be opinionated.)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> After we've discussed for a few days (weeks if being
>>>>>>>>>>>>>>>>>>>>>> debated), I'll put
>>>>>>>>>>>>>>>>>>>>>> together a motion to vote on.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>>> Cameron Shorter
>>>>>>>>>>>>>>>>>>>>>> Technology Demystifier
>>>>>>>>>>>>>>>>>>>>>> Open Technologies and Geospatial Consultant
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> M +61 (0) 419 142 254
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>> ------------------------
>>>>>>>>>>>>>>>>>>>>> http://about.me/jocook
>>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>> Erin McKean | Developer Relations Program Manager, Open
>>>>>>>>>>>>>>>>> Source Strategy | emckean at google.com | she/her
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Erin McKean | Developer Relations Program Manager, Open
>>>>>>>>>>>>>>> Source Strategy | emckean at google.com | she/her
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Erin McKean | Developer Relations Program Manager, Open
>>>>>>>>>>>>>> Source Strategy | emckean at google.com | she/her
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> --
>>>>>>>>>>>>> Cameron Shorter
>>>>>>>>>>>>> Technology Demystifier
>>>>>>>>>>>>> Open Technologies and Geospatial Consultant
>>>>>>>>>>>>>
>>>>>>>>>>>>> M +61 (0) 419 142 254
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>>
>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>>
>>>>>>>>>>> _______________________________________________
>>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> ------------------------
>>>>>>>>>> http://about.me/jocook
>>>>>>>>>> _______________________________________________
>>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Erin McKean | Developer Relations Program Manager, Open Source
>>>>>>>>> Strategy | emckean at google.com | she/her
>>>>>>>>>
>>>>>>>>> _______________________________________________
>>>>>>>>> SeasonOfDocs mailing list
>>>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Cameron Shorter
>>>>>>>> Technology Demystifier
>>>>>>>> Open Technologies and Geospatial Consultant
>>>>>>>>
>>>>>>>> M +61 (0) 419 142 254
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> ------------------------
>>>>>>> http://about.me/jocook
>>>>>>> _______________________________________________
>>>>>>> SeasonOfDocs mailing list
>>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>>
>>>>>> _______________________________________________
>>>>>> SeasonOfDocs mailing list
>>>>>> SeasonOfDocs at lists.osgeo.org
>>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>>
>>>>> _______________________________________________
>>>>> SeasonOfDocs mailing list
>>>>> SeasonOfDocs at lists.osgeo.org
>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>
>>>>> _______________________________________________
>>>>> SeasonOfDocs mailing list
>>>>> SeasonOfDocs at lists.osgeo.org
>>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>>
>>>>
>>>>
>>>> --
>>>> Stephanie Blotner
>>>>
>>>> _______________________________________________
>>>> SeasonOfDocs mailing list
>>>> SeasonOfDocs at lists.osgeo.org
>>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>>
>>> _______________________________________________
>>> SeasonOfDocs mailing list
>>> SeasonOfDocs at lists.osgeo.org
>>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>>
>>
>>
>> --
>> Erin McKean | Developer Relations Program Manager, Open Source Strategy |
>>  emckean at google.com | she/her
>>
>>
>> _______________________________________________
>> SeasonOfDocs mailing listSeasonOfDocs at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>> --
>> Cameron Shorter
>> Technology Demystifier
>> Open Technologies and Geospatial Consultant
>>
>> M +61 (0) 419 142 254
>>
>> _______________________________________________
>> SeasonOfDocs mailing list
>> SeasonOfDocs at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/seasonofdocs
>>
>
>
> --
> Erin McKean | Developer Relations Program Manager, Open Source Strategy |
> emckean at google.com | she/her
>
>

-- 
Erin McKean | Developer Relations Program Manager, Open Source Strategy |
emckean at google.com | she/her
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/seasonofdocs/attachments/20190826/f8b25cf2/attachment-0001.html>