[Bro-Dev] CBAN design proposal

Robin Sommer robin at icir.org
Mon May 23 14:59:43 PDT 2016

On Mon, May 23, 2016 at 17:26 +0000, you wrote:

> To clarify, is the concern w/ the amount of non-automatable tasks or
> with the model of requiring authors to “ping” some middle-man in order
> for updates to their plugin to become visible to all CBAN users?

Both actually. Putting us into the path introduces delay and requires
somebody making time available. This is already not working well for
the current plugin repository, where things stall because we would
like to provide feedback and help guide the author along, but then
don't have the cycles for actually doing that. The delay/effort will
be shorter/less the more tasks can be automated, but at the beginning
we won't have much automation in place I imagine and even long-term
certain stuff could never be automated. So I'm wondering if we really
need to be in the path at all, seems that can only cause friction that
would be better to avoid in particular as we kick things off.

> Because most what I had outlined could be automated

Yep, understood, my mail was not directly targetting your proposal;
that just triggered me thinking about this again. My comments were
meant more broadly, we've been discussing different notions of vetting
over time with various subsets of people.

> That would make life easier for authors, and that’s maybe even a
> higher priority than maximizing the quality/consistency of user
> experience because, without authors, there won’t be much for users to
> experience in the first place.

Yeah, that's exactly what I'm advocating: making it easy should really
be priority number one, with everything else coming second. If you see
ways to adapt the design to target that specifically, I'm all for it.


Robin Sommer * ICSI/LBNL * robin at icir.org * www.icir.org/robin

More information about the bro-dev mailing list