> On May 24, 2016, at 12:40 PM, Siwek, Jon <[email protected]> wrote: > > I lean toward starting w/ the most streamlined and least complicated approach > and seeing what quality control checks you need to layer on top of it because > we might just expend a lot of effort planning for problems that don’t actual > ever pop up in practice. But as a person that has to do development work on > cban I might be biased toward doing what seems easier for me, so I’m fine not > having a vote.
I guess I’m not seeing more vs. less complicated; I see mandatory vs. optional being the difference. The important design goals here I think are: 1. Not block anything on a human if possible. 2. Be extensible so we can add future checks and change things between optional and mandatory. 3. Require as little information as needed, but no less. And these goals are really in service of the broader goals of having a useful repository with low barrier to entry. It is is these two goals that are in tension a bit. I’d prefer not to have anything in there that we know is broken, and I believe Robin is concerned that any blocks are going to require interaction on our part. I don’t think that is the case, but both of us are speculating with out data. I think compromises can be made as long as we have the flexibility to change approaches as things progress and we get data back. ------ Adam J. Slagell Chief Information Security Officer Director, Cybersecurity Division National Center for Supercomputing Applications University of Illinois at Urbana-Champaign www.slagell.info "Under the Illinois Freedom of Information Act (FOIA), any written communication to or from University employees regarding University business is a public record and may be subject to public disclosure." _______________________________________________ bro-dev mailing list [email protected] http://mailman.icsi.berkeley.edu/mailman/listinfo/bro-dev
