 Is it time? Yes, overdue. Good. Welcome to this Meet the Debian Technical Committee buff. It's intended to be a buff, so don't hesitate if you have questions or remarks or other type of communications with us. We have a small presentation, so we'll start with that. But if you have questions, don't hesitate. So the current Debian TC members are mostly all here on stage. I'll start in order, so we have Keith, myself as chair, Tolef, Sam, Phil, Margarita, Marga, David, and Nicottini, who is unfortunately at home, couldn't attend EPCONF, but Hai is probably following up on the video stream. But what is the Technical Committee all in all? You probably all read the Debian Constitution more than once, and you know that the 6.1 chapter talks about the Technical Committee and what it does. The Technical Committee may has a set of powers, and one of these is to decide on any matter of technical policy. It has also decided on any technical matter where developers' jurisdictions overlap and make a decision when asked to do so. It's subtitled as tie-breaking. And it can also, according to 6.1.4, overrule the developer, but it requires a 3 to 1 majority. So we also act as a last resort body. We can override developers. But we can also offer advice. The 6.1.5 point in the Constitution does that. And we are bound by a certain set of constraints. 6.3.3 says that we have to have public discussion and decision-making. 6.3.5 said we cannot do detailed design work. And 6.3.6 says that the Debian Technical Committee makes decisions only as last resort after all attempts to resolve the problem by consensus have been tried and failed, if I quote that correctly by heart. We're also constitutionally asked to break ties amongst available options. So we are picking options that are on the table, and we're not supposed by the Constitution to come up with solutions ourselves. So after all effort to resolve it by consensus have been tried and failed, that's what I just said. We can also offer advice and make our views known. So that also means that the TC can offer you advice if you have a technical problem or something related to Debian in general that you want advice on. We are one of the bodies you can go to if you want advice, how you want to handle that technical problem. So in short, the Debian Technical Committee is a self-nominated and DPL-appointed last resort conflict resolution and advice-providing body. It's very beautiful. We'll come back to the self-nominated and DPL-appointed points later. It's been a tradition of the Technical Committee both to review the issues we've had since the previous Debian Conf. So if you want to see the previous issues, you have to go watch last year's buff. But for this year, so we've went through the issues that we have had in front of the Technical Committee since the last Debian Conf. And actually, when I wrote the slides initially, I thought, oh, we only had two or three issues. Actually, it was not exactly the case. We've had six membership bugs, so to say. We track all the decisions we take through bug reports. So we've had three new members in the persons of Marga, then Bremner, then Nico. Congratulations. And we have decided as internal procedure that every time the membership changes, so whenever someone leaves or when someone joins, we have another vote to decide on the TC chair. The Constitution doesn't require us to do that, but we do it as a matter of not having to ask for a vote for the chair. And so far, I've had the honor to be elected every time as chair. So that means I'm preparing the slides. We've categorized the decisions we have had in our hands in two categories. The first one is the issues we have actually decided. So it's three issues in which we actually have a vote, had a vote on it, and we have closed the issue after a formal resolution. There was, should the TC help with a project roadmap, to which we have answered that we are ready to help to break ties, but we don't really want as a TC to be the body doing a project roadmap directly. I don't know if any of you guys wanna comment on that, or I just go on and you interrupt us, me. There was the blends task must not be priority important. That was conflict within the Debian installer, where if I remember correctly, the task, the priority system was used to make sure blends could be installed through the Debian installer. And we have done some mediation there and recommended that, well, we did a recommendation on how the problem should be handled. It was solved in by other means, but we acted as a recommendation there. And then quite recently, as was already highlighted by the DPL, we had the question of whether we should rename Node.js back to Node, which we managed to take a decision quite quickly saying, well, the namespace is free again, so Node.js might as well be named Node. So we answered, yes. There was actually seven bugs that were closed without a formal resolution, and we just discussed that within the TC and it's quite surprising that we are happy to close issues without formal resolution, where our main constitutionally required way to take decisions is to have actual votes, but there are plenty of cases where it makes sense to not go through an actual vote, where it's obvious that we have consensus, and we don't have to go through the administrative of doing an explicit vote and having a lengthy resolution and wording and all that. So there are these seven bugs. We closed them without having to take a vote. So we had two about browser-ified JavaScript and the DFSG2, so the first bug, we clarified the responsibilities and bounced that back to the FTP master and did that again a second time. There was a police clarify that CSV and a support decision is not going to expire. We refused to rule on that, saying, yeah, what I just said, we refused to decide on that. We had a longer one overruling the maintainer of the global package to package a new upstream version in time for stretch, and the result of that discussion was that the maintainer of the global package orphans the package, so the problem disappeared so that the package became free for adoption for someone else to actually do the packaging of the new upstream version. We had to decide on the proper solution for the binutils-mips bug. Actually, it was a bug in binutils where, if I remember correctly, the new version was creating failure to build from source for some MIPS packages. So we did some mediation there and the solution was found without us having to vote. We had another request to clarify that the USR bin foo should not be hard-coded. Even in upstream parts, we had a quick discussion and also declined to rule in that case. And then the browser-ified JavaScript issue came back in another form. The question of supporting configuration file changes between the versions in unstable and testing and it was obvious for us that the issue didn't need a resolution from us because it was consensual enough within the project that we didn't have to rule. Any questions remark so far? Is it boring? I'll just go on then. And actually we have one currently open issue that is advice on dealing with grub upgrade failure caused by InitSelect. It's a question by Colin Watson about how to handle configuration files of abandoned packages or of disappearing packages because if you don't purge a package, some configuration files can stay on the system but they can be hurtful for other packages. So there was a question whether it's okay in terms of policy for grub to take over a configuration file from another package that has disappeared from the archive. And we have consensus that it's okay to do it and that's not hurting, it's not against policy but we still need to actually close the bug saying that. We have consensus that it's okay in this case, yes. Thank you. I'd also like to really thank Colin for what a nice bug that was and how well presented it was. And every option was laid out. If you wanna get a quick decision from us, if you do something like that, it'll go much better than if you start shouting at the start. 865929, I hope it's correct. You can always go to bugs.debender.com. He deserves a round of applause for that actually, it was really good. You can always go to the technical committee bug report page where you see all the current bugs in case. So that was for the current issues we have. Another subject we wanna talk about is that we are often looking for new members. That is in the constitution now since four years, I think we have the term expiry in the six to seven point. I'll just read that out loud. So on January 1st of each year, the term of any committee member who has served more than 42 months and who is one of the two most senior members is set to expire on December 31st of that year. You actually need to read that multiple times and write the formulas down to actually understand what it means. So I did the calculus for you. What it means is that Keith's term will expire at the end of this year. But it's the only term that will expire. We only have one person who leaves. But next year there are three terms. So my term, Tollef's term and Sam's term that expire at the end of 2018. But only the two first ones will expire because we expire at most two per year. And so these are the dates of the expiration. We also noticed that if Tollef or myself resigns during 2018, we force Sam to expire as well. It's not a loophole, but it was just funny to discover. So we need fresh blood. Thank you for the evil laugh. That means we're looking for at least one new member per year. So we are still on the, so this year we will need one, but next year we'll need two. And the regular rhythm is that we need two new persons per year, actually. And not all issues are like 727708. Who knows what that bug is? System D, yes. It's actually a bug tracker low tester. I think it's still the longest bug ever. With something like 7,000 males, something like that. So don't go and read it, it's way too long. So we wanna quickly talk about what actually our work, what the TC work is about, because we wanna find new members, at least one before the end of this year, ideally. So our work is often more social than technical. It's also about disagreements and conflicts by construction. I mean, that's what we do is like solving conflicts. It's at the broad technical level, so you don't have to be a C expert. I'm definitely not, but you have to be able to have a wider view on how Debian works and how the different things interact with each other and have a good understanding of what Debian is. It's about listening to what people have to say. So the name is technical committee, but actually it's often about what the people are doing and what their opinions are about the technical problems. It's also sometimes taking hard decisions. As was outlined before, we can override developers. It's not a fun thing to do, but if we have to do it, then we'll do it. And all in all, it's essentially political. So in Debian terms, of course, we're not talking about the wider society problems, but it's still how people interact with each other, how they collaborate as humans and all that. And the required skill sets to come in the technical committee, you don't have to tick all the boxes, but that kind of gives you an idea of what types of people we're looking for. So you need to have some empathy, technical agility, so the ability to dive in a technical area that you don't necessarily know, but be able to get an understanding of that problem, some sense of mentorship, ideally some responsiveness, so that we don't let the bugs die in limbo because no one has time to answer or even read the mails that are sent to the technical committee, some social sensitivity, and ideally you should be cool-headed because the issues can flame up slightly, so it's good if you can take a step back and take a look at the wider view and approach the problems with a cool-head. One important point is that we need more diversity. We're all white, we have one woman, and a lot of us are native English speakers, I'm not, but we're still, it's 50-50 for now, which is not the best situation to be in, so we definitely need more diversity. Yeah? One of the things we also, as we were discussing this earlier, we have a lack of diversity, and I think we're all closer to older school programmers in a certain way. I think, as it was pointed out, there's perhaps over-representation of Emax Bliss on the technical committee, is composed to say the latest in GUI IDs and graphical design environments for code. We probably write, make files more than we drag and drop build systems. And actually that's not a good thing, just to, I mean, to follow up on, to follow, I mean, okay, we all have a certain mojizmo, I guess, but to follow up on DDA's point, you don't have to be an old school programmer to be on the technical committee. Well, just to resolve the Node.js issue, it would have been lovely if we'd had somebody on the TC who'd actually ever programmed in Node.js. For instance. So I'm teaching it in September, so. So you'll start programming it in October. And so we need diversity, but we also need nominees. And the current process is that you should write to the technical committee, private alias, or any of us saying, I think this person would be good, or saying, I think I'm a good person. Because we also want to pick from a set of good candidates. And if the set is too small, then it's really hard for us to just blankly, blank, accept whoever is the poor soul that got nominated. There's a question at the back of the room. I don't know if we have microphones. How big was the set? Do we want to say that? Five was better abouts. So the question was how big was the set, and the answer is about five. My understanding is that we've decided, over at least on this side of the room, that we need a better nominations process. And Keith's leaving, and I tried to convince Keith to handle this, but he wasn't willing to do that. So, kind of in the wedding bouquet style, I have this ball here, and I'm going to throw it out into the audience. And you should consider yourself empowered to optionally give us a nomination and pass the ball along. I actually suspected that might happen. And I think that shows it is a little bit challenging to fill the TC spot. We are already nominated. The trouble is, of course, that this is not at all diverse because you all came to DebConf. And so you know loads of people that come to DebConf, and they're much more likely to get nominated and all that. I did do a thing where I was randomly selecting people and sending them emails doing this in the previous round. And it didn't really bear fruit, but it would be really nice if people could come up with nominations because there's this thing about groups of people knowing more people that know lots of people than... So, the idea was that if you select someone from the community at random, they will know someone that's quite representative of them who knows lots of people, which is quite a good sort of mix for the technical committee. But for the record, the ball eventually did hit Docko, and that was the final target. Now he has to nominate some. So, Phil, I am very confused. I thought your random thing was the best enhancements in the nomination process ever, I thought. Like, I think it actually did substantially influence the process in good ways. Okay, cool. I was obviously expecting much more, and it did something. So, I can carry on running that. I did it in a way that it uses publicly-available data and runs it through a crypto thing to generate the list so you can check whether I'm cheating. And, yeah. So, it's not just me picking people that I like to nominate people. Okay. So, is the first... Is this our... Yes, yes, yes. I'm going to turn it on, or is it... Can you hear? Yes, no? Okay. So, as the first person who ever termed limited out after that resolution was in, you can certainly take everything I have to say with suitable quantities of salt. But I'm actually... I actually get really concerned when I hear people talking about diversity without having some sort of really specific set of objectives or some specific problem they're trying to solve. I, too, would love to make sure that the technical committee remains or becomes even more sort of a representative swath of the project. But I get worried if you start worrying about gender or skin color or make files over drag and drop because while those are all good indications of whether they're markers for whether it's diverse enough, that none of them are actually sort of the point. So, don't beat yourselves up too much. And if somebody really great is available and wants to contribute and would have something to add, don't be too hung up about it if they happen to be old and white or something. And no, no, no, please don't look at me. I wouldn't be concerned about us being hung up about that. I mean, of course, people have to be competent and good people regardless of their sex or their skin color or whatever. But if we can increase the diversity, then there is absolutely value in that. And there is an important point about self-selecting. So we have an inherent bias in the process that as a body, we select other people to join us. So we're more likely to select people that are like us. So we need input from people not like us if we want them to be considered. At least for me, I think it's more interesting to encourage people to apply without a fixed set of prerequisites. I think that's what I want to push, rather than saying, oh my God, we have to find a random Node.js developer and get them on the technical committee by the end of the day. Well, apparently we did that already, because here I am, but I'm pretty random, so. So another point we wanted to get across also is that we are, but I think we told that already, we're normal. We're just developers, so come talk to us if you have worries, questions, or else. I mean, we are not like, I think I talked to someone the other day and he was like, oh, but I'm not in the same high spheres as you are. We're not in the high spheres at all, we're just developers with a duty to solve complicated technical problems or social problems and it's not a high sphere at all. So come to us, we're normal. Oh, yeah. Hello, can you hear? What are the lifestyle impacts of being in the technical committee? What was that? Not all issues are like system D. What's my? No, but it's a fair question. Yes. It's very spiky because we don't get, it's not like a regular thing that you have to do the same amount of work every day, every week, every month. Like suddenly we get a bug report that is super hot and in three days we get a hundred emails, right? And you need to be able to read those hundred emails in those three days or you're left behind. But then nothing happens for two months. So it's not something that you can like plan to spend a certain amount of energy every day. You just need to like have a window where you will do that work. And it's also quite heavies and maybe not a good word, but it triggers a lot of reflections and it's writing the email at the end of the reflection is the easy part, but you spend a lot of time thinking about what you will write and how you will write also because the process is public. So it's, and by definition, all the issues that come to the TC come at a point where it's often late. So there's a lot of untangling to do to actually understand the problem and understand the issues at stake. So it's quite some energy, but it's also rewarding in the sense that we help fix some problems, I think. Thankfully. If there are no other questions, we'll just finish the slides so that we can get to the bar after that. So we're also looking into ways to improve the process, the recruiting process, as well as our general bug handling process. But I don't remember exactly where I had that slide, so I'll just go to the next one. So our current discussions that are not bug specific, we actually just had this one the hour before is how quick we can be and we were actually surprised both ways. For some issues, we thought the system D, for example, we thought, oh, that took a year. Actually, it only took six months. And for other issues, we thought, oh, that took multiple months and actually it took only one. So we have a weird understanding of how long we take to actually decide and actually we are faster than we thought on multiple ones. So we became better and yeah, but I'll let Sam enhance. Sorry, are you done with your comments? Yes. But I think an important thing to understand is that typically it takes for, the, you should not be surprised if it takes the TC multiple months to respond to an issue. If, excuse me, to resolve an issue, to get all the way through. That said, if that timeline doesn't work for you, be honest about what your needs are at the beginning and we'll see what's possible. Sometimes it has been possible. I think that the shortest we produce a resolution in is five days from bug to a formal resolved resolution. But that's a case where the project really needed it and where it happened that it was easy for the TC to get an internal consensus. Normally it's going to take longer than that, but you may be able to get some idea earlier in the process to help you start to move in a direction. As mentioned earlier there as well, it really helps if you have actually your, whatever the problem is written up well, rather than pointing us at bug report, spanning, you know, three months with people being upset and personal attacks and all the bad things we sometimes see in Debian. Yeah, if you want to get a nice hearing from me, then really don't say someone already addressed that point in the thread. If you want to say that, then say here, and here I quoted again so you don't have to go and look for it, saying, oh, I already addressed that. You just went down about three points in my estimation if you say that, really pisses me off. Because I'm dyslexic, so it takes me four times as long to read this stuff as anybody else, so yeah. I told myself I wasn't gonna ask a question at this one. We see how well that held up. I was wondering about, to get a little bit back to a person's question over here in the corner and to link it with the subjective perception of time to resolution that you guys have, I'm wondering if it isn't, if when you look back on something and think, oh, the in-it situation took a year to resolve and this other one that we thought took two months took one, if that might not be more of a measure of your level of comfort with the issue. I wasn't around for the system D in-it wars, but I watched them from the pages of LWN and I read a lot of the deliberations on the subject, which is how Russ Albury came to my attention as a pretty kick-ass dude. So do you think that's the case? And secondly is, you talked about diversity, I'm trying to tie a bunch of things together here, is a person who kind of wants to be on the technical committee, don't they have to be the kind of person who's prepared to deal with spiky, high stress episodes like that. And that's one area where you can't diversify into people who want a predictable workload. Just some thoughts there, tell me if I'm wrong, probably am. I'm happy to repeat my previous answer to piss Phil off. No, I mean, I think the thing, again, the thing about diversity is to lower barriers. To lower perceptual barriers. I think anybody who's been around Debian for a year or more, probably you won't be on the TC in your first year, but you never know, knows that there will be stress or at least you know that there will be emotional issues that come before, people are invested in these things, they don't get to the TC if people aren't invested in them. So I don't really see that as a diversity issue. I mean, I guess we're not looking for, we're not looking to expand our complement of thin-skinned people, right? I guess maybe I don't understand your question. May I missing something? I think what I understand of your question is that this spiky workload that is associated with a lot of stress when the spike comes might deter some people, and then we get a profile of a person that is willing to put up with spiky stress. But I mean, that's kind of all over Debian, right? We have people in key positions because they're the ones who can do them and not go burn out right away. So I don't know, it's not unique. I think that's not unique to the TC. You're right, but I think it's not unique to the TC. I think a lot of moderately high visibility positions within Debian have this feature. Hi, Sean. New policy editor. So on a hopefully somewhat less spiky sort of thing, but speaking of policy, so one of the things I used to want to do when I was on the TC was to try to use the technical committee as a mechanism for resolving some of the things that are longstanding in Debian where they actually aren't all that hot, like nobody's really super excited about them, but the project would be better off if we would actually make a decision because we're in some limbo land and we just sit there for forever. A bunch of those tend to land in the policy BTFs where we will never probably get consensus on a particular resolution because there are people who really would like it to work either way, but the project as a whole would probably be better off if we just made a decision. Now I just kind of wanted to get your take on what you feel about us starting to forward more of those to the technical committee. A great example, and I'm just gonna give it as an example and ask the room to not start talking about it because it's one of those things that will erupt into a conversation is that longstanding question in Debian is if you upgrade a package and the init script fails to start the demon, do you abort the package installation or not? And there's lots of arguments on both sides of this and some packages do one and some packages do the other. That seems like the kind of thing and there's a policy, open policy bug. What would you all think of us forwarding those kinds of things on to the technical committee? Well that is one of our constitutional roles is to offer advice. So if you want advice in that issue, absolutely. Come and ask us for advice and we'll come up with, we either say we have no idea or this is our opinion as a body and as kind of a set of developers who might have an alternate view that certainly something we're constitutionally empowered to do and we'd certainly encourage that. Actually we're in that case even constitutionally empowered to make a decision. I think I would be delighted if you forwarded stuff like that. I would be delighted if the technical committee got more things that were, hey we'd like you to ask you to do this rather than we've already gotten to a point where we're snapping each other's throats and I think this is a case where that could happen. That said, you shouldn't be surprised if sometimes you get back rather than a decision, you get back advice more than a decision. You shouldn't be surprised if sometimes you get back, we don't think that you can set policy here, the best you can do is to describe the trade-offs and that it will be a lot easier for us if you take the time to write a good report of it rather than sending us at a 10-year policy threat. Hi. So I wasn't planning to ask a question but apparently it looked like I had my hand up so I know I've got the mic but actually as it happens I was sort of thinking about something. So over the past couple of weeks I've been thinking about things like, are you guys familiar with things like snaps and flap-hacks and that kind of thing? So I was thinking about, and this was prompted by, thank you for sitting around, Cosmo. Cosmo, I saw earlier today, whether and how much we could possibly push this kind of stuff into Debian. Now this question can probably go as deep as you want it to go, right? This is, it ranges from like, can we generate these things from our Debs and distribute them to users, which is possibly like the shallowest end of it to, can we provide our users access to upstreams, built stores by default, right? Now you're frowning, but what I want, the TC related thing that I want to ask you is, one, it feels like this is something that if somebody tried to start pushing on this it would end up at the TC eventually. Would you want to offer advice on this? And number two, given the, I forgot exactly who it was, you raised a point about possibly there being a lack of like technical kind of diversity. You're coming from one sort of school of thought. Do you think that the TC would actually be qualified to even like give these issues proper consideration given that maybe you haven't, I mean, you're not sort of coming from that world, you might be coming from an old school Debian based distro-y kind of traditional world. Like, you know, do you have some, I don't want to start this discussion now necessarily, but do you have some thoughts about whether the TC would be able to handle this well or not? I'm sure we're not ready to make a decision there. I didn't even have a proposal to make, I was just thinking about. No, no, but I mean, my point is, this is an area where if you were to ask the TC, can you evaluate, can you help us evaluate the technical trade-offs and come up with a deliverable that would look more like, here are some discussions of trade-offs. To spark some informed discussion, you would get a lot further than if you said, can you set policy for flat-packs? I think that there probably is expert, like I doubt I'm the only one who's, I haven't dealt with flat-packs, but I've dealt with many of the issues underlying that in commercial contexts. I suspect there are other people in the TC who've dealt with lots of different software delivery mechanisms. I think if you could get the right people together for a discussion, having some TC members involved in that discussion and producing a good discussion of the trade-offs for Debian would be a wonderful thing for the project. I think that's also quite an important point is that this discussion needs to happen at the project's wide level as well. And probably as prerequisite, because deciding whether we enable external repositories or not is also something we need to decide as a project and we kind of have to find a consensus there before directly going to the TC to actually take, to actually rule that. That's fine, we do that all the time. Right, so I actually think that having the TC or somebody get the technical trade-offs together and feeding that into the broader project discussion might derail a lot of flaming. Like, I think that we're actually pretty close to being ready to have the discussion of so what are the trade-offs for enabling, for enabling build stores by default, right? And I think that we could write up those trade-offs as an input to the project-wide discussion. And I think that that might diffuse some other things that might be pretty awful if they didn't have a good set of technical trade-offs as one of their inputs. So I think maybe a way to do this is to approach the TC to sort of shepherd the discussion in the wider project, because it's gonna be really hard to formulate a complete proposal and then approach the TC and then because it possibly involves so many, like touching the competencies of the FTP team, the release team, all of the teams, right? So no, I don't know that the TC is necessarily going to be the best to shepherd a proposal. You think we should move? I think the TC would be good, again, at discussing the technical trade-offs, right? That's what we do as we look at, if you look through the system debug, for example, you will find that several people wrote some really eloquent discussions of the trade-offs. If nothing else, that was a great deliverable. I bet we could do something in a situation like this. I think that that would be a lot more feasible than asking us to shepherd the discussion or at this time asking us to rule on a policy. But again, that's my opinion. I just want to expand on what Russ said about policy team passing bugs to you guys. This process that we have in policy to get consensus, as Russ said at the BOF yesterday, if a couple of people disagree and are not persuaded, then that process just stops. So I think, and this is often the case for these long-running bugs where it's not urgent, but Debian will benefit from it being solved, which is how Russ put it. If we were to pass that up to the TC and the response was, if you took this as us asking for your advice, then that wouldn't actually unblock the situation because, as I say, the process just stops if there's no consensus. If you were to say to us, okay, that's not documentable, just write about the pros and cons, that's fine. But taking it as offering advice when it's come from policy team, because we think we're not gonna get consensus, doesn't help that much and probably isn't a great use of your time, I would say. So if the policy consensus process stalls, doesn't that fit the model of all the right processes having being followed before it, does anybody in the audience know what that means? Okay, moving on then. Okay, so does anybody disagree that that would be a valid, I mean, I'm not saying, okay, it's hard to say, but it seems like it could be valid TC bugs. Yeah, for an actual decision. Right, if you guys say our process, we tried the consensus thing and it didn't work out, then that seems like valid to ask for an actual decision. As much as I hate to make work for us, but in any case, it's something we should probably try and see if we succeed or fail. So you can try one or two and if the result is not satisfactory, we should have a discussion again. Hi, talking more about the process of taking a decision, most of the, I heard this, you communicate by email, are you using like more or considering using some more real-time and closer communications in particular problems, like going all the way from IRC chats to phone calls or maybe organizing in-life meetings for a particularly bad problem because we all know that sometimes some problems can be best solved only by getting the people that disagree into one room and then have somebody moderate the discussion I wanted to say, but yes. So we have a constitutional limit for that, our meetings have to be public and so the only credible way for us to do a public meeting is email or IRC. Or video streaming, yeah, one can imagine that, but that requires in-person stuff. So like teleconferences, I've tried to do public meetings via teleconferences. It's very difficult to get a reasonable transcript from that. It's very difficult to let an arbitrary number of people come and listen in. Whereas with email and IRC you have this ability for the entire community to watch and I think that's a really powerful part of the constitution here and I wanna make sure we respect that as literally as we can. It's like I wanna make sure that anybody who wants to watch the TC can come in and watch. They don't have to have a cell phone or a phone plan that can dial into a European number. They don't have to have magic enough bandwidth on a network to be able to watch a live video stream. There's a lot of constraints on, that puts a lot of constraints on us and it does mean that we are somewhat constrained. But I think IRC in particular is a pretty powerful tool for us. It makes it easier for people not using the native, who aren't using the same language, aren't native in the same language as being used to read and understand and reply because it gives that not quite real time behavior so you can Google translate whatever parts you're confused about. It makes the record exact, right? There are no side conversations in IRC, we don't do that. So whatever's in the IRC channel is exactly the conversation that occurred. I think that's really powerful. But we like to meet here but we don't do any decisions because we can't all, trying to get a physical meeting of eight people together is very difficult and a physical meeting of seven people with one person remote, then all of a sudden you have an unbalanced meeting and that person's views won't be presented as accurately. So I think we've made a pretty good balance with IRC. I'm reasonably happy with that. Does anybody think that we need a different mechanism? We can choose a different messaging system but text messages seems like, I mean my children communicate solely by text messages. Surely the TC can respond, can respect what the modern children have figured out. Well, there's one thing about the constitution. We still have the right to handle some parts of the discussions in private and we do that for some issues because it's just impossible to discuss some specific person-to-person relationship problems in public. And I think it was a GR some two, three years ago about that so that we're explicitly allowed to do some things in private. We try to not use it too much. That's also why here if you see us having a discussion at DEBCONF, we don't hide in the room, we go in the cafeteria and if you wanna sit down and listen to what we say or even interact with us, please do. And it's the same for the IRC meetings. We have it monthly. I think it's the third Thursday every month on IRC, the Dependent Org. You can come, well Wednesday, it's in the agenda. The day is secret for the meeting. Exactly. But I don't think we ever explicitly said but it's fine to also interact in the IRC meeting. So and if it's too noisy for us we will say but if you have something to say in an IRC meeting just come and say it. Well and in fact at our meeting just before we met here we had a couple of people come and sit down and watch and I appreciate that. Oversight in any legislative or judicial process is really valuable. So come in and talk to us and tell us when we're doing something stupid because we're only eight people, we're just eight little DDs trying to fix some big problems and if you have input to help us, that's great. Yes. Oh and we're out of time. Now we get to go drinking, right? Sorry, are we really out of time? Sorry.