Re: [all candidates] vote time?
On 15/03/13 at 10:24 +0000, MJ Ray wrote:
> Lucas asked
> > Dear questioners,
> > How much time do you think DPL candidates should spend answering those
> > questions? :)
> Probably about half of the time it currently takes ;-)
> > More seriously, [...] Maybe we should try to have some of those
> > discussions on a more regular basis, outside DPL elections?
> I think that would be healthy and probably make the DPL elections
> easier for people.
> Personally, I posted
> http://www.news.software.coop/in-praise-of-consensus/1445/ where
> (among other points) I suggest that the debian project misses a good
> test for consensus (GRs seem an expensive and heavy one and there's
> significant pressure against using them) or a common understanding of
> how strong a consensus we want (like: is it more or less than the
> established majority sizes?).
> That makes many discussions a lot longer than they really need to be,
> where it seems either there are a few people basically in agreement
> bikeshedding, or there's an irreconcilable minority who ought to stand
> aside and let the remainder develop a compromise.
> So as the discussions are long, there's a reluctance to start them,
> which has a number of side-effects, including these Big Questions to
> DPL Candidates which maybe aren't really much about the DPL vote.
> I'd welcome a DPL who led work on this aspect of the project
> management. I suspect that until there are a couple of minor tweaks
> to the project, it's difficult to reach sufficient consensus if the
> DPL's against it.
Yeah, I'm interested in that too.
For example, we could use polls during long discussions to understand
how [silent] people feel. I even did that during the Debian rolling
discussion (see http://www.lucas-nussbaum.net/blog/?p=659) -- the target
there was however wider than just Debian contributors.
However, this must be done with great care:
- rough consensus is very important to avoid splitting the community.
Deciding something because half of the voters+1 agree would be very
- the focus on achieving consensus usually makes us design better solutions.