 Thank you, Todr. Great, welcome to the Meet the Depp in Technical Committees, BOF or TOC, whatever that is. We plan to have a short reminder of what exactly the Depp in Technical Committee is, and I'll start with presenting the actual members. So we have Andreas Bart, to my left. Don Armstrong is unfortunately not at DeppConf. We have Keith Packard, myself, Odyx. I'm the current chair of the Technical Committee. Tolle Foghien, Sam Hartmann, and Bill Hentz. Hello. I'll start with what is the Depp in Technical Committee actually? It's all written in the Depp in Constitution, which is the Bible you should have by your bed, and read it from time to time. It's useful for getting along in the project. So 6.1 says the Technical Committee may decide on any matter of technical policy. It may decide on any technical matter where developers' jurisdictions overlap and make a decision when asked to do so. That's basically tie-breaking. It may overrule a developer with a 3-1 majority. That's the nuclear weapon we have. We don't use it much. It's the last resort point. And 6.1.5 says we may offer advice for the project or for any question, basically. We are limited in these powers by some constraints, amongst which we have to have public discussion and decision-making. We cannot do detailed design work. And we make decision only as last resort. Constitutionally, we are picking options. That means we are asked to break ties amongst available options. After all efforts to resolve it via consensus have been tried and failed. And we can offer advice and make our views known. That means we can offer you advice if you want. After all that constitutional thing, we can say the Depp in Technical Committee is a self-nominated and DPL-appointed last resort conflict resolution and advice-providing body. Any questions so far? I know it was quick, but you might, oh, no, that's all. Let's move on. It was traditional of the Technical Committee talk to have a short review of the past issues that we had in the TC since the previous Depp conf. They're all listed under the Tech CTE-CTTE pseudo-bug list. And we try to have everything we are publicly discussing there. We have actually decided on two, six issues. I won't read all of them, but there were two that made it into a GR, on which we voted in March about the supermajority fix and duplicate section numbering. We had one on the menu system. We had one discussion about how we want to appoint the Technical Committee chair. We did make it a constitutional change. We just adopted it as an internal procedure. We have proposed Phil for nomination to NU as DPL back then, and we have voted for the CTG chair. We also had four issues that were dropped or retracted in the last year. There was the coordinate plan and requirements for cross-toolchain packages in Debian. Some weeks ago, we decided to drop that issue from our list. We also had two other things concerning how the TC works itself, so the introduction of a formal cloto vote and the change in the constitution to permit us to hold private conversation, which we dropped by saying it's already permitted and we make use of that right. And there was a discussion between the OpenSSL maintainer and the stable release managers about the new OpenSSL option versions, which found its way outside of the TC. Exactly. And we have currently only one open issue that is new Technical Committee members, which brings me to the next point. We're looking for new members. As an introduction for this, we have adopted two or three years ago in the constitution a new thing about term expiry, which says on January 1 of each year, well, you can read it. Basically, it says the term lasts three and a half years roughly, and it's a small set of conditions. So we can see here the list of the expiry dates, kind of expiry years, in order that means that we will be losing under us and done by the end of this year. Keith, next year, tolef and myself in 18, and then Sam and Phil in 19. That means we need fresh blood. We're roughly looking for at least one new member. Where are we? Except for tonight's skating. We're roughly looking for at least one new member per year. It's between one and two, but if we can at least have one new member per year, it can be sustainable. Not all these shoes are like 72, 77, 0, 8. Most not. So I will tell you that the work I've done on the technical committee that I'm really proudest of was something that took me one evening. And basically, someone had written to the technical committee really frustrated because the release manager didn't accept a patch, and they believed that without that patch, their software would be something that they couldn't maintain. And they basically were really frustrated about this, and like, how could this come about? How could the release manager not care? I took some time because the release managers are pretty busy. It sounds like I'm not a release manager, but I can talk about the trade-offs here and said, look, the release manager has to make some trade-offs. And it's absolutely fine for you to say, well, if you won't take this patch, you're going to need to find someone else to maintain that software in the release because I don't want to do the work. Debbie and I were volunteers. But it's also fine for the release manager without saying you're a bad person or anything like that to say, I don't trust the risk of this patch. And being able to write that up and kind of explain that situation is the thing that is, I think, so far my best contributions to the technical committee. And that was really easy. And I think was helpful. I don't know whether it was helpful to the individual person, but several other people have come in and read that and said, ah, that was actually a really useful thing to think about the issues involved there. Well, actually, I mean, I'm one of the survivors of the buck mentioned before. I think I need to say it this way. And most issues that we had, I really not said bad, but last time, people had some misunderstanding and needed some external help to make some speaking together or even some cases where it was just an honest split up between maintenance that we could go this way or that way, but we just can't come to an agreement and just make a decision, please, now for us, which is fair for me because nobody will get hurt if you say, we just disagree, but we know we can take both ways. But we need an external somebody who makes a decision. That's not that bad. So yes, this was a single buck that we had. I think you all know that, but in normal cases, the committee are way better. And yeah, so we had this one. I don't think we had any of that kind ever before since the committee was set up, which means since the constitution was written. So, perhaps we have another one in 15 years where you could volunteer now and be out of office before it happens, getting quick. Well, we're so friendly. So what we can say about the TC work is it's about disagreements and conflicts. It's at the broad technical level. One thing we can say is that we are not all kernel hackers. I don't code in C all day, if at all. It's about listening to what people have to say. I had initially written that sentence by saying talking to people, but actually less talking and more listening. Sometimes taking hard decisions, we're one of the bodies with some powers in the Deppin constitution. And it's essentially political. So the required skillset, sorry, we are looking for is people's empathy, technical agility, the ability to take a look at the problem you haven't seen before and take a distant look and global look at whether it's sane or not. Someone that you might consider as your mentor would be a good person to join the TC, for example. We're also looking for people that are reactive that can answer in mails in, what we said, one week. At least read the mails in one week. Some social sensitivity and cool-headed. It is crucial for the TC to be representative of the developers. We are really trying to expand, to have the TC be a accurate representation of everyone that is acting in the project. It used to be Northern American white males. It has changed to some extent. Native English speak, I think we had at least one long-term TC member who would heavily disagree with some of you by this day. So, yeah, we're looking to become more diverse. So we need nominees. One of our problems is that we had multiple calls for TC nominees and we didn't have like 25 people amongst which we could pick. It was hard for us to get enough nominees. So nominate yourself if you feel it's interesting for you or could be interesting for the project. Nominate anyone you could see at that position because they might not have thought of nominating themselves. And being nominated by someone else you can make this person also wonder, well, I hadn't thought about that before, but okay, it might be interesting. And come talk to us. If you have worries, questions or else that are about the TC itself, issues in front of the TC or whether you might be interested to work within the TC or with us, we're just developers. As I said before, we're not special in any way and we're here to help. So in particular on that, I'd like to say that I think it's better if you contact the TC at a point where you're still engaged in the process where you're still constructively engaged with all the parties than where you're so frustrated you're no longer talking. That yeah, no, I mean, you know, if you're going to be able to work things out and you don't need us, that's great. But we would rather get involved at a point where people are starting to realize, hey, this is thorny than at a point where I'm never talking to that other person again. That said, if we have to get involved in a situation where you're willing to talk to us, but communicating with some of the other parties is challenging, we'll deal with that. But we would have rather been involved sooner, I think. It's certainly easier to do it and have the decision at the end need something that we're all happy with. One thing that I think is, when I, no, okay, I'm the T-boy in this group, I only just arrived. Why weren't you getting us coffee then? Well, I closed the bugs, right? I closed all the bugs. So anyway. So before turning up here, you know, it's very easy to say, well, there are some sort of gods that we go to in supplication to sort out our problems. The thing that becomes instantly apparent when you're sitting on this side of the table is that if there's an argument that's gone on long enough for people to start spilling blood, then the subject experts are definitely not on this side of the table. They just don't agree. So when they have to explain to us what's going on, it's gonna take some time because we're coming to the party late and they are already carrying so many assumptions with them that you must know this because I've been concentrating on it for two years. Everybody must have heard about it. Well, probably we don't. So if you leave a situation to go sour enough so it's gonna be ruled on by the technical committee, there's pretty good chance that it won't actually, it won't be completely clear to us instantly that you are right. And that means you've got a good chance of not getting what you want. So if you can sort it out yourselves first, great. If you wanna come to us and have it mediated so that you don't have to start stabbing one another, that's even better. I'll just continue and then we can have the lively discussion also about that but I have more slides. Not many. About the recruiting process, we're also looking into ways to improve it because we had announcements, we didn't really announce a time span and we are looking into announcing something like the DPL election saying this is the period where we expect nominations, this is the period where we will run the internal discussions and vote and then we expect the DPL to be able to have a decision by that date. And if we don't have enough candidates then we just wait another year and we run another session, something like that. It's not being decided. So we are having informal and internal discussions, mostly in IRC and by discussing with each other. One very important thing that has improved but is not perfect yet is the TC responsiveness. Both internally and externally, how we respond to mails, just mails on the bugs and how we are progressing together towards resolution on some issues. Also we're discussing our ability to pick options in a timely manner. For some of the past issues, it would have been beneficial to pick any of the available options and picking any of the two options would have been better than letting the time go and not picking even if the picked option wouldn't have been the best but picking is better than not picking. And we are wondering about the amount of issues we don't have any other than recruiting currently. So we currently have few issues to solve and we're wondering if this is in any way an indicator of the health of the project. If people are not having conflicts is maybe they're not talking to each other or no one is doing anything anymore or it's just that everything's happened smoothly. We don't know. And we are also kind of worried about the time we spend on recruitment and having to find one or two members per year and not having any other issues than that is not really useful work for the TC to conduct. So that's it. We are now to the point for a Q and A open discussion. We started to dive in some of the things already but the stage is yours or we can have another coffee break. Any questions? Any nominations? So it's now either questions or nominations. And we could just go to both doors and then we can see who gets out. Go for a tilt. I think it's decent. Sexy. So I hear there's a guy behind me who's over the question. I didn't hear anything. He said there's a guy behind him. So is there a nomination? So I can see here one. I think it's a serious question. I think it would probably be best if people only nominated themselves in public like this. So, okay. I was going to nominate myself. No, I think really, I mean, we should just get those questions because it was really good the last years when we started with some. So how many nominations did you get for the last call? We got, I remember correctly, I think we got seven. Seven. That's about. Amongst the seven, yeah. But I think it's also, I wish we would choose to disclose how many accepted. Yeah, so, but from the seven, I think most didn't accept. So we have run up as very few candidates and of course, yeah, we had, we finally managed to pick someone up. And the bottom of the barrel. No, that is so not true. Not everybody's good at running, you know. In terms of actual time commitment, I don't think we touched on that, but we're looking at about an hour a week. So it's not a huge time commitment. Of course, if something huge happens, then that might explode. But in general, we're not looking for somebody to have this as a 25% job. What's even made this? Yeah, I mean, you just need to be able to keep up with the mail and well, or if the times when you're not keeping up, do especially do not both fail to keep up and then raise last minute objections. That's, wow, does that get frustrated quickly? So I think there was another question. Hi, how can you quantify a bit more about the improvement of your responses? It sounds like it's an interesting balance between the cool headedness aspect, having to cool down a bit, because it's waiting to think to resolve themselves. Basically, it's just what Tollef just said. I mean, did your mails and answer in a timely manner? That's all, because both of us have the same thought. It's not helpful if you get mail and we can't get an answer because nobody reads the mail within one or two months. So yes, did your mail answer to it? If you have questions, ask questions. Nobody says you need to respond within five minutes, being normally able to respond to mail within a week might be quite helpful. It was also the question of acknowledgement is that we as a body have to progress together towards a common understanding of what the problem is and what possible solution could be. And our responsiveness problems were like someone spends some time writing a long mail about his findings, et cetera, and gets basically no acknowledgement because we all act as we all act in unmailing lists, like we don't send one mail saying plus one, or I agree. Which is as a body is something we now seem to need because then you write this long mail and you need a way to see that the rest of the body actually agrees with you or disagrees with you. Yeah, we are just discussing that right now. It's actually going to be plus one mails roughly. I would prefer questions by the microphones because that's a video sequence there. And I think Anna has the next one. I was wondering several years ago, I don't remember who proposed this, but some people that have run for DPL have advocated as part of their platform they would call for a social committee because well, the technical committee should be focused on their technical work. But well, now you say that a big part of your work is actually social. I mean, it's not so much of a question, the answer is obvious, but maybe for the more long running people among you, what do you think that led to that impression to somebody that was running for DPL? I'm not speculating on other people's DPL platforms, especially not if recorded, but otherwise, I mean really, I mean we are not the chief architects of the DPL project, that's not what we are, that's not what we are good at. Some of us might be chief architects in our work, but that's something else. So, and it might mean it's not true both for the committee and some of you know, I've been long term, the least team member, both there. It's not that you have made final, great technical decisions, so everybody says, oh yes, that's really great, we never have thought of it, but people come to you with problems, they say, oh, we don't know how to do it, we don't know how to see back to fix, we have a disagreement about the maintenance that does, do we, can we accept the page, is it too risky, and then what you don't do is, you don't go and say, oh yeah, I look at the page and my decision, final decision is, okay, why do you believe it this way, why do you believe it the other way, and come to another side, which everybody makes happy, so it's lots about speaking, it's necessary to be able to understand the technical things behind, because if you say, oh, Petra, is it, it doesn't help, obviously, but so it's more about speaking with people about technical issues, and that's basically in all of that, let's say high level technical things in there, we need to make sure that the people speak to each other, so yes, this is something social, but the social thing about how to get on technically, it's not about, oh, I was feeling as somebody was treating me unfairly last night, it's a Mao game, so now I need some, whatever, that's not our purpose, but I don't understand why always my patches are refused, yes, please come to us, that's one of our duties. I think we also changed our understanding as members, we also changed our understanding what the TC work is, and we are, I think, progressing towards more, that's also why it reflects in the skillset we're looking for, it's also very much social work, and we're going in that direction, which makes the idea of a social committee kind of useless because we become that, basically, our understanding moves into that direction. I mean, we will never be a committee that decides on balancing, say, non-technical aspects of balancing our users versus the free software community, but when it has the technical implication, we can give input. I also think that the entire DBM project is over the last five to 10 years, maybe even more, and gain an understanding that a lot of the problems which we're trying to fix are actually, they're about communication, they're about the people, they're much more about that than they are about actually fixing a particular technical problem. So, and I think that it's basically just a reflection of the project as a whole, more than it is something that the technical committee has gone out and done on its own. This is, yeah. And perhaps also to say, for example, whenever the member platforms running something in 2005, 2006, and I think that very interesting discussion at these times with the DPL candidates, more or less the daily committee was, let's say, had a few members who were not so active anymore, so we had a hard time to get them to the sign from the committee because we couldn't even get enough votes for them to expel them from the committee anymore, so that was then fixed. We had a few new members added, that was Steve and me later on, Colin as well, and so we get to the committee from, they don't even look at bugs and don't work to, yes, now it works, we solved some issues, we did some better, some not as good, I mean, long-term observers could remember that, but so we really got to the committee to working again, and back at that time, I think also it was the first start of, oh yes, Deppin isn't only about technical decisions, there's something else in which also changed the way the DPL interacts, or some of the DPL interacts, we managed to get migrated from, we have the CFDP masters who occasionally also do releases and just shout out, oh now it's frozen to the least, to something like, we have a release team now, with multiple members, so there were a lot of changes in the project as a whole. I'm just pointing and just pending a bit exaggerated picture of course, but yes, the project changed a lot in the last, whatever, 10 years, and I think in a good way. Anymore, don't be afraid, we don't bite. So, and just as a, to hope to start some discussion, one thing we'd love to hear about now or later is if there are things we ought to be looking at, if there are issues that are starting to boil up that maybe we should care about, that would be a great thing to tell us. If no one has problems then, good? Continue the good work. Yeah, I want to add what Zobal just said, it's not so much of a question, but being on a technical committee seems like an extremely thankless job, so I guess I just want to say thank you for all your hard work. Let's see. One question there. So in terms of what you're saying of that now the committee sees its role not purely as answering technical points, but also thinking about the social factors behind them, do you think there can sometimes be a contradiction between those two things though? Because maybe on the technical side, it could sometimes be that you can rife quickly, say well this is the right answer. I know not on certain bugs, but in some cases, but it could be that there's actually a deeper social problem that is the real issue at stake, and that, so I mean imagine someone, one person is technically right, but actually they've been really socially bad in pushing that side. How do you see the kind of deal between the two things to sort out what would you? Well, if there's an obvious technical correct solution then one of our roles would be to socialize that appropriately and say yes, this person is being a total jerk, but they actually are right, right? And that would be a responsibility that we would have in that case, is to balance the, choose the technically correct solution, but to socialize it in a way that people can begin to accept it, that separate the technical issue from the social issue and try to solve both of them in our response. So whereas you might think that the only thing we would say is oh we're gonna pick the technically correct solution, no that can't be the entire response. It might be the answer that we provide, but the response needs to also acknowledge the social issues going on. And so that you would balance those two not by choosing the technically incorrect solution, but by having the response acknowledge the social issues as well. And also, I mean, in lots of cases when a conflict has been long growing there's some personal tension, it's often easier to not get some answers. This is the right solution for the person who has obviously said you're bad, but from some independent body who said, okay as we reviewed, we heard all of the reasons for both sides and we came to see that this really looks better because it isn't that it's an easier to take than of the person who is going on your nerves for whatever the last two years. So that might also help. Any other questions? All hungry? Deludged I guess. One at you. One at you. I think if you've ever tried explaining why you've got a tangly bug to someone and then just fixed it, I think that's also a role that we can have is that if there's an awful bug where neither side can agree and they explain it to us, then one of them might go, oh, bye. Never mind. So I will say I have pondered standing for, you know, volunteering with tech committee multiple times over the years. But, but, I think it, well, essentially yes. No, it's one of the important things that I think we actually do need to spread and represent more of the body of the Debian contributors in total. I mean, I'm one of the old God as my wife keeps on telling me I'm getting old. You know, I've done all kinds of other jobs in Debian. I think I could help, but I would much rather see other people with different experiences of viewpoints represented as well. So I guess I have just kind of volunteered, haven't I? I would rather, if you're desperate this year, then yeah, count me in, but I would rather see other people step up first. That's basically exactly what I said when I volunteered because it was only when the, was it the second or third call for volunteers having thought about it for six months? Because, you know, look at me. Okay, I'm wearing a skirt. That's almost diverse, but not really. But I'm here. No, yeah, that's the matter. That's great. I mean, so correct me if I'm wrong, have we ever had a female TC member? We had multiple proposals of females, but I don't think ever one of them even accepted to be nominated. I still think we had the same person more than once. So yes, I think there are very good female potential members of the committee. However, if they don't agree to be, yeah, what can we do? On the other hand, if you think something like that, and I can fully understand that, you can always say I nominate myself, but please prefer someone from a different group than me and me only as last resort. That's okay with us. Maybe then only pick the person if we have don't any other acceptable nominees. So, I mean, one thing to consider is that there's a lot of research that suggests that there are some groups that are more likely to self-nominate than other groups. We find, at least as a minor study of the research, we actually find the TC composition is very consistent with groups that are fairly commonly willing to self-nominate. So one of my advice to people who are willing to stand themselves, but who would like to see more diversity is to go in addition to volunteering yourself, go spend an hour or two thinking about who would be good candidates who would be more diverse and nominate them, and possibly even copy them on your nomination and let them know that you think they would be great and why. Because sometimes that can actually be enough to help someone get over that hump and accept a job. This diversity thing is both our responsibility because we pick from the nominees, but it's very much the responsibility of all the developers also to give us enough names. And you all know more people than we all know only, and we need your ideas of people that would be good for the TC and think wild. I mean, anyone that has interesting social skills in discussions and online that you have to sort, yeah, well, that's an interesting sort. That's a good way to tone a conflict down. Well, maybe just push them a little and dominate them for the TC. Just as a slight adjustment to what Sam just said, rather than CCing the person that you're nominating, I think you should tell us that you want to CC them because then people can opt out of being spammed about a thousand times by everybody in the project. Having, if there happened to be someone that says there's absolutely no circumstance under which I'm going to do it, then having their mailbox filled is not going to be helpful so we can just filter that. So if you want to CC them, don't actually do it, just say I'm very happy for this to be published to the nominee and we'll do it. Okay, I'm not sure I'm going to agree on that. I'm actually, I need to disagree a bit on that because basically the nominees may not send to the project mailing list but rather to a private place because especially if you could send a nomination to public list but if you don't need someone else. So if in the mail you say, and I'm happy for this to be forwarded. So yes, but. Then we can get forwarded and then we can not do that. But really, if it's private mail, just do it as it works but I've seen the five minute sign so I think the good suggestion is make sure that you know how many people you would like to see in the comment here also from a diversity point of view. I think that's an important thing and the other you see might be different but yeah, do it like you think it's correct. As always, exercise your best judgment. Last words from anyone? If not, then. So before we do the closing, I would like to thank you all for the trust that you had in me as a member of the committee. This is now my last year here standing here. Next year I'm happy to join B-Dale. So thank you for the support that we got and the trust that at least most of you had. I get less bad emails than other people on the board check in a recent decision. But anyways, so thank you and I wish you all and the future members of the committee that you are going forward in a good way. Thank you.