On Tuesday October 18 2016 5:26:05 PM Matt S Trout wrote:
> On Tue, Oct 18, 2016 at 11:08:59AM -0600, Darin McBride wrote:
> > > Each non-VM LS may post +1 or -1, and the aggregate of those form the
> > > LAV,
> > > which is +1 if the total is positive, -1 if negative, or abstain if 0.
> > >
> > > Voting closes after 72 hours of the last vote by anybody or after the
> > > outcome can no longer be affected by further votes.
> > In the interests of "stability" ... I'd suggest:
> > ----
> > Each non-VM LS may post +1, -1 or abstain (which can cancel out a previous
> > +1 or -1 vote). The last vote posted is that user's final vote. The
> > aggregate of those from the LAV will be -1 unless the total +1s exceed
> > the -1s by at least 10%, in which case it is +1.
> That makes the existing rules harder to make more restrictive.
Sorry, you're right. I was more thinking about this extra hurdle exclusively
for non-dev CPAN releases. Us users mostly don't care about the processes
used to get to the next release, but mostly only about the actual release
itself - does it break our existing code, does it offer the features we need,
does it impact performance (positively or negatively), is it released in the
necessary timeframe, etc. The governance model is _completely_ superfluous
unless it is impacting things in actual releases.
> Are you sure you want this in the bootstrap version? It would seem more
> logical to me to introduce a proposal to make this adjustment six months
> in or so, no?
I kind of propose it in a tongue-in-cheek fashion based on itself. That is,
if no one else agrees, then my own proposal defeats itself ;)
> > All -1s, whether from VM or non-VM, SHOULD include a reason, as in what is
> > preventing them from voting +1, so that patches to that effect could be
> > proposed.
> Right, so, that's common politeness to my mind, but seems trivial to amend
> in afterwards.
Rights without responsibilities always seem a bit suspect to me, so where
you're granting an explicit aggregate right to LS, it seems to me that it
should come with an explicit aggregate responsibility.
> > The first paragraph here introduces a mild bias towards caution. The
> > second introduces a mild bias towards progress (which is not the same as
> > change). Note that the abstain here is slightly based on the "=0" option
> > for voting on perlmonks - before that was introduced, someone could
> > accidentally click on a ++ or -- and have no way to undo that click
> > without reloading the page prior to submitting other votes.
> Mmm. Right, ok, explicit retraction/change of vote stuff is probably worth
I'm sure that if this actually becomes really engaging, someone will put up a
web page somewhere for managing votes instead of on-list... but who knows :)
> > And thus, my vote for your proposal, Matt, is: "-1, because it's missing
> > these modifications." :)
> Basically: Given these modifications are all minor tweaks to things the
> proposal explicitly renders tweakable, I'm inclined to ask - why do you
> believe having me making the changes you desire unilaterally would be more
> in the spirit of this proposal than letting it go forwards and proposing
> your amendments in the normal way afterwards?
I didn't suggest it be done unilaterally. Other LS users can agree or
disagree with my suggestions, and you can use that to inform your changes, if
> I mean, I can totally tweak the document before it's finalised. But I can't
> see what that gains over "present these as amendments afterwards" ?
> (I'm really not trying to be snarky here, much though 'not snarky' doesn't
> exactly come naturally to me ;)
I thought that adding some bias against _non-dev releases_ that this would be
more in line with riba's concerns about the stability DBIC's users care about.
If no one else is concerned, then their +1s outweigh my -1, and, by my own
proposal's rules, my suggestions are mooted :)
Searchable Archive: http://email@example.com