 Okay, so anyways, thanks all to coming to this booth and I need to find some power for my laptop first. So, as I said before, I'm not giving a presentation. I'm not holding the hope we are having a booth together on the Debian policy. So, everyone who wants to move close is very welcome too, because it's really something we do together, not something I'm speaking and you can whatever work on your laptop instead on something else. So, basically, why did I schedule that booth? We have the Debian policy, which is, let's say, has been not too good maintenance status ever, I think, since I joined Debian or even before, I can't say about before. It had a few good times where things were working on. Basically, there are lots of things which should be done in policy. We could look at the bug list in the Debian policy. So, basically, what happens if someone wants a change in policy, mostly an adjustment to what we're actually doing. They should report it by a BTS. People should second it, and if they're not second, it should be incorporated. So, things are sometimes working up to the stage of things as suggested. A few have even seconds, but since a bit of time again, basically, after a second, nothing happens. What I would like to get out from this booth is really that we get it done again, at least for whatever two or three years we can have another booth in three years. So, that would be my plan of this booth. I'm happy that at least a few people came here, and so my question really is, what could we do to improve our Debian policy processes to get it working again? This would be my opinion. If there are other opinions that we should speak about, I think we should discuss it now at the beginning of the booth. So, anyone would like to say something here, and anyone who wants to speak gets a microphone. First of all, I have been lobbying for it for a while, so I'm glad you're doing it. I've been speaking to Ross Albury, who's also our policy maintainer, and he said there were already a lot of changes that presumably had three acts and just had to be written up and committed. So, basically, I guess what we need is some way of making this happen. And some of this, I presume, will end up being basically having enough committees for the policy team. Yeah, basically, there's a little two things. The one is that lots of, I would now say, just grant work, what you just need to be done. There is a patch, which is most acceptable, perhaps except formatting or so, which isn't a hard technical decision to do. The policy lives in a git tree, so basically, even as of today, anyone could clone the git tree, make a git format patches of it, and say, here are my, whatever, 20 bucks I've closed. And I'm very happy to apply any of the patches, which seems reasonable enough and have a bug. So, I mean, it's even easier sponsoring such kind of things than normal packages upload. So, I'm happy to sponsor any policy additions. And I mean, if the two bucks remain open, which are more difficult, it's not an issue for me to, whatever, have a discussion about it. But I really think what we should do is get rid of the easy ones, which we are not doing. So, I'm totally agreeing on that end, as a git tree, and everyone could have access to the git tree. So, any more people needing power? Good, so. Yeah, Sam? Hi, I guess I'd like to delve in. I think you've oversimplified the policy process in a way that... Of course, I did up it. I understand. But there's a part of it that is, I think, important to remember going forward. I'm speaking with my TC hat on as someone who may, you know, from time to time get called on to look at whether the process is working well. When you second a policy proposal, you're doing two things, and I'd like us to remember both of them. The first is you're saying, I think this proposal looks good. The second is you're also saying, according to the process document you guys have written for your internal use, that I've reviewed the process and people have had a chance to discuss it and any objections have been handled. So, when you second a bug, you're not just saying, I think it's good. You're saying, we've done our job of listening to all the people who have concerns. Basically, seconding a policy proposal means, I think the deputy community has decided it's a good thing to do. Not just I've decided, but I think the deputy. It's quite important. If you second it, it means, I personally am convinced the deputy community has done this decision. So, yes, but I'm actually about getting from proposals for seconds isn't the thing we're lacking too badly because I always say it's a proposal and we don't get the second within a certain time. We just checked it, so that's the easier one. The thing is really, what do we do? So basically, how do we clear up the queue and how do we get on with proposals who have had enough seconds and are really just easy to implement but don't get implemented? I mean, for the hard ones where we have fights over, we will find out something. In worse case, we defer to the committee. So, I think that's all not what really worries me. But, I mean, if I look at the commenter list, there are the same people who can find other places in Debian and I don't think one of us is going to do it to work on the, let's say, on the normal policy patches. We're all happy to work on the hard ones, but not on the normal ones. So, my question is just, is there someone here who has interest in doing that? How do we get people for that? Any other proposals? How we could do it better? Do we require, for example, anyone who likes to get a policy proposal in to submit things in the kit format patch style? So, we could just apply it. The specificities of the Debian policy work is that it's also quite English bound and it needs competencies to be able to write reasonable technical English and from what I remember it from past discussions, there is also quite a lot of discussions about how exactly the thing appears in policy, which means that it's not just about having a good idea of how the technical policy should look like in terms of technical terms. It's also how it should be written in proper English. And that means that the competencies to do that are not necessarily the same. I need to even discuss a bit about the proper English part because at least from feedback I got, and you can all hear I'm not a native English speaker. From feedback I got is sometimes that if English is something written by me or I had a lot of fight with Steve about proper English for our release announcement mails, and some of the feedback was that my English was better understanding for non-native speakers. I think the most important thing in policy is to be able to understand it. So if I would choose for a, let's say, sufficient English interpretation of someone everybody can understand and something which is totally perfect in English but unfortunately even Schumanns can't understand it, I know what I'm choosing for. And I'm not lobbying now for the way of English that everybody on the planet can understand because it would not be helpful either, but something in between. So probably you need a mix of people with good English language skills, technical skills and who can work up together to find the appropriate mixture of having good English, good technical understanding, and at least understanding for most parts of the projects because that's actually a thing that we aim for. I can see that Peter is perhaps not happy with what I said or is it just over-interpretating your face? Well, so I think it's quite possible to overstate the requirement of needing knowledge across the project. That was the part I was reacting to because in fact I think there's a big difference between writing policy and editing policy or managing the process of merging bits of policy into our policy document set. And I've always thought there was great value in both tech committee work and in policy work of making sure the people who best understood that area of technology within the project were the ones who were sort of helping to articulate what our policies around that ought to be. So I wouldn't get too hung up about sort of broad domain knowledge as a requirement for being very helpful in the policy process, but somebody somewhere does have to understand the technology. You don't get the right ideas to capture to begin with. Yeah, sure. I don't think we have a disagreement about that. So any more remarks, questions, proposals? It's a both, not a talk. So you should speak, not I. Just clear the queue and then have a cleaner ground to start from. Because the current pile of things looks kind of scary and it's not super interesting work to dive into very old things and get people back into discussing specific patches and things. But the problem with Sprint is that you exclude the others that are not there, but yeah, I don't know. But what you could of course also do is just make a virtual Sprint saying we take from this or that time and have an ISC channel dedicated to it. So it doesn't need to be a physical Sprint. I mean a physical Sprint might be better about even a non-physical Sprint. Yeah. It's really all about what it takes to motivate people to work on things and if the opportunity is some direct social interaction with others who are also interested in it would help. It certainly seems like working the policy backlog and getting things to a more current state is the sort of thing our DPL would probably be happy to allocate some funds for. I wasn't thinking about cement money. I'm just saying that when we start thinking about work in and around the project and certainly the backlog of issues in the policy queue is one example of work that's not being adequately attended to. We just heard Mady talk about the notion of trying to find ways to incent things around the project that need attention, that don't have them to happen and if the idea that having a Sprint or something that gets people more directly socially engaged with each other to tackle a problem like this, if it seems like that would be helpful then I wouldn't be too quick to back way from it. I don't worry too much honestly. I mean if people feel like they're going to be disenfranchised by not being at a Sprint, there have after all been lots of time that's already passed where they could have been commenting on those elements of policy or participating in the discussion. And I think if we do a Sprint we should at least do it not only in presence but also allow people to join to the Sprint via IRC. I mean that's not an additional effort and it really helps. Plus one thing we might be thinking is also reducing the barrier of entry for new things in policy because we can also always undo and if we release a policy with something that didn't have enough seconds or I don't know something we had discussed in the Sprint and it happens to not be the right thing to do then we have another discussion and we upload a new version of the policy. As long as we're not too close to the freeze, it can work. So the next ones are the same and the next one are the same. I will also be doing the Q now. So I guess to ask, I think an interesting question to ask the room would be are there people who, you know, conceptually might be the kind of people who would work on policy who aren't and are there things that disincentive that basically when you think about working on policy are the things that you look at and you go, yeah I don't want to work on policy because X. So can we ask people, you know, are there reasons you're not working on policy? Okay, yes, that's a good question. First I would like still to answer a bit to what you just said. Actually I think we should only put in policy when we are sufficiently convinced that it's good for Debian. What we had been doing in the past was basically to take the other things like the developer sufferance. We could say yes, the current ideas of going in this and that direction, but it was nothing formal. If you fail to do that, yeah, you just fail to do it. But I think really for policy we should rather say this is not what we really expect everyone. If you're not doing it your package is definitely buggy. So what we have had in the past is that people said, oh yes, it would be quite nice if we could make this move and put it in policy but we're not doing it. I think that's not something helpful. So we should only move in policy when it's ready. So yeah, and then I have another thing I would like to ask if we should first get an answer to Sam's question. Are there any things that could make it easier for people here in this room or for people you might think might be interested to work on policy? The room is larger than asked for. You can also answer. By the way, is somebody watching ISE here? I'm not doing it. I can answer for myself is I'm not doing policy because I'm in the TC and I kind of tend to think it kind of conflicts because we are the appeal court for whatever policy work could create as conflict so it doesn't feel perfectly right to do both. Plus it's not super interesting. I mean it's not technical work and it's not necessarily the thing I enjoy doing. I don't feel very motivated to go into doing policy work. On the other hand the setting technical policy is the TC work so it's kind of the same thing anyway. Others to the question? Does one of you want to answer? My other question is what I said before. Do you think it would be too harsh to say we won't ever, basically before we accept seconds on a policy proposal you would like to see the diff in the git format patch way or would you think that would be a reasonable thing to do? I don't have an objection to that. I will note that there are a lot of patches that even if they're not necessarily get format patched they're in patches. I mean the difference when you can get AM and get apply isn't really I mean yeah you got to go come up with a commit comment but it's not really that hard to do that. And those still aren't getting applied. I wouldn't say that all of that will solve everything automatically just to put it this way that it could be part of a solution but it's not the solution. And of course anything which now hasn't been patched I wouldn't say we are just refusing it for the fact that there is not the git format patch. So that would be silly and we're not doing that I would say. For me that's more of an administrative question of the actual policy maintainers that could handholds people in the process so you have this proposal look I've just made it a git version of it so that we can all review it in a better way and by that I'm not expressing any agreement or disagreement on that I'm just making a technical change so that we know exactly what we're talking about and then you push it back to the to the producer and say is that what you mean and that's more of an administrative thing and if that's helpful for the process we should certainly be doing it but it doesn't need to be a condition for starting a discussion for something new to be integrating policy. Not for the discussion but for the seconds perhaps. Yeah but that also means that the maintainers could do this administrative work to transform whatever the discussion output into git. I think his point is that the maintainers are overloaded. The fundamental problem here is the maintainers are not doing there is more maintainer work needed than is getting done so pushing more work onto the maintainers isn't going to make things move faster the claim and I think it's true is that we have a large number of things that are adequately seconded that are not moving forward and that's the problem we're trying to fix so adding more tasks to the people who could move things forward I don't think it's going to help. I guess my question is the obvious solution to this is more maintainers Of course. Are there any other solutions that we're considering are we basically sitting here looking at what do we do to get more policy maintainers is that really the question of this boff is how do we get more policy maintainers? No the question is the question for me is rather is that the only way we could do or other ways so basically I mean I plan to go through this boff later on going other things for us to be done in Debian and I think yes I have some of them so I'd like to find people there but the question is is it the only thing that we reasonably need are more maintainers or are there other ways or do we say well do we need policy at all so the question is are we moving in the right direction so that's basically the question for me because I would like to avoid to say yes I have these ideas so I'm just doing it and pushing it and giving nobody a chance to review what I'm planning but of course if nobody else has ideas I'm just looking for more whatever maintainers, people helping the maintainers you don't need to be a whatever long year Debian developer to be able to do a lot of useful work on the policy especially on cleaning up the patches that already exist Bide? Yeah I actually have a slightly different sense of what I think the problem is at various times in the past we've had sort of enough warm bodies looking at the proposed bits of policy but there's almost a different skill set or a different personality matrix or something required to be the person who actually commits a bunch of those changes and it almost feels to me like the thing we're missing is someone who's sort of willing to be a strong policy editor right now it's that sort of last yes okay we've passed all the gates now let's actually put this into policy and the problem is you don't want that to happen totally willy-nilly because even if there's been good discussion around elements of policy there's still sort of I don't know how to put this exactly there's still sort of an element of style or something associated with sort of that final gating of what actually gets merged into a policy document and well did I understand your point about you know we shouldn't be afraid to let things into policy that turn out to be mistakes that we end up having to take back out on the flip side I've always liked the fact that our policy sort of trailed best practice and that you know policy in some sense was the codification of sort of everything we had learned that was actually good about the packaging process and about making a system that really works well and integrates together and we don't let policy sort of lead implementation so there's a bunch of sort of balancing bits in here and it has been surprising to me at times when we were in a situation where it seemed like there were people who were paying attention and commenting on proposed policy elements but that some of them just didn't actually get there. There are some people in this world and we certainly have had the pleasure of having some of them involved in our recent past who are really really good at sort of bringing things like this to closure and it's not a skill set everybody has. I fully agree to that so yes but now on the other side there are a few patches which are not so hard to, there are some that's really very important to make sure the wording is okay. There are some patches where you can just say yeah well it looks most okay and if there are some words not perfect we can just merge up an enhancement later on so I think we need to find the balance but it's not a surprise that the people who are actually policy uploaders I mean at some times with the last time there were two TC members on the four members list of the TC members it's not necessarily a surprise for it so yeah but on the other hand finding someone who is not as deep in the project might be quite helpful as well I think or at least I think we need to try it out because we don't have a chance otherwise to get on it. So don't you have a microphone? Hello, so I was at the tech cat above yesterday or the other day and I remember them saying we don't have a lot to do other than finding new members would this be a possible area of work where we could I will not just wait because I'm from the others to answer because I won't be in the committee long anymore. Well the constitution says we can. The question is whether it makes sense to take a look at the project as a general thing for us to do it. I kind of see that as last resort like if the Deben policy process is so broken that the only recourse we have is get the TC do that administrative work and not to dismiss any of that work but that administrative work nevertheless then we might get involved but I really see that as last recourse and it shouldn't be that way. So I think I would be hesitant politically to do that. That said I agree with that idea that if that needs doing you know if all else fails I absolutely agree that it's worth doing and I should go and twist my arm. The reason I'm politically hesitant is we had some people who are fairly heavily involved in the policy process recently fairly upset about a TC decision and I think it's nice to be sensitive to that. I think it's also nice that if we are going to do a bunch of policy work there's a chance that there will be disagreement about something that happens and it's nice to have the TC one level removed to better handle that disagreement. And so yes I absolutely agree that have the TC do it is a fine is something that is better than not having it done. But I think you know it would not be my first choice. So now with my policy maintainer head on I would say of course everyone who is on the TC right now is somebody who I would be loved to be welcome on the policy because I know I could it. However I can understand the reason for not doing so much there. I also have been used to not keeping a bit of distance from policy with my TC head on things will now change but yes I can fully understand you there. I think Martin also. I was just given the second microphone. Okay. So I think other more things otherwise I think we seem to boil down really to we need to find people when you are simply finding people and thinking about a sprint or whatever else is helping us. Maybe one last word about the TC involvement. I think what we've basically said is that the TC as a body involvement doesn't make sense unless dot dot dot but involving the TC members in discussing that the various patches and all of that totally make sense and we should probably let individuals get involved but not in front line. I think getting input from the appropriate people and I think lots of the team members are the appropriate people for different parts of the policy is a very good thing we should do. But that's something else as a person who are driving the process. So I agree it would probably not be good if the TC members or the TC as a body would drive the process however in cases where the input would be quite valuable. I'm just going to ask this because it's something where I'm surprised it didn't come up and I'm pretty good at kicking at elephants in the room. So I will note that in the last year and a half we've kind of found a couple of people who walked away from the policy process frustrated and upset. Is that actually I guess I'm surprised I think we should ask ourselves whether like talk to people who might be potential new contributors and ask is that an environment you'd feel comfortable working in or does the level of hostility in some of the discussions make it harder for you to contribute there. I don't know what the answer is. I know for myself it would that is not a part of the project I would really enjoy jumping into. But maybe it isn't maybe for the people who would be willing to do the work it isn't an issue. If it is an issue I think we should work on fixing it. Yes basically what is up in my mind for the moment but that might be very wrong. So it's really I mean there are things which are in a non-hostile environment like this is a patch which was just done and nobody disagreed and so on so we can just apply it. I think that's a non-hostile environment and there are more let's say difficult discussions. If somebody is going to say I am going to work on policy but I'm keeping out of all those difficult discussions that would still be very great. So I think what we should do is speaking upfront with people and saying you should choose which part of policy process you want to tackle just with a non-hostile part or are you willing to tackle the hostile part. Why do you think you're going to be able to tell which ones are hostile? You will notice it's a moment where they get hostile and you can just say okay I'm dropping a system. Which might be okay if you have the set of mind to say it's okay to just stop working on this bug because it's getting hostile now and some other else might take over or not. That's something else and if there's a feeling oh I started with taking care of it I'm going to finish it. I think it's okay to say this is getting hostile I'm not taking care of it anymore. So and then yeah perhaps it might be better to just share a source of the people who don't mind about being hostile comments or already have had their share in Debian so that the experience of that takes the hostile ones and the other ones take the not so hostile ones or at least until they get hostile. Just an idea but that really depends on the people who are actually doing the work what they prefer. So I'm not saying you need to do a system that way but whoever feels comfortable with what we should do whatever is comfortable with people doing the work. Okay one silly idea about recruiting would be to use the abuse of the fact that the TC the TC terms expire and we have multiple people in that room that have seen or will see their TC term expire and we should probably talk to them about becoming policy maintainers. So you want to source the policy maintainers from the TC team? I mean it's two new people per year. Actually we already did. There's one right behind you you could start with. I think we could play tonight a round of Mao or policy. So you're absolutely determined to have me not involved in policy. I said oh we can find out later on. You can choose whatever you would like to play. You can't figure out policy until you violate it. You have good ideas. So reverse engineer the rules. That's what LinkedIn is about anyway. I think the discussion starts to get more funny but I don't think we get further points. So I would propose to just close the session here. Thanks for coming and if somebody of you who was not saying so much or someone who was saying much would like to get involved, someone who is watching the video please feel free to contact me directly on IRC, by mail or whatever. I would really be happy to have more people involved in that area. Thank you.