On Tue, Nov 08, 2016 at 02:30:22PM -0700, Darin McBride wrote: > (In fact, if I remember, I'd propose the same rule of thumb for voting here > in > general - rather than making it a hard-and-fast 72hr wait, I'd suggest in > general, using an async communication method such as email, that the rule > should be more along the lines of "whenever the conversation has died down, > run its course, or stand at an impasse, or 72 hours, whichever is longer, the > proposer, or any VM, may call for a vote, itself seconded by any other person > among the proposer and VMs." This is a bit looser than your proposal, but > also less formal, and I don't know about you guys, but most programmers I > know > aren't that formal.)
I intentionally started off with a relatively formal version, with the expectation that once we got a rhythm going we'd look at what could safely be relaxed later on. Also, I'm faintly concerned that "run its course" can make a vote take indefinitely long, and what I'd -rather- do is establish a norm that we let the discussion in the PROPOSAL thread run its course before starting the VOTE thread, then the voting part is fixed (and people can -1 for "you didn't let the conversation finish"). Also that way you don't run into issues where people have different interpretations of "run its course" and we end up in a meta-argument about that. -- Matt S Trout - Shadowcat Systems - Perl consulting with a commit bit and a clue http://shadowcat.co.uk/blog/matt-s-trout/ http://twitter.com/shadowcat_mst/ Email me now on mst (at) shadowcat.co.uk and let's chat about how our CPAN commercial support, training and consultancy packages could help your team. _______________________________________________ List: http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/dbix-class IRC: irc.perl.org#dbix-class SVN: http://dev.catalyst.perl.org/repos/bast/DBIx-Class/ Searchable Archive: http://www.grokbase.com/group/dbix-class@lists.scsys.co.uk