>>>>> "Anthony" == Anthony Towns <aj@erisian.com.au> writes:
Anthony> Number one is something like "where should the innovation come from?"
GN> You may notice that unlike in previous years, I do not have a Grand
GN> Vision, not in the same sense at least.
MD> Of course, those are not trivial questions and I don't claim I have
MD> answers. Solutions and ideas will come from contributors. Solutions
MD> will come from you! Do not be shy and do make proposals.
Anthony> I think it's fair to say algernon and mehdi both emphasise the role of
Anthony> supporting other people's innovative ideas rather than promoting their
Anthony> own. (Maulkin splits the difference a bit, I think, given he's got a
Anthony> specific proposal for PPAs and buildds in his platform)
Anthony> That's a very workable plan, but it has one (IMO) huge drawback: the
Anthony> DPL position is /the/ optimal place to be in Debian if you want to be
Anthony> innovative.
I respectfully disagree. The DPL position is the perfect place to be
visible, and to attract attention. It is a terrible position to innovate
from.
There is this great picture I saw just the other day:
https://pbs.twimg.com/media/BwCLXMrIQAAxHEA.jpg
A similar idea applies to the DPL's role in innovation.
Anthony> You have resources, your ideas have been scrutinised and
Anthony> (to some extent) approved by the developers, and (almost)
Anthony> whenever you want it you've got the immediate attention of
Anthony> developers, users, the press, or sponsors at your beck and
Anthony> call. Is it fair to expect cool new innovations within
Anthony> Debian if all the attention goes to someone who's not doing
Anthony> cool new stuff?
Yes, it is fair to expect that. Except, that attention can be directed
further, where it needs to be directed. It's easy to look at the DPL,
and see all the attention the position gets. But, one of the tasks the
DPL has to do, is to lead that attention to ideas and people who deserve
it. The DPL doesn't just lead a project, but also leads - at least in
some way - the incoming attention and resources to their rightful place.
Anthony> So, specific question: do you also see this as problem worth attending
Anthony> to? Do you have any solutions in mind?
I believe that the perception that the DPL position is - or should be -
the source of ideas and innovation is a problem worht attending to.
Anthony> Number two is something in that nature of "how to share the DPL's
Anthony> workload". I think this is widely acknowledged as a challenge, eg:
NM> the job of the DPL is a tough one that requires a lot of work, and
NM> I don't want to bite off more than I can chew
MD> The DPL role is very time-consuming. To be able to do it seriously,
MD> I will put on hold my other Debian activities for the duration of
MD> the mandate.
Anthony> I have three thoughts on that. First is that (I believe) one of the
Anthony> biggest workloads for the DPL is conflict resolution/mediation. But
Anthony> there's recently been some talk about the tech ctte addressing that same
Anthony> issue eg [1], [2]. It's obviously an open question whether it will work
Anthony> or not, but I'd be interested to know if the DPL candidates are thinking
Anthony> of trying to help make it work, and (if/when it does) to refer folks to
Anthony> the ctte freeing up DPL-time for other things?
I'd rather keep that workload closer to the DPL position, and delegate
other tasks instead, at least in the short run. As mentioned in [1],
giving this task to the CTTE would be considerable effort, and would
also require buy-in from current and future members of the committee. On
the other hand, I agree with the idea of approaching the TC sooner. Just
not with the idea of the TC being the *primary* body of conflict
resolution/mediation. That requires a very different skill set, than
deciding on technical issues alone.
Anthony> The second idea on this I have is perhaps a little twisty. First a
Anthony> reference from a while ago: [3]. There have been lots of ideas on how to
Anthony> scale the DPL role -- teams, 2ICs, boards, helpers, etc. Problem is, none
Anthony> of them have worked perfectly, and everyone who's elected DPL is a leader,
Anthony> not a follower, so they come up with their own plan from scratch. Then
Anthony> that idea doesn't work perfectly either, rinse, repeat. At some point,
Anthony> we need a DPL who'll take one of the previous ideas that worked a little,
Anthony> improve it only slightly (ie, so it's still recognisable), and turn it
Anthony> into a tradition that can keep improving. Any chance of that happening
Anthony> this year?
I do not think that the plans this year - or the years before, going
back a few - are entirely from scratch. Each year, there are more and
more common themes between the platforms, because we learn from each
other. I agree, that it would be a tremendous feat to have a DPL really
continue the work of the previous one. But for that to happen, we first
need to make the job of the DPL manageable by a single volunteer. To
adjust expectations to reality. Only then can we have a First Follower.
Anthony> Third is just this: there are two people who've just volunteered
Anthony> (more or less) a year of their life to helping enable other folks make
Anthony> Debian awesome who aren't going to be elected DPL. AFAICT you've all
Anthony> got compatible ideas and can work together okay. So, if you're DPL,
Anthony> how are you going to enable the two losing candidates to enable others
Anthony> and otherwise do awesome leadery things?
We have, indeed, very compatible ideas, and that's terrific. I cannot
yet tell what Neil or Mehdi would need to be able and willing to work
together with me. That is something you should ask them. Would I get
elected, I would be delighted to have a chat with both of them, and
discuss how we can combine our efforts.
--
|8]
Attachment:
signature.asc
Description: PGP signature