Thank you for coming and waking up early for this BoF.
Someone yesterday evening came to me and told me,
"Oh, I have something... I would really like to come to the BoF. Actually, I have only one thing to say to you,
so if I say it now, I can sleep."
He is not here today. I will protect his identity. so if I say it now, I can sleep."
He is not here today. I will protect his identity.
Originally, when Zack started the DPL Helpers initiative,
I think there were three big axes of motivation for that.
The first one was to share the DPL workload,
so that there's less work to do for the DPL,
more tasks that usually fall into the DPL domain get done,
more than just the ones that really must be done in any case.
Also, there was the idea of giving prospective DPL candidates an idea of the DPL workload,
and test themselves on the process.
[to Zack] Does that reflect what you... [affirmative response]
[Zack] Totally. It was also to be more transparent about what the DPL does, and actually show what's going on,
It's possibly a sub-point of the second one, but yes.
[Lucas] Yeah, but then it won't fit anymore, though I try.
(...?!)
I've tried to go through my current to-do list and pick out items that could be done by someone else.
For some of them it's really easy for someone else to do them,
for some of them it's much harder to see "Oh, someone else could do it", but, well, let's see...
I'm just going to go through them quite quickly, just so that you know what's even behind the descriptions.
So, the first one is about, basically, the infamous library required to play encrypted DVD.
We have legal advice how to package it in Debian.
The package is ready; it needs to be reviewed by FTPmaster, then SFLC, so that it can get into Debian.
It's currently blocked in that state for the last three months, so needs some poking.
The second one is that we have this great new NM website, developed mainly by Enrico.
We have the DM workflow, which is completely separate.
It would make sense to try to fit the DM workflow inside the NM website, see how we can do that.
Then, there are several things that are related to delegation.
The release team is not delegated currently.
It would make sense to have it delegated so that its powers are more explicitly stated.
For example, when they decide to remove packages from testing, or to...
That's the kind of thing that can be quite controversial inside a project.
It would be nice to have a way to say "Yes, they can do that."
Same for the trademark team: we have a brand-new trademark team.
I need to prepare... well, someone needs to prepare a draft of the delegation.
We have some ideas written down, but they still need to be consolidated.
d-i is quite... There is not really active development around d-i, so
a call for help should be prepared and posted to appropriate mailing lists.
We can try to recruit a volunteer for it.
We just need to write a job description, and work on that with KiBi, who is currently the most active person on d-i.
The Debian-Events team is... I was told the Debian-Events team is kind of MIA, so we just need to ping it, see what's the problem, see what could be done, etc.
The Press team delegation needs an update.
Someone stepped down. There's someone who could be convinced to increase the activity, maybe... It's not clear.
Related to the Code of Conduct discussion, there is the question whether listmasters should be delegated.
If they make the decision to ban someone from the list, and are not delegated, that's a bit strange.
Maybe it's not necessary, but we need to think about it.
Then, there is a big set of items that are about easing contributions.
I think this is something that is very important for the project.
Most of them are quite...
Voilà. Do you have questions on some of them? I think the label is more explicit than for the first set.
Some of them are really packaging-related.
Since I originally wrote a packaging tutorial, I have some items that are related to that,
but that's clearly something that could be... The DPL doesn't need to maintain the documentation.
And then, various items:
I did some usage statistics about testing.
With ftp.de logs it would be interesting to confirm those results.
With other logs... There's Amazon Cloudfront, which is used as part of http.debian.net,
and also ftp.mx, to provide the logs for that.
I have to... The DPL has to write, or someone has to write for the DPL, a paragraph for the DebConf final report.
I think it's more than one paragraph, actually. I haven't looked at it yet.
DSA tends to require a lot of small expenses, such as buying cables or shifting servers around.
It's a bit stupid that each time they do that and ask for 100 Euros, they need to go through DPL approval.
They wondered if we couldn't have something like, they are allowed to make expenses of no more than 200 Euros every seven days,
so that they don't need to stop when they start working on something, to ask for DPL approval.
Of course, notify DPL and auditors that this is happening,
In the worst case, that means they spend 200 Euros on something we don't really want,
but we can afford that.
This needs to be raised on -project,
so that we can have a project-wide discussion about it.
And then, some mediation. Well, one mediation specifically:
In the lxc package there is a debian template that is quite different from what upstream provide,
and apparently many users are quite unhappy about that,
and prefer to use the Ubuntu package.
Also, that template was broken in Wheezy, which is a shame.
Someone needs to talk to the lxc maintainer about that, and see what can be done.
So, really I think that those tasks are quite different in nature,
and not all of them could be addressed the same way.
For example, for some of them, the role of the other person would be to write the draft, provide the draft to the DPL, and not all of them could be addressed the same way.
For example, for some of them, the role of the other person would be to write the draft, provide the draft to the DPL,
modify it and send it to d-d-a, for example,
(...?)
That would be quite broken.
For some of them it's about doing all the actual work, actually write and submit a patch, or maintain a packaging tutorial.
Doesn't need to be done by the DPL; there's no special authority required to do that.
For some of them it's more like coming up with a summary of options while looking into an issue, and recommending something to the DPL.
And for some of them it's more about looking into an issue and providing detailed feedback on an idea.
The last two are quite similar, actually.
There are more people in the room than the sum of people who ever attended the DPL helpers BoF. The obvious question is:
What are your reasons for not taking a DPL helper task yet?
Then, how can I help you pick one?
maybe we should think about reducing our expectations of what the DPL does.
That's also something that we...
If the answer to the first two questions is, "It's not possible; I would never do that", That's also something that we...
It might be a good thing to allow people with more diverse personal... work... That's also something that we...
It might be a good thing to allow people with more diverse personal... work...
...day job and stuff like that, to apply for DPL, because...
we have kind of a shortage of people in French academia to run for DPL, so...
Maybe one question related to that: maybe the DPL should just try harder to offload work to the relevant teams.
The problem is that the relevant teams are usually teams that are already quite busy with lots of other things,
so it's not really... it's just moving the problem to the next step.
So, maybe start with that, who wants to comment about that.
[Wookey] I guess I'm fairly typical in that I may be interested in helping,
but I have 46 other things to do,
I don't really need to do any DPL tasks,
I'd like to help, but mostly I'm too busy
with all the other things I was supposed to be doing already,
not even necessarily just for Debian.
I guess that applies to quite a lot of people.
I don't really have any answers, I'm just saying that's why I haven't done anything yet.
So I'd kind of turn up and listen and see what's going on.
I've taken more of an interest in this than I used to, for the last seven years, you know.
I have actually come to this, I've been to at least one IRC meeting,
so, you know, I'm approaching actually doing something, maybe.
[Marga] For some of the tasks, I don't see why they are listed as DPL tasks,
like the packaging tutorial thing or the ITP template.
[Lucas] For many DPL tasks, there is no strong reason for the DPL to make them,
but if the DPL doesn't do them, usually it doesn't happen.
It might be that they are not important enough,
but I think that most of the people in the project agree that we have a problem attracting new contributors and that we could do better.
[Marga] I'm not saying that those are not tasks that should be addressed, I just don't see why they are DPL tasks.
Maybe they are just things that we should do, but anybody can do them.
[Lucas] The point of having them there...
They are there because they are basically things that I would like to keep an eye on, and make sure that things progress.
Clearly, in terms of priority, what's there about teams...
I'm going to try to do that before working on the HTML version of the packaging tutorial.
[RichiH] I do actually help with the trademarks, but from this perspective,
if you had asked, "Hey, I need someone to do DPL work", that's a big and scary thing.
But you asked, "Is there someone to help with trademark?",
and that's a clearly defined sub-problem,
and I thought, "Yes, I am able to do this."
Maybe a little bit in the same direction: DPL helper talks are big and scary,
and clearly-defined problems of domain X are not as scary, if you are somewhat familiar or happy with that particular problem domain.
Maybe that's one of the approaches to better define the problems,
and simply put out that these are the things which are currently open,
and they may not even be DPL helper tasks, they may just be Debian tasks,
which no-one actually does at the moment, because if I understood you correctly, and they may not even be DPL helper tasks, they may just be Debian tasks,
which no-one actually does at the moment, because if I understood you correctly,
you more or less said it needs to be done, so you just pulled the task to you because somebody has to do it.
I've tried to describe tasks (not really there because I want to keep it short, but...)
in a quite actionable way so that people understand that what they would be supposed to do if they agreed to do something.
One problem with that, though is that, from my point of view this takes a lot of time, everything teams-related,
and actually, this is not the most fun thing to do.
Doing a mix of this is more interesting from my perspective than finding people to do all of that and then getting stuck with it myself.
Those are probably harder to split into... a quite large amount of work that could be transferred.
Individually it's quite easy, but then
sending a call for help on d-d-a for that, and waiting for people to volunteer,
Sending a call for help for someone responsible for preparing delegations for the next six months, that's a bit strange was well. That might not work - I'm not sure I would get volunteers for that.
[Zack] I think an important point here is that on the one hand, the role of the DPL is something people look up to. It's a cool thing you do, you're representing the Debian project, and so on, and so forth,
but on the other other hand, it is also a kind of a dumping ground where we as developers push stuff which is not funny to do and which is not something we would like to work on.
and in some ways, that's fine. Actually that's part of the constitutional definition of the DPL. It's some sort of "decision garbage collection". Not only "decision", because it's also some sort of "action item garbage collection".
The important point I think is that here in Debian we do ourselves, as volunteers,
a lot of stuff which other projects have other ways of doing,
usually by having some corporate support, or by hiring some paid staff for this kind of stuff.
I think here what's at stake is really: "Are we really able to be sustainable as a project and work on this kind of stuff, or not?"
If we want to be, and I think it's truly important to be independent,
we need some sort of collective awareness that this stuff needs to be done.
There have been, in the past, DPL tasks that took 4 years, 5 years to complete, but there was stuff on which the project was blocked.
I guess the question is: "How do we make people realise more often that everyone needs this kind of stuff to be done?"
It is just insane to think that one person at a time, the one who is elected as DPL, can reasonably make progress on all of them.
I think the question is: "How do we collectively realise that we need progress on this,
and then how do we attract volunteers to work on this?"
I think it's not only a matter of "It's not fun to work on that", sure.
I think it's really trying to make people understand that we need progress on this as a project.
[Wookey] I'm sorry I missed the beginning of this, but have we considered paid administration for some tasks?
Has anyone thought about how that might work? Are there jobs?
Again it's the question of job divisibility.
Is there a little blob that you could actually give somebody?
I guess it's the same problem as paying developers.
It's tricky in a project with a culture like this.
[Lucas] If you start going in that direction, The other problem is that you get less diverse...
Who would be interested in that work? For example, I cannot easily give up my current position, probably.
I could try, but the process of giving it up requires at least one year.
due to French administration latency. [Wookey] I wasn't suggesting that we pay the DPL, I was suggesting that they had a paid serf, a PA, that kind of concept,
and if that person stuck around, you might get some useful continuity out of it.
I don't know, it's not very Debian-ish.
Just wondering... If we've already decided it's nonsense, then we definitely shouldn't do that.
[buxy] My problem with DPL helpers is that we see lots of administrative work mainly,
Sometimes it's not even much. I mean, I could probably spare the time to go and ask the Debian-Events team what's going on and report back to you,
but when I see the DPL, I elect him based on a vision and some direction where I want him to steer the project to,
and if I want to help the DPL, I would like to help him do that, and not really...
If you had on your list some item "Steer the discussion on the Code of Conduct", this could be interesting for me, but this is not really.
So, maybe you should broaden the list of stuff to do,
because even if it means some of the administrative stuff will not be done right now,
it means at least you have the opportunity to attract people within your team to help you do some interesting stuff.
[Lucas] Yeah. I think that we are kind of...
During DPL elections actually we kind of forget that most of what the DPL does is not-so-interesting tasks,
and he or she needs to demonstrate an ability to work on that kind of things also,
and we don't evaluate that, actually, during DPL elections. That's really broken.
We might end up with someone who has a great vision for the project,
but who totally sucks at doing that kind of boring daily stuff.
That would be really harmful for Debian.
How I see that is that... Basically, if I...
Let's say for some reason I could not dedicate as much time as I currently do to Debian suddenly.
The things that I need to do, not all of them are really that important, but
some of them are very important and I still need to do them.
I don't think that being the DPL,
giving lots of great ideas about the project,
and pushing a vision without doing the actual work behind it
would be seen as something positive by the rest of the project.
So I just want to... [buxy] Delegate the interesting part! [Lucas] Hmm? [buxy] So you have to delegate the interesting part.
[Lucas] So I have to delegate the interesting part. That's...
That's why I'm interested in delegating this, so that I can do some of the interesting parts.
But I just wanted to clarify also that...
in Debian, some people are great at pushing their own ideas, own projects.
Some of them are not so great at that, but still have great ideas.
Only the pushing part, they are weaker at.
And I think that it's really important to clarify that everybody is welcome to come to a DPL helpers' meeting,
and describe ideas and ask for feedback,
and "How should I go forward with that?",
and I think that having a place where you can get feedback on your ideas and how to push them to the project as a whole, that's quite useful for many project members.
It's not really OK that, in Debian, if you have a great idea you need to be good at pushing it so that it can reach completion.
[Richi] Maybe if you have some kind of bugtracker for these tasks, and even make them release-critical in some sort of sense?
Maybe in your "Bits from the DPL" just note "OK, guys, these are still open issues, and nobody volunteered this month",
"How about next month, how about next month, how about next month?"
Of course, you run the risk of just generating noise which gets ignored at a certain point,
but still this would keep up the awareness of "Hey, there's too much work to be done, this guy needs help."
[buxy] I think it's a good idea. You could share your to-do list on d-d-a (debian-devel-announce),
but I don't think anyone will grab anything written like that.
But if you prepare a little bit of work, in terms of "What's the next step in this specific project?",
and if you give a longer introduction to to explain context and everything
(because not everybody will understand what it means to talk to Anibal about the new NM website - they don't even know there is a new NM website),
so I think it would be interesting to have some sort of tracker with a longer explanation and a next step.
So even if you don't handle the whole item, you can at least do the first step.
And, it means you have a log.
If I query Anibal, I send a mail and ask him to respond to the bug report,
and someone else can pick it up later.
[Lucas] So, one issue with that... [buxy] Not all issues can be discussed publicly, that's true.
[buxy] At least most of them here look like they would fit. Probably...
[Lucas] Yeah, yeah, public now, but not the next step, for example. [buxy] At least most of them here look like they would fit. Probably...
[Lucas] Yeah, yeah, public now, but not the next step, for example.
For some of them, the next step is how to get people to agree on something on which they currently disagree.
[buxy] ...which in consensus is often done in public, sometimes it won't work, but sometimes...
[Lucas] You can always (?) [buxy] It's often about people more than technical stuff.
There are people that support it, and others that don't.
It's true that I could try to be a bit more verbose about what's the current state, and what's the next action,
but for example, for those two, we have a draft, a list of items, for delegation.
It needs to be rewritten to proper text, and then go through the respective teams.
They can provide feedback and iterate on that.
[Lucas] That cannot... that could happen... [buxy] Well, even if you have only the bug report with a link to the TitanPad draft, it's still better than the current status.
[Franklin] I was suggesting to have a public to-do list, maybe not the whole to-do list but, the same way as said,
focus on some items you want to achieve in the next month.
Since usually one nice way of having things done is to not do it yourself,
(or not do it at all, actually)
I'll read the line: "Write a call for help for the d-i team".
Maybe you could just send a mail, very short, to the d-i list, and say:
"The d-i is not having much attention at this time; could one of you prepare a mail, and send it to debian-devel?" - just offload,
and, by saying this, it's also...
There's also another thing I wanted to say: "DPL helpers" is a bit scary.
I wouldn't get into the whole thing.
I don't want to attend meetings every week, but if there are some items,
like, having more people in the d-i team, it's something I could be interested in.
If you said, "The d-i team needs more help", then I would send a mail.
[Lucas] I could push more of the work to the relevant teams.
I said for d-i, the problem is they are too busy.
Many people in our teams in Debian are past the point where they are able to ask for help themselves.
[Franklin] People who are overloaded sometimes need someone to say, "Hey you, you can't do it yourself anymore, just do ask for help, and maybe you should send this very small e-mail", and it would trigger the thing.
[Wookey] I was just wondering about the concept that's been mentioned a few times. There's a difference between the leadership and the administration.
I mean, they're quite closely tied, and that makes them difficult to separate.
You can be good at administration, you can be good at leadership,
and we haven't got that many people who are great at both - and, it's a lot of time.
Could we try having the Debian Administrator as well as the DPL? If we made another position, would that help?
(Kind of additionally... Or is that not really... Because you'd just spend all your time communicating. It would have to be someone you get on with, I guess, otherwise it wouldn't work.)
[Lucas] It would be interesting.
[Stefano Rivera] I've always been a bit surprised (no, not surprised)...
I see there's a bit of a conflict in DPL elections, that we are electing someone to be our leader,
but most of what we expect them to do is be an administrator.
However, the leader has no teeth without the administrative powers.
Would anyone listen to someone who just made a lot of noise, saying "We should do these cool things"?
We've got some crazy people who do that on the lists all the time, and we ignore them.
To some degree, yes.
Wookey said the authority comes from doing all the boring work; that's probably true.
But maybe it does make sense to split the administrator from the leader, because they are totally different things, suited to different people.
[Richi] In such a case, you have the problem of how to determine who is the administrator, and how long will it stay the administrator.
If this person is, like our secretary, going on and on and on for years,
to be the de-facto administrator and the de-factor Power That Be,
this person gains more and more power, both implicit and explicit, over time.
So, this may be a real risk,
as in: even if this person doesn't even intend for this to happen, but still...
You kind of... it doesn't feel right. That's the short version.
[Wookey] You could deal with that by effectively having the administrator come with the DPL.
You get a pair for that period.
Continuity is actually useful in an administrator,
but as you say, there is the problem that they'll slowly acquire stuff, which could become an issue after a while.
I don't know... I guess we press on with this "helpers" concept for a while,
and see whether we get enough traction in general assistance distributed through everybody,
which seems a better concept, if we can make it work.
If it's still not working in another year or two, then I think we need to think harder about another position.
[Lucas] We have had DPL assistants in the past, or a second-in-charge, but I'm not sure how the split of powers worked between them.
[Zack] Right. There was a point we discussed that you forgot to mention at the beginning was that the idea of the DPL helpers team was actually to have more continuity than a single year,
and that your comment now made me remember that.
The problem with the DPL assistants is that if they are tied to the same period of one year, which is relatively short,
to learn how to get around. So then you still have the problem that every year you start from scratch, with inertia and common mistakes and whatever.
That's part of the reason why a hypothetical, more-stable DPL helpers team would need to be longer than a DPL election term.
[Lucas] Zack, did you read the DPL-archives about how the second-in-charge and the DPL interacted in the past?
[Zack] Partly, yes, so I think the question is: "How did they work?"
I remember only the last time,
and I think they both read leader@debian.org,
and they just coordinated via the same address. I haven't checked the AJ case in the past.
[Franklin] You have a whole list of tasks. How to get on now?
Do you intend to publish them in some way so people can grab them?
Not just today - you could shout and say "Yes, it's on here!" That's one choice.
[Lucas] So, what I've been doing during the last DPL helpers' meeting, and the one before, I think,
was to publish that to-do list,
which actually is quite a lot of work,
because rewriting your to-do list that you write using more direct words
into something that you can put in a gobby document...
It's at least an hour of work to write this down and find the...
DPL helpers happen once every two weeks, and in the future I plan to continue to publish that kind of to-do list, probably a bit more verbose.
Feel free to attend the meetings and ask for details about some items.
One of the questions is: in Debian we tend not to do IRC meetings that often.
That's not really something that's really common in Debian culture,
except for some teams like the DebConf orga team.
Is it a blocker for you that meetings are on IRC at a specific time, that you have to be there if you want to participate?
We could try to better at changing the time each time so that everyone can participate, or try to move to mailing list discussions.
Nobody feels strongly about that?
It's not really about problems about IRC. It's about holding the meetings on IRC at a specific time.
[Stefano Rivera] Of course, there is the usual problem that these groups end up self-selecting,
and the people you've got here are people who've found these meetings happen at times that suit them.
Other people might have taken one look at DPL helpers, but decided maybe [?] was more interesting, because they never got involved.
[Zack] Just a general comment: I feel personally pretty strongly about the usefulness of a periodic IRC meeting, especially in this case because it's a place where you have tasks that have been lingering for a long while.
So having a periodic reassessment, "Are we doing progress or not?" is pretty useful, but your mileage may vary.
[Lucas] I fully agree with that,
but we could do that via e-mail as well.
I send monthly e-mails to d-d-a; we could have the same kind of e-mails sent on a regular basis to...
I agree, it's better to have IRC meetings for that reason.
[Richi] I guess it makes sense to have the IRC meetings because it's just easier to sync up quickly,
but there's no harm in having a back-up place on e-mail lists,
where you can go through issues a little bit earlier, and then do the actual more involved discussion in real-time.
Maybe it would even be a possibility to put DPL helpers discussions onto debian-devel or debian-private,
to kind of force people to keep seeing those issues popping up.
So, not to move it away to a place where only those people who really care,
and who really decide, "Yes, this is not scary enough for me to run away," see this,
but so that everybody continually sees there is stuff which needs to be done, this is happening,
"They may need help here - hey, that's something I can do."
[buxy] I wanted to say there is also the Technical Committee which is doing regular meetings in the same way.
but I really feel some difference between both,
because on one side there is a team who is trying to find a solution and reach consensus and what is the best way to go forward,
whereas in the DPL helpers meeting, it looks more like you asking each volunteer individually, "How far are you?",
and not so much a discussion or decision-making group.
While it's useful to ping people, I don't think it needs to happen over IRC always, at least.
If you move some of the management to a bug tracking system,
then you can at least use the "owner" feature to record who is working on each entry,
and at least some people can help on a specific item without subscribing to the whole DPL helpers infrastructure.
[Richi] That's actually a very good point. Most of the things we did within the trademark team could be done on the mailing lists,
and it was more or less just reporting back to you what the actual status is, what we did,
what we came up with, and just pinging you, "That's the actual status".
What we did a few days ago while sitting around, that's something which is better suited to IRC, where you just have real-time communication,
and the whole team is better than just one of the team,
but all the other preparation and especially the "this is the status" can be done asynchronously.
That would probably make it easier both for you and for others.
[buxy] Someone help me... [giggling in the background] I changed the topic, just a question for you for the fun:
Would you consider delegating someone to steer the discussion concerning the Code of Conduct?
For example, Wouter started it. Would you mind giving him some sort of official status to try to bring it to a conclusion?
[Lucas] Hmmm, good question. Well...
[buxy] Assuming you're happy with what he's doing...
[Lucas] Can you think of another occurrence of someone being delegated to steer the discussion?
It doesn't really sound...
I don't think we need that.
I fear that that would be a way for that person to push his views quite strongly,
and it doesn't really make sense, especially for Code of Conduct discussions.
[Richi] To put a finer point on this, if this happens, as you said, there is the possibility of that person just strong-arming their way into the direction which they want,
instead of trying to reach consensus.
I just lost my point... Sorry.
There would be a lot more discussion about "Hey, you delegated - or mini-delegated - this person,
why not mini-delegate someone else?", so you would just...
If people are aware of this person having this leaning, or this type of agenda,
it would just move the discussion about who gets to really decide and lead.
[buxy] Well, I say delegated, but not in the official sense - just like you try to delegate those tasks.
Just that it will happen in a framework, so that he...
You ensure that there is some progress made,
and you can annoy him, "Hey! Did you miss something?"
[Lucas] One thing that could help with the Code of Conduct discussion is to find a group of three to four people,
who care about it and who disagree on some aspects of it,
and ask them to push it forward together, trying to reach consensus between themselves, before it gets too much larger.
Mailing list discussions are difficult to converge.
That smells of a working group, which doesn't have to be a bad idea,
but then you have to make sure that the working group keeps and remains open,
because else you would more or less exclude the rest of the project from the pre-selection or pre-discussion.
and then are fed maybe even foregone conclusions, which will probably get quite a resistance within Debian.
[Lucas] What often happens in Debian is that everybody thinks that something is quite important,
but nobody feels particularly empowered to work on it.
and for the Code of Conduct, for example, I think that was the case for...
I'm not sure Wouter even feels like...
I'm not sure of his motivations for working on that, but he might not feel very empowered to work on it himself.
He's pushing it, which is great,
Having a more explicit way of saying "Thanks for pushing it; please continue", that could be quite good.
[buxy] Yes, I guess encouraging him is a good idea,
because I fear he is going to run out of time after DebConf,
and this will not go further, which is a shame,
because, while we've made a bit of progress, it would be nice to go to the end.
[Lucas] OK, I think we are out of time, so thanks a lot for attending.
I will watch the video and prepare some minutes for the BoF,
which I will send to...
Probably I will provide the link in my next d-d-a bits.
[unidentified audience member] There is a DPL helpers mailing list?
Oh I see, yeah, there is a DPL helpers mailing list,
I will post the notes there,
and provide a link to that in my next d-d-a bits.
Thank you.
[thunderous applause]