 Okay it's time so I guess we can start. Next topic is meet the technical committee that will provide you an opportunity to meet the members of the Debian technical committee that are present at debconf. Here the status of the open issues before the committee and ask questions about how the committee works, operates and if you have questions. Go ahead. Now is it turned on? Okay this is intended to be you know more buff and less talk. Certainly we want this to be very interactive. I grabbed the same short set of slides that we used for this last year in Banyaluka and updated them appropriately and so we have very short set of things just to provide a little bit of context and to get things started and then I firmly expect us to transition very quickly into discussion and we'll see how things go from there. So to start with there are eight members of the Debian technical committee. On this list I have coded them with italics if they're not here. So as you can see there are four members or half of the technical committee present. I'm B. Dale Garby. I serve as the chairman, nominal chairman of the committee. We have Don Armstrong and Ian Jackson and Steve Lancashack are also here and the other four members as I mentioned are not able to be here at DEBCONF but that's who we are. The Debian technical committee can exists because of authority that is defined within the Debian Constitution. I won't go through all the details here because as I said this is just the same as what we used last year. For those of you who are not present in Bonn you look at DEBCONF last year if you have any questions about the boundaries of the technical committee's responsibilities and authority that's certainly an excellent thing for us to take as questions and to talk about here after we get through this little bit of introductory stuff. In the past the technical committee has operated almost entirely through bugs being reassigned to the technical committee's pseudo project or pseudo package and email but recently at the suggestion of Zach we tried something a little new and a little different of having a live meeting on IRC and a majority of the members of the committee were able to participate and it was actually fairly productive so we've had two of these meetings now and I think going forward at least for a while we will try to do these on something like a monthly basis and if it turns out that's too frequently maybe we'll back off at some point but for now we're trying to do that and if you're interested in joining in and watching those discussions you're certainly welcome to do so and if you watch the committee's mailing list that's probably the best way to see when they're happening and be reminded of them. So for the exciting part the good the bad and the ugly on the positive side there are fewer open bugs before the tech committee this year than there were last year and of the three that I've mentioned here the first one is actually in the process of being voted right now we had a call for votes I think was it yesterday Steve on the node versus Node.js and we're in the middle of voting on that and so hopefully by the time we conclude here at Dubconf we will have heard from enough folks to know what the outcome of that is. The second bug that's open against the committee right now for our shame I did not have to edit from last year's slides we'll talk about that and then the final one is actually in some sense not a very big deal except to us but there is an issue a fence post issue in the Constitution right now around the definition of super majority for votes that the technical committee is taking and Ian is working right now on exactly what the right text should be for changing that and that has led us to an interesting sort of sequence of discussions around the process by which the technical committee might propose and run general resolutions this has been part of the authority that the technical committee has under the Constitution for a long time but to the best of my knowledge we've never actually exercised this before so it's led us an interesting conversation so with that this is really sort of all I had in the way of providing context and it's now time for us to talk about things because I suspect that at least some of the comfort conversation will pertain to them I'll put the list of open issues before the committee back up and maybe before I completely open up to questions I should offer my three colleagues here the opportunity to each say a word or three about the committee and what we're currently doing anything like that if you'd like to so Don I don't have anything in particular to say just the the meetings on RC we've been having the logs are present and in the future we'll have the meatbot running we actually had it at the last meeting but I forgot to run the command to invoke the logs so hopefully from now on they'll be there I've published logs out of my own chat clients so hopefully they're they're acceptable but we'll of course continue to try and do that yeah the RC meetings are working really well I think based on what's happened so far I can say that with much better probability if you now reassign a bug to the technical committee something might happen about it which would be quite a radical departure and so I'd encourage people to give that a go yeah so I guess I would say I think the one-month frequency is about right for the meetings I think that that has worked well a one-month interval is about the right amount of time for me to procrastinate my action items from the previous meeting and then get around to having a little bit of time and maybe working on them so that that's about the right nag frequency I think for the for an ongoing basis for the committee so I'm trying to think of a question okay so so you have the second one on there and Python package maintain a ship traditionally the tech committee has been very reluctant to decide on essentially between who should be a package maintainer when essentially two people are are in conflict is is there any particular reason for that and do you think it's something that the tech committee should be ruling on I mean from some point of view we are extremely reluctant because all decisions are bad I mean if there's generally there's a problem otherwise we wouldn't be being asked about it and at some level and not even speaking about this example but if you ask somebody to go away then you've specifically attacked them as an individual so and sometimes to the choices for alternative alternative maintainers or your alternatives are perhaps untested or maybe intractable as well and then you've got the added issue that it's a social problem in a entirely volunteer organization where you can't pay someone money to do a job or fire them you're operating at their sufferance and their volunteer time so I mean I think that's some of the reluctance but let's see what else yeah I mean one problem I mean we've got a number of problems on this particular question one is that it's just a very difficult thing to do for the reasons that Don has mentioned but the technical committee has had difficulty with this in the past we have historically been extremely reluctant to overall maintainers at all this is something that I'm not so happy with but my colleagues seem to feel differently about this to me so well you know I get to be outvoted to but there are other reasons people don't tend to bring issues to us until they've got really frustrated with them and by the time you've got really frustrated the bad blood and the flame wards are just really impossible and often you end up with a situation where nobody nobody who fancies having a good time and doesn't want to get involved in a huge argument will really step up and say well I'd like to help out with this package that seems to have some problem and also we've had there's the constitutional rule that we're not allowed to have private conversations and in practice what happens most recently is people have been emailing us privately to ask our opinion by you know picking out the email addresses of the members and just putting them in a to field and this is a bit irregular it's worked a lot better than you might expect because we can kind of you know people can ask us a question without having to kind of publicly come out and make a big deal of it and then we can say well actually maybe this would be a more constructive way forward or whatever and it doesn't necessarily have to become a huge row this is something I like to see us do more of I'm not sure my colleagues want to be quite as interventionist as I do I think it would be useful for us to try out a mediation role one of the reasons for that is that we would be able to directly experience how a maintainer who was being criticized actually dealt with interactions with us and then this would give us some information about you know did we think that the complainant was more right than the maintainer or what have you also it depends of course on who we might have as alternatives I think that's all I had to say about that so I don't know that in my own case I've ever felt particularly reluctant to overrule people or even to sort of make choices the problem is that the right answers are often just not very clear and so one of the things that I think is going to be very interesting about some of what Ian's trying to propose about sort of the possibility of a constitutional amendment to enable explicit sort of private conversations between developers and the tech committee is that it creates the sort of intermediate third state between a public discussion that's archived because it's on the committee's mailing list or associated with bug reports that have been assigned to the committee and what has always happened and will continue to happen of people choosing to reach out individually and privately to members of the committee or find you at dinner at Deb conf and have a conversation you know ask your opinion on something or whatever put us in this interesting sort of situation of having this in between state where you're publicly acknowledging that you're having a private conversation and I haven't really quite completely wrap my brain yet around how that's actually going to make a practical difference in the way we as humans choose to interact with each other but it at least provides some constitutional air cover if you will for the notion that it's okay for us to be you know trying to resolve conflict without necessarily doing it all in public with everybody's dirty laundry visible all the time for all the reasons so going back to Neil's specific question I think you did ask about the particular issue of making decisions about who should be the maintainer of a package if actually if I look back at the the history of the technical committee I can think of very few occasions where that particular question has been put to us and so to a certain degree I think we are perhaps inexperienced at actually resolving such questions because this is not the sort of question that generally gets referred to the technical committee partly because people who are actually having a dispute over who should maintain a package to the point where they would try to get something like you know changed are they generally have fire in their bellies about it and are looking for a quick resolution and the technical committee does does not generally provide quick solutions and so there many people will in fact they'll choose one of several suboptimal socially suboptimal solutions which may be that they will decide to just give up and go away even though they think there's a problem or they will try to browbeat the other person into giving up so they can take over the package or they will you know this sort of thing as and I do see scenarios where there are disputes among members of the community over who should maintain a package which do get resolved by this sort of thing they have very rarely actually been referred to the technical committee I think it would be well I'm not sure if I think it would actually be healthier to have more of those refer to the technical committee because they are twisty issues they always are and I don't know if the technical committee actually can do a better job you know keeping our keeping keeping people civil about it then then the status quo as far as our problem-solving processes there but I do think that you know this is this has been an exceptional case and I think we finally actually reached some sort of a consensus which just now has to get written up and voted on but it's been a long time coming and you know Ian your point about private conversations as well I think is is I think that's also been a key one for us because especially when you're talking about who who should maintain a package that winds up often being as much about non-technical social communication interpersonal issues whatever it might be as it does about actual technical things you can point at saying that the package has been badly maintained and that makes it you know that much harder to actually sort out and untangle I more a comment than a question what you're saying about changing the constitution to acknowledge something that's already happening might not per se solve anything except for aligning the law with what is already going on which is always important because if you let the formal rules diverge too much from customer you know practice then they become irrelevant that's that's a very good point there's also the fact that at the moment you know when when these kind of conversation take place there's a certain amount of guilt going on and there's you know it's not an advertised thing we don't have an email address like a roll address that you can email to say you know I'm having a bit of difficulty here can you help etc and so I think we're failing we have an opportunity to help people resolve their disputes before they get to a really bad stage which at the moment we're missing because there's really nobody in the project that you can go to who will help you out with that who also then will have the ability to make a decision stick at the end of it and technical me he does in principle have the ability to make its decision stick at the end if you you know if you ask the technical committee for help and the technical committee actually agrees with you in principle they have the power to sort it out but at the moment you can't really go to the technical the only way you can do it is by filing one of these you know huge character assassination bugs and that's not yeah that does not lead to good outcomes and I would like us to formally say we would like to try to resolve these things in a way that that fits better with the way that social monkeys work and that's not to say that we won't you know when it comes down to we won't make all the decisions in public and if we're having technical discussions about some bug or other that that won't happen in public as well that that kind of stuff absolutely fine but when we're saying you know I'm having some difficulty talking to this maintainer can you please try and help me persuade them or you know we don't seem to be getting on that's the kind of thing that you really can't do in public you have to do it in private because then it's not a criticism it's just like will you give me a helping hand and hopefully we'll be able to maybe resolve some of these clashes before they get to unpleasantness and and I completely agree with all that and I think it's all good and I think the point in particular of the notion that you might have some well defined place to go for some mediation help that actually has some authority behind it in the end if needed is really great the flip side of that to me is that everybody who knows me at all knows that I've been around this project a long time I've had the privilege of being asked questions by everyone who's ever been the Debian project leader all the way back to In Murdoch I've had the you know the privilege or the frustration or the angst or whatever of being approached by people a lot of times over the years who wanted help understanding why somebody was attacking them or you know hated what they did or you know there's this sort of there's this role you know you were mentioning the Council of Elders thing in a different context yesterday I certainly am aware of the fact that there's this important role that people have been around for a while and have some sense of context for sort of what's important and what's not in this project in order for it to you know be successful in the long term that there's a role to be played which I don't mind having be part of what I do which is to just try to be helpful and in particular to try to help people understand how to get things done when they're frustrated and to me I hope that nobody ever sort of feels that they absolutely have to have you know some sort of good housekeeping stamp of approval on them as is having some special role in order to be willing to turn to the person next to them and answer a question or to to to invite somebody to say hey you know if you're not happy and and and working for Demian's not making your life better then let me help you figure out why and help you fix it because that's the thing that people who care about each other and are working together collaboratively in the kind of community that we are can and should and ought to do for each other and I see it happen all the time I see lots of people sort of going off to have a conversation and coming back feeling better about the world and I hope that we all sort of take some personal ownership and responsibility for making sure that happens independently of whether we successfully go through the process of making it more obvious that you can come to the tech committee for mediation help independently of you know asking for some specific decision on a specific bug that gets reassigned to us and so I hope that all makes sense but it's not that I'm negative about the formalism or that I'm reticent to make decisions or anything like that I just put a huge emphasis on the value of the informal kinds of interactions that we can have as a way of trying to deal with most of the things that otherwise end up you know requiring some kind of a frustratingly complex unhappy for somebody formal vote so Russ Albury's comment on RC is that he agrees with Ian that we don't manage to head off these questions soon enough but he's worried about whether we have the resources to manage to do a lot of mediation and that leads to a question from possibly a question from Ben Hutchins which is that are there any plans to appoint new members right so the question of resources I think is one that we will have to we'll have to cross that bridge I think that the right way to deal with that would be to try to bid and see if it works well and if we get all horribly overloaded then you know we'll have to do something else in terms of adding new members well we are at our maximum size of eight you can't see that on the slide anymore but there are there's a you know there are perhaps at least one person on the committee who hasn't been seen in some time we might persuade them to step aside or if they don't answer their email we might just say well actually we better to have somebody else it's not that clear that you know of those eight people seven of them are reasonably active I would say and one more or less inactive member is is a survival level if people think that the TC should be bigger then that's certainly something that could be considered we're in the process of writing up a set of constitutional amendment GRs to sort out the supermajority thing to permit us to have private conversations and fix a couple of little bugs yeah yeah renumbering section a dot one to not be the same as number a dot one but it would be certainly be possible for us to increase the maximum size in the constitution it's not clear to everybody whether that's better we might become a more awkward cumbersome kind of organization where you need to persuade more people and you need to have longer conversations and frankly things already taking quite a long time often and not just because we're all busy people and don't always get around to things but also just because when you've got seven or eight people all who who might have an opinion that takes quite a while to build a consensus all to discover that there isn't a consensus I mean sometimes it's really easy when enough of us get together in one place which sometimes happens at dub conference sometimes doesn't or might happen in our IRC meetings we've discovered on some of these things that if enough of us are in the right place we can all kind of go yep and then we move on and you know write a write a something about a resolution to vote on and just move on and so I think the thing that's likely to actually help the most in this regard is having some kind of a regular excuse to is Steve says you know make sure the action items have actually had you know at least five minutes put to him since the last month and and get together and trying to actually work through some of these things and in fact as I mentioned of the three open issues right now Steve did put forward a call for votes on one of the ones that he took as an action item at one of our meetings and that one hopefully will be resolved here in the next week or so and of the other two one the third one which has to do with the supermajority thing there's quite a bit of discussion going on in the last day or so on our list about exactly what the wording of the amended constitution ought to be so that we don't sort of create yet another funny potential offense posting situation in the future and that's all great we'll talk through that and our heads will all explode and once we get all the pieces pulled back together we'll figure out exactly what text we want and we'll put that out and you'll probably all get to vote on a GR here at some point so those are all sort of making progress I actually you know other than the fact that it embarrassed me when I realized that the the Python maintainership bug I really didn't have to edit it from my slide from last year other than the embarrassment over that it feels to me like things are actually going okay and we could actually handle more inquiries more requests for decisions if there are some I'm completely happy to live in a world where the technical committee is boring because we don't have much to do because Debian developers are taking responsibility for the work they do and are collaborating and arguing and working through their differences with people sitting next to them and don't need us that would just be brilliant right I agree with what B Dale has just said but I don't think actually that the world is that good a place we're all pretty nice people as by and large but any organization as big as Debian with as many bugs as Debian house is going to have some you know there are going to be situations where somebody gets it wrong and it's important enough that that needs to be looked at again by somebody and at the moment I don't get the feeling that when particularly as the submitter of a bug you're in this position people consider escalating the bug to the TC for a technical decision and I guess that's probably because people don't think we'll make a decision within any reasonable time frame and historically that's been true but I think recently we've shown that we can do a lot better than that I have another type of question I mean you said okay we have the eight places just basically taken but also most of the issues or some of the issues have nowadays been human instead of technical do you think that the current set of people that are actually in the seats of the technical committee are represent of wide enough diversity in the project I mean just to take an easy example there is not a single woman folks I'm so do we think do you think there is something to be changed in that sense I mean nowadays we also have non-uploading LEDs so I don't know just a question so given some of the responsibilities of the technical committee which are to sort of be a body of expert generalists who can arbitrate on technical issues I think I would find it difficult to say we should have non-uploading DD's in the sense that many of the people who are going through that route are in fact not they're doing so because they're not technically oriented and they don't aren't involved in the same kind of technical they don't have the same technical background that the people on the technical committee do currently so I think I would shy away from saying we should make it make it more representative in that regard also I'm it's interesting that you bring up the question of having a woman on the technical committee because the technical committee is actually currently fairly representative of Debian as a whole and the fact that we don't have any women on it and there are very few women in Debian but diversity though is an interesting it's an interesting thought I hadn't considered that myself before now yeah I think it's it's important to remember that anybody can make arguments before the committee as well and so while it's true that as a body we're not particularly diverse diverse opinions are definitely warranted and accepted and hopefully heated on on the discussions that happen so that was also in the sense that most of them if I know the people correctly or at least the four of here are all English native speakers which is just a fact right that's so the question I mean that that gets on to the wider question of you know English being the language of most of the discourse within Debian and it's very difficult to run an institutional like Debian without having a lot of common language and that tends to lead to a single common language and I think given the role of the technical committee which often involves a very detailed discussion of very technical issues at length ultimately I don't think we're going to get away from people who have a good command of communication in English that doesn't mean that they have to be a native English speaker and I don't think that everybody there to them my nose isn't right okay okay well my first language was Dutch but it's rusty now I can't hardly speak it so don't think that counts and of course Andreas no no the question was can you even function without speaking English on the committee and the answer is no right but I do think there's a valid point that it we do have many fluent English speakers in the community in the community of developing developers who don't have English as their first language and do we in some sense are we failing to take on board not by design but by accident different cultural perspectives that would be more representative of significant segments of our developership by having the composition that we do I think it's a really great question it's exactly the kind of thing that that you know I worry about particularly when we're having conversations around the pool at night with a beer in hand or something but what I can tell you quite genuinely and honestly having been a member of the technical committee now for a number of years and having watched it very closely before that you know all the way back to certainly at least when I was DPL and probably even before that though that gets long enough to go my neurons aren't all that good I can't think of any time in the history of the committee where anyone proposed for invited to and brought on to the committee didn't seem like exactly the right choice from among the body of available developers to help with the kinds of decisions that we anticipated the technical committee would be faced with at that time in other words I can't think of any time where there was ever any sort of intentional biasing of the process and of course all of us who you know read and study and care about diversity issues understand that you know that's exactly the problem sometimes that if you don't consciously try to work on these things nothing ever changes but at the same time given what the original objectives for having a technical committee within the Constitution were I think the the mix of sort of experiences skill sets and representation of different sort of technical working groups within the project over time and if you look at this list we've got people who've been release managers we've got people who've worked on the installer we've got people that worked on tool chains and worked on you know fundamental core infrastructure for the project and who you know worked on the BTS and worked on sort of everything that's kind of fundamentally important to the project in terms of sort of infrastructure and different technical areas graphics various things we've got a reasonably broad swath of representation of all the sort of different technical activities in the project even if it's not gender balanced or racially or culturally or language balanced and so it's one of things where I agree this is something we ought to care about and we ought to think about and when we decide we have an opening and it's time to make some changes in the list I hope that we'll consider that but I don't actually worry about that a whole lot another comment from Russ is that if the the the issue of diversity will maybe come a lot more important and a lot more pertinent if the technical committee starts having to deal with a lot more social issues now there was a proposal a while back to create a social committee which hasn't been progressed do you think that the technical committee should fulfill that role and if not do you think that there should be a so well should there be a body to help mediate the these sort of issues as things like sometimes the package maintenance ship can straddle those lines so in answer to the first half of that question by default the factor or whatever we are the body that sort of left you can talk to the DPL and trying to get advice you can talk to other developers and try and get advice if you're looking for some place to sort of make an authoritative decision right now the tech committee is it so whether we really want that or not it's a role that you know we're sort of stuck with in terms of whether there should be a social committee or not that's a really interesting question we had lots of discussion as you mentioned a while back and unfortunately even to me at that time after thinking about it a lot the answer wasn't really clear and the reason it wasn't really clear is that we think we can do a pretty good job of defining what is or is not a technical question but sort of how you bound what the responsibilities are and how you imbue such a group with meaningful power was never really clear to me. Yeah I mean the technical meeting is not the best constituted body for doing for dealing with those problems but it is the only body that we have in the project that has the authority to do that and so by default we're probably at the moment trying to use it for that and we're not using it in a very good way and maybe we could do better. I would like to see us try doing this in a slightly more structured way and if it goes well then good. Project does need more attention to this problem and there are sort of social problems going on that other moment just sort of rumbled on until eventually somebody gives up. If it doesn't work we do a bad job we trust that everybody will tell us and then you know we'll do something else exactly what that something else will be we'd have to decide then we the project. So I believe we're down to less than 10 minutes of time so I'd actually like to pose a question to the audience here at the moment which is we've talked a lot about what the you know what kinds of things that we think we have or haven't done a good job about and ways that we think we can improve that. I would kind of like to pose the question to the audience to think about occasions where there have been issues that would have been within scope for the technical committee to consider that you did you for whatever reason you did not raise to the technical committee and that you were not satisfied with how those went whether you were you know the winner or the loser on the on the technical discussion that you did you you were either left feeling either that the right technical solution was not reached or that you felt bad about the process and I'd like to ask are there some of those issues that you think the technical committee should have been able to take for you and what are we missing for you to have confidence in submitting those things to us. Can I you ask the question? Well I noticed Joey didn't come to this session. Well for me personally it was the fact that you can't keep anonymous you will ruin some of your reputation if you reach out to the technical committee publicly and the other thing was that I personally was scared that both the ring the technical committee because your time is valuable and I wouldn't think if the issue is important for me would it be important for you. So those are the two things. Joey says he's sick. I'm sorry Joey feel better. So about an issue where the technical committee might have been helpful it's not my own problem but there has recently been an argument between non-developer so who can't upload on a sound and needs sponsored uploads and sound and a project member it it's actually raw audio I think where basically there has been what was it exactly so the support for our audio was removed I didn't follow the reasons exactly but basically it created a conflict because there are audio maintainer wanted to continue providing support for it in other audio applications but apparently a developer was against it because there were also technical issues involved but basically the last mail from the maintainer I have seen was that he basically wants to give up maintaining the package. Okay so what do you think should have been better there? Do you think that there should be a process by which a non DD maintainer can escalate issues to the technical committee or do you feel that somebody involved you said this is not an issue that you personally were involved in did you consider raising it to the technical committee yourself on behalf of the non non DD uploader maintainer or how can we help there? Well it's it's a question who should handle it so right now basically there's only the technical committee and he was also referred to the technical committee from the release team which is I think the right team but it was only on the release team mailing list so so the the release team said take it to the technical committee but nobody actually did is that yeah it was they said basically that it's not the it does not concern the release team but only they should eyes us solve it between themselves or a such as a technical committee but so I actually read some of this flame war and I will try to keep my opinion out of it the message I think you're referring to was the release team saying we don't want to intervene in this we don't think it's our role and I can't remember exactly what the the wording was but basically that the intent was if you want to take this further then you should go to the technical committee and the the the developer well the the maintainer the non DD maintainer who was upset chose not to do that is that but I think it's also hard for a non member to raise such things so well I think it is true that the non DDs and maybe non maybe even DMs feel that they aren't entitled to bring an issue to the technical committee but that is certainly not the case and there is no restriction that I can see that prevents anybody at all even just a random user from bringing an issue to the technical committee and so you know you should just not feel inhibited about that and if you're if your complaint has no merit then we will dismiss it on its merits not because of your I was to say there are points in history when we had you know a flurry of bugs handed to us by one person in particular that we chose to treat as not being of merit and to explain to them that you know that wasn't the right thing to do and to sort of close them without further action taken but the point that I'm trying to make is we're not afraid to do that so I would encourage as Ian has just has that anybody I don't care if it's a user of a package a DM a DD a sponsored uploading maintainer person you know please if there's something we can help with that falls within the purview of the tech committee then you know please do it and we will let you know if we think we've got value to add and if we don't we'll try to make that clear in a reasonable time frame which as Ian loves to continue pointing out is something that wouldn't always the case but I certainly hope from here forward will be I noticed you said no member and you said non DD and the other comment that I was waiting to make is how do you give teeth to a social committee you don't necessarily give teeth to it for instance you might make a private resolution the default and publication of the issue only if the committee or a mediator can't get the parties to agree oh sorry so you know you don't necessarily give a social conflict resolution team committee mediators teeth private resolution is the best outcome getting the parties to agree is the best outcome and maybe if you can't get them to agree mere publication of the issue to say okay well you put an issue forth yeah I understand what you're trying to say and if we want to have a bop or something and talk again about whether Debian should have a social committee and if so what it should do and how it should be constituted and so forth great in the context of the technical committee I think that what we're trying to accomplish with the change that's being proposed to head towards a GR at some point is this notion that it ought to be explicitly constitutionally okay for the technical committee to have private discussions amongst itself or with you know other members of the project if that seems like the most effective way to address a particular concern and then you know the language discussions that we've been having about the proposed text the last day or two are really all around this notion of how do we make sure that while enabling that we don't sort of enable the committee to somehow start doing everything it wants to do in secret which would not be desirable and how do we ensure that everyone understands both the committee members and the rest of the project and the rest of the world that our biases always in favor of doing as much openly publicly you know in view as possible because that's part of our you know projects fundamental core value about transparency and not hiding problems. Last word from the technical committee because we are running out of time the video team has to take some rest so so I had a thought along the way here and I'm gonna spit out and share it with all of you that the fact that we're now doing IRC meetings I think is actually a very important change for the technical committee in the fact that we're dealing with these things in real time for the simple reason that contentious issues discussed on mailing lists have a very hard time converging even when everybody involved is actually reasonable and generally the same mindset and could in fact hash these things out if left to their own devices and you know in real time and in a room or whatever and so I think there's there's a lesson to be taken from seeing how the technical committee has let issues linger in the past versus what we're doing now with IRC I think there's a lesson there for the wider Debian community about finding ways to resolve issues that don't rely on trying to get a mailing list thread to reach a conclusion. I mean from this thing one of the things that people have been talking about is setting up VoIP or something for all of Debian and something like that would be amazing so if anybody continues thinking about that that would be pretty awesome I can imagine having an IRC conference room with a couple thousand developers would be pretty cool. I think the final word for me is I'd really like to see a couple of nice technical issues come to the technical committee where there's just a disagreement about how some package should behave and that would be you know exactly yes or no on a given patch that would be that would be great and I think we can based on the performance part over the past two IRC meetings I think you can probably expect to actually get an answer so please go ahead. And I'll wrap up just by thanking all of you for your time and attention today. We certainly want to do everything we can to help make the project be successful within the sort of context and constraints established for us by the the Constitution. We very much appreciate your interest and please feel free to follow discussions on our mailing list and chime in when you've got useful opinions to add. Thanks very much.