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

Fri Aug 2 13:37:24 PDT 2019

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/seasonofdocs/attachments/20190802/9f9c0c3c/attachment-0001.html>