Minutes for the DPL helpers BOF at DebConf13
Hi,
Below are some minutes for the DPL helpers BOF at DebConf (mostly to
provide an overview of what was discussed).
Video: http://penta.debconf.org/dc13_schedule/events/1022.en.html
Subtitles (thanks to Nattie Mayer-Hutchings): http://deb.li/3ghMR
I feel that it was a very interesting discussion. In terms of immediate
actions, I will try to include the DPL TO-DO list in my d-d-a bits,
as well as in the agenda of DPL helpers meetings. I will investigate
whether it's possible to move it to a BTS pseudo-package (but that's
not trivial).
I also think that the discussion about the two sides of the DPL role
(administrator vs leader) was something we should think about for future
elections.
Lucas
================================================================
* Motivations for DPL helpers:
- share the DPL workload -> get more DPL-ish tasks done (more than just the mandatory ones)
- give prospective DPL candidates a way to discover the DPL workload and test themselves
- be more transparent about the work of the DPL
- have more continuity than a single year
(01:40)
* An overview of tasks currently (at the time of the BOF) on the DPL TODO list, and that
could be informally delegated, was provided
* Possible models for (informal) delegation (depend on the task):
- write draft
- do the actual work, completely (e.g. write + submit a patch)
- come up with a summary of options + recommendation
- provide detailed feedback on an idea
* Questions
** What are your reasons for not taking a DPL helpers task yet?
** How can I help you pick one?
** Should we reduce our expectation of what the DPL does?
** Should the DPL try harder to offload work to the relevant teams?
(11:30)
wookey: no *personal need* to do DPL tasks, and otherwise very busy, which is
why I haven't done anything yet. But growing interest, so maybe ... :)
marga: I don't see why some of the tasks mentioned above are listed as DPL tasks
(e.g. packaging-tutorial improvements).
lucas: mainly because they are tasks I'd like to keep an eye on, to make sure
they get done. Clearly they are less important than the teams stuff.
richih: DPL are big and scary, better to seperate into clearly defined
sub-problems.
lucas: [I agree generally, actionable tasks ftw].
But:
- Not always easy to describe tasks (it takes a lot of time to summarize
what needs to be done)
- Some tasks are very short ones
- Hard to find the good granularity for informal delegations
(16:30)
zack: DPL is a kind of dumping ground where DDs push stuff which is not funny
to do / not something we would like to work on. That's fine in some ways, and
part of the constitutional definition of the DPL: "decision garbage collector",
and not only "decision", but "action item garbage collection".
Debian is made by volunteers. The important question here is: "are we really
able to be sustainable as a project and work on this kind of stuff, or not?"
We need some collective awareness that this stuff needs to be done.
Q: "How do we make people realise more often that everyone needs this kind of
stuff to be done?"
(18:36)
wookey: paid administration?
lucas: less diversity in who would be interested in the DPL role
wookey: not suggestion that we should pay the DPL, but pay someone else to do
the grunt work
buxy: DPL helpers is mainly administrative stuff, no so interesting stuff
lucas: DPL elections are broken: we need someone both with a great vision for
the project, and with an ability to do the administrative (boring) stuff. The
administrative stuff is what really needs to be done.
(23:56)
richih: some kind of bugtracker for these tasks?
buxy: the to-do list could be included in bits from the DPL (with next step+
summary of what needs to be done)
buxy/lucas: one issue is that not all issues can be public
franklin: agree that public to-do list would be useful
(29:18)
wookey: leadership != administration, hard to find people who are good at both,
and it takes a lot of time. Could we try having the Debian Administrator
as well as the DPL?
s.rivera: we are electing someone to be a leader, but who will mostly do
administrative stuff. but the leader has no teeth without the admin power.
wookey: authority comes from doing all the boring work
s.rivera: maybe makes sense to split the administrator from the leader
richih: real risk to having an administrator that stays for years
wookey: have the administrator come with the DPL
lucas: we had had DPL assistants in the past, but I'm not sure how they
split powers.
zack: DPL assistants are tied to the DPL term, thus they start from scratch.
problem avoided with DPL helpers. An hypothetical DPL helpers team would need
to have longer terms than DPL terms.
lucas: Q to zack: did you read the DPL archive from when we had DPL assistants?
how did they work?
zack: both reading leader@d.o, and coordinating using the same address.
(34:14)
franklin: you have a whole list of tasks. what's the next step? are you
going to publish that to-do list?
lucas: I tried to do that during the last two DPL helpers meeting. which is
hard: need to rewrite into a version that can be made public. Plan to continue
to publish those to-do lists.
lucas: Q: are IRC meetings a blocker for you? should we try to move them to
a list?
zack: feels strongly about usefulness of IRC meetings. = periodic status update + reassessment.
richih: continue with IRC meetings, but use lists more
buxy: DPL helpers meetings are mostly for status updates and pings. maybe move
part of the management to a BTS entry
(40:39)
buxy: delegate steering the discussion on CoC?
lucas: risk that the delegate would use that position to push his own
preference.
lucas: another option: small group responsible for reaching consensus on a
proposal
richih: smells like working group, but risk of excluding the project of
the discussions
lucas: what often happens in Debian is that everybody agrees that sthing is
improtant, but nobody feels empowered to work on sthing
Reply to: