[Infrastructure] Meeting Minutes / Etherpad

Mon Nov 11 08:09:11 MST 2019

On Sun, Nov 10, 2019 at 12:06 AM Dimitris Zacharopoulos (HARICA) <
dzacharo at harica.gr> wrote:

>
> I am not comfortable with "requiring" minute-takers to use Etherpad. A
> minute-taker could choose to use a paper notepad. Most people will prefer
> the collaborating real-time tool as suggested.
>

Could you explain why? We've already seen significant issues with the
minutes *not* done in Etherpad in our most recent F2F?

While it sounds like you're in agreement for the follow-up, I don't think
there's a clear understanding about your discomfort or how to address it,
especially in light of the issues we've seen and continue to see. The
alternative seemingly being presented is just to ignore those issues, and
that seems like a real detriment.

>
> I recommended Etherpad for the reasons already mentioned in this thread.
> It's simple, quite fast, easy to setup, no need to worry about sharing
> problems, works with all browsers/OSs. GDocs, Sharepoint and other online
> collaborating tools offer significantly more features which are probably
> not needed for this specific function.
>
> After the F2F, these minutes from Etherpad will be transferred to the wiki
> where authenticated collaboration and history is tracked using the wiki
> mechanisms. Once in the wiki, the process is similar as we are used to.
>
> The wiki allows editing of different sections by different users so I
> think it's been working fine so far.
>
> If there are no objections, I believe one could take the task to setup
> Etherpad in one of the VMs we currently use and make it available at an
> alias "etherpad.cabforum.org".
>
>
> Dimitris.
>
> On 2019-11-08 11:04 μ.μ., Ryan Sleevi wrote:
>
> Right. I think there's two parts we should separate: collaborating
> real-time and collaborative editing post-facto. Etherpad gives us both, but
> it's not necessarily want we want for that second part.
>
> I think in terms of use cases, we talked about having real time minutes
> compiled by minute takers (and collaborators), during the meeting. I think
> this actively requires *requiring* minute takers use whatever collaborative
> tooling is there, and not simply relying on them to publish minutes after
> the fact. This will, admittedly, limit some of the options for minute
> takers, but addresses the long-standing issue of having trouble getting and
> collaborating on minutes (especially with post-facto discussions/debates
> about their accuracy)
>
> Once that meeting is complete, however, we should move those minutes into
> the collaborative editing post-facto. And we've got a solution for that so
> far, via the Wiki, and we've already seen the F2F minutes shift over there.
> As those are collaborated on, they're eventually finalized (and also record
> fine-grained edit history), and we publish those to the mailing list and
> durable forms.
>
> Using GDocs or Etherpad or Sharepoint or Slack or IRC for the real-time
> are all fine by me. Whether it's "start a thread in slack" to correct
> minutes or "overwrite the text" (in GDocs or Etherpad or Sharepoint)
> makes... not much difference to me. I think, of all of these, Etherpad is
> the easiest to get started with, because it doesn't require figuring out
> the sharing settings in GDocs or Sharepoint or the like, or making sure
> folks have an account, or allowing global edits and hoping everyone
> identifies themselves.
>
> So "Run Etherpad on a CABF server and use it for real-time minutes,
> requiring minute takers to use it. Following the completion of the meeting
> (plus some slop time? like an hour or two?), post minutes to the Wiki for
> collaborative editing" seems... viable?
>
> On Thu, Nov 7, 2019 at 12:04 PM Wayne Thayer <wthayer at mozilla.com> wrote:
>
>> What are the requirements? If this is for collaborating on minutes that
>> will then be published somewhere permanent, do we need to worry about
>> losing the data? And if these are unpublished minutes, do they need to be
>> secured? These answers might favor one solution over the other. Meanwhile,
>> I don't have a strong preference.
>>
>> On Thu, Nov 7, 2019 at 7:29 AM Jos Purvis (jopurvis) <jopurvis at cisco.com>
>> wrote:
>>
>>> The experiment with using Etherpad for minute-taking during the meetings
>>> seemed to go OK this time. While observing the minutes assembly (and Ryan’s
>>> observation that Etherpad-as-a-service will be discontinued in December), I
>>> noted to Wayne that we could easily stand up an Etherpad service on a CABF
>>> host. He wondered whether there were advantages to doing that vs. Google
>>> Docs (which people are likely more familiar with), and the only real
>>> advantage I could come up with was that by doing it on a CABF server, we
>>> could ensure that copies of documents weren’t “owned” in Google by any
>>> single member. That might not be a good trade-off, though, so I thought I’d
>>> toss it here and see what people thought. We came up with a couple
>>> possibilities:
>>>
>>>    1. Run Etherpad on a CABF server and use it for official minutes,
>>>    encouraging (not requiring) members to use it.
>>>    2. Encourage the use of GDocs for collaborative work, but create a
>>>    cabf at gmail.com or similar account that could be added to each
>>>    document. A little scripting, and that CABF shared account could likely
>>>    make a backup copy of any document it’s added to, ensuring that the CABF
>>>    always has copies of materials that will survive individual members.
>>>    3. Jos is again inventing a solution for a non-existent problem, and
>>>    we’re probably good to keep going how we are. :)
>>>
>>>
>>>
>>> Thoughts?
>>>
>>>
>>>
>>> --
>>> Jos Purvis (jopurvis at cisco.com)
>>> .:|:.:|:. cisco systems  | Cryptographic Services
>>> PGP: 0xFD802FEE07D19105  | +1 919.991.9114 <(919)%20991-9114> (desk)
>>>
>>>
>>> _______________________________________________
>>> Infrastructure mailing list
>>> Infrastructure at cabforum.org
>>> http://cabforum.org/mailman/listinfo/infrastructure
>>>
>> _______________________________________________
>> Infrastructure mailing list
>> Infrastructure at cabforum.org
>> http://cabforum.org/mailman/listinfo/infrastructure
>>
>
> _______________________________________________
> Infrastructure mailing listInfrastructure at cabforum.orghttp://cabforum.org/mailman/listinfo/infrastructure
>
>
> _______________________________________________
> Infrastructure mailing list
> Infrastructure at cabforum.org
> http://cabforum.org/mailman/listinfo/infrastructure
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/infrastructure/attachments/20191111/af46cd9e/attachment.html>