[Infrastructure] Meeting Minutes / Etherpad

Sat Nov 9 22:06:34 MST 2019

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.

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 
> <mailto: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 <mailto: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 <mailto: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 <mailto:jopurvis at cisco.com>)
>         .:|:.:|:. cisco systems  | Cryptographic Services
>         PGP: 0xFD802FEE07D19105  | +1 919.991.9114
>         <tel:(919)%20991-9114> (desk)
>
>         _______________________________________________
>         Infrastructure mailing list
>         Infrastructure at cabforum.org <mailto:Infrastructure at cabforum.org>
>         http://cabforum.org/mailman/listinfo/infrastructure
>
>     _______________________________________________
>     Infrastructure mailing list
>     Infrastructure at cabforum.org <mailto:Infrastructure at cabforum.org>
>     http://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/20191110/a70e2f61/attachment.html>