Re: Lars Wirzenius' not-platform?
On 18 March 2016 07:40:47 GMT+08:00, Paul Wise wrote: >To the candidate: > >Have you read Lars Wirzenius' not-platform? > >http://blog.liw.fi/posts/dpl-2016-not-platform/ > >Do you have any thoughts on it? > >Does Debian need the Social Committee proposed by Lars? I feel that more personal contact (e.g. events) and activities like leadership training/seminars would help address the problem he describes. Many DPL candidates, including Mehdi, have indicated support for the former, it would be interesting to see comments on the latter. -- http://danielpocock.com
encouraging events?
Hi Mehdi, I've been reading over your platform, I couldn't help noticing it is in all seriousness better than some of the other candidate's running for high office right now. The only other thing needed to be in that league of course is fostering good relations with Irish voters[1] If Irish developers were to try and organize a MiniDebConf for the weekend of 18-19 March 2017, would you be happy to support that as DPL and provide some funding if necessary to make it happen? Happy St Patrick's Day everybody Regards, Daniel 1.http://www.bbc.com/news/world-us-canada-13166265
Re: quantity of DPL candidates?
On 16/03/16 01:25, Ian Jackson wrote:
> martin f krafft writes ("Re: quantity of DPL candidates?"):
>> What sort of decision-making are we talking about? We require the
>> DPL to sign off on expenses, but this could be solved with
>> a (collaboratively generated) budget. What other decisions are in
>> the DPL realm? I don't mean the constitutionally assigned roles, but
>> those decisions which the DPL wouldn't defer to someone who knows
>> better already? For if there weren't many of those, another
>> consideration would be just to get rid of the DPL position and
>> spread powers wider and closer to where the work is being done.
> Well, I agree that it would be nice if the DPL were to delegate a lot
> more. DPLs have historically avoided delegating ad-hoc one-off
> issues. (Also there is not currently a convenient way for the DPL to
> find someone interested in and suitable for a particular ad-hoc
> delegation.)
>
> I don't think a collaboratively-generated budget answers the
> expenditure question in an effective way. Someone still needs to have
> the authority to approve an expense item from a particular budget.
> (This could be done with delegation.)
>
Looking at the issue of delegation from a fact-based perspective, a lot
of research has been showing
a) people can only make a limited number of decisions per day
b) this number of decisions is the same whether they are all big
decisions or if some are only little decisions
c) quality of decisions and motivation to make decisions depletes during
the day, a famous study looked at this in context of parole decisions[1]
In fact, even deciding whether to answer a phone call is a decision,
that depletes your daily "quota" of decisions referred to at (b).
What does this mean for the DPL and Debian? Delegating is not just good
but essential. E.g. instead of approving individual expense requests,
just allocate a fixed amount of money for some activity or class of
activities and let somebody else divide it up. To put it another way,
if the DPL can only make three Debian decisions per day without
impacting his quota of decisions for job, family, etc, what should they be?
Regards,
Daniel
1. http://www.wired.com/2011/04/judges-mental-fatigue/
Re: quantity of DPL candidates?
On 14/03/16 03:53, Paul Wise wrote: > Hi Mehdi, > > Any thoughts on the low amount of DPL candidates this year? The only > year we have had a sole candidate was when zack ran for second-term > re-election in 2011, which is a quite different situation to this one, > where the previous DPL is not running for re-election. > > How do you think this situation reflects on the health of the Debian project? > It could be a flaw in the nomination process. Perhaps nominations should be made in secret. Then more people would nominate out of concern that somebody unsuitable may be elected by default. The DPL job involves a lot of work and anybody who is suitable to be DPL is probably aware of the expectations and workload. Maybe there are some improvements to organization structure, like having a couple of Deputy DPLs, that would make it more fair to the DPL. > Do you think we should vote for NOTA until someone else nominates themselves? > No, people should only vote none-of-the-above if they have good reason to believe there is some fault with the candidate. If somebody is aware of a really good reason not to support Mehdi then not only should they vote NOTA, they should also consider asking Mehdi to withdraw or making the concerns public. I'm not aware of any such concerns myself. Regards, Daniel
Re: GR: Selecting the default init system for Debian
On 19/01/14 03:25, Ben Hutchings wrote: > >> In general, I've been quite unhappy with the excessive invocation of >> the TC recently, with developers seeming to view this as a first, >> rather than absolute last, resort. > [...] > > Constitutionally, a GR is the last resort in that it can overrule every > other decision. A GR can settle a decision finally but does *not* > create consensus. So if you honestly think that more time should be > allowed for a consensus to arise, perhaps you should propose a GR that > says this issue is not ripe for the TC to decide on and sets some > minimum delay before it can be brought to the TC again. It is not about the TC at all (unless they volunteer to do the work to implement any decision they make) Ultimately, whatever decision making process is used (GR, TC, etc) there needs to be some suggestion about who will actually do what and who presumably won't do anything or what will stop working E.g. if we choose systemd, who will implement all the things that need to be changed outside the Gnome related packages? What will immediately fail if not adapted to systemd? If we choose Upstart, it is not quite ready to do everything systemd would do and we have to trust the developers to follow through on their commitments to fill those gaps. I personally believe their intentions are good but promises are never the same as releases. If we decide to give them our trust and for any reason they can't deliver on time, what would we fall back on, is it enough to say we would just keep sysvinit for another 2 years, or would we defer the release and wait for them? Every option - and every fall back option - needs to be explained and accompanied by some details about who will do what if that option is chosen, if it hits a snag, etc. Only then do we have a list of choices for a GR -- To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/52db97ff.8070...@pocock.com.au
