 I guess we should start. Okay, well, welcome to the policy bof this year. It is a bof, I'm gonna get off the stage in a minute and sit there, I guess. I just wanted to say a few things by way of introduction, so I'm up here. Would anyone be willing to watch IRC for any questions that come up? Okay, thank you, Jonathan. Okay, so what is Debian Policy? Well, it's the document that defines the content there, what is allowed to go into packages, the document that defines the technical content of packages requirements for that content. You might say it's like a spec for all of Debian or as much as we've managed to document. It's also a repository of lessons learned, so things that we've learned not to do in developing Debian are written down there and that's a useful thing to have for us and for others. What is it not? The key thing that it's not is it doesn't really deal with social processes, so we have this other document, the developer's reference, which is meant to contain social workflows and how to coordinate with each other. And so sometimes people file policy bugs asking for social stuff to go in and usually we just reassign it to develop as reference. I thought I might be interested to know why I work on policy. In real life, I'm a philosophy PhD student and so my skills that I get from that are stating things precisely, so I work on policy in the hope of applying that to Debian's benefit. So that's that. How does it work? How do changes to policy happen? Well, there's an appendix to policy called the policy changes process and it basically has four stages. So someone posts a bug saying, I think there's something wrong with this section or I think this thing should be written down and that's the discussion phase. And then at some point someone comes up so the discussion comes to a consensus about what needs to happen and that's called the proposal phase, so there's a proposal for what should be done. Once there's a proposal, the next thing is to write a patch to the manual documenting the proposal and that's possibly the hardest stage. Like often we know what we want to do but writing it down can be tricky. And then the patch needs to be seconded by DDs. So we want three people, three DDs to sign off on a patch. So if the patch submitter was a DD that counts as one and then two seconds. If the patch was submitted by a non-DD then we need three seconds. So seconding is the only thing you have to be a DD to do or everything else in that process anyone can do and you don't have to be a special kind of DD to second policy bugs. That's something that anyone can do. Talking to people this week, I've discovered that some people thought it was like a smaller group than that so I wanted to mention that. And then the changes go in. What do the policy editors do? That's what I am, I'm one of the four policy editors. Basically three things. We maintain the package in the standard sense. So we triage the bugs, we fix FTBFS bugs which do sometimes happen. And that kind of stuff, we write the changelog. We guide the bugs through the process kind of part of triaging. So if it's not clear what should happen next with a bug the policy editors try and like indicate that. And we judge when consensus has been established. So that's basically the reason we're DPL delegated because that can be very contentious in some cases. Usually it's not. So that's the three things we do. One other thing to mention about how policy works is that it's intended to lag behind what's going on in Debian. So changes to policy should never block doing other stuff. Generally there are exceptions where you have to change policy first but generally you should just do stuff if it's the right thing to do and write it down later. And changes to policy shouldn't make lots of packages buggy because they should already be considered buggy and that's why we're writing it in policy. So like if we've got a project consensus that we shouldn't do X then all packages doing X are buggy. And so if we write down in policy that you shouldn't do X we didn't make anything buggy, that's the idea. Okay, let me talk about the past year since the last policy buff. Policy has been uploaded 10 times. Seven of those uploads were normative as in they changed the requirements specified. The other three were like fixing packaging bugs I think. I would like the seven to be 12. I think it would be great if we were releasing policy about once a month. Why don't we? Well, we try to wait until there's about four substantive changes waiting to be released because otherwise we'd be sending these very short emails to Debian developer now and expecting people to read them and that wouldn't be a good use of people's time and the Lindsay and maintainers have to respond to policy releases so we don't wanna make spurious ones but it would be great if we had enough changes that we could release once a month, that would be a goal. So that's releases. We fixed all the issues relating to the transition to Sphinx and RST, I think. I don't think there are any more open bugs. The webmaster team are gonna add some redirects. That hasn't happened yet but we closed all the bugs against policy I think. So that's pretty cool. There's been a lot of contributors over the past year like there's been people who have come back after a while not working on policy and submitted useful patches so Ian is someone who's done that and there've been people like Simon McVitie who have been involved in a lot of discussions and there've been a lot of people who I won't mention because there's so many of them who have just come in and made a first contribution to policy. So that's been great. Translations. Hideki, Yamane and I are working on translations and I think I know how that's gonna work in terms of process. I think I've talked to enough people at DevCom to figure out how to do it. So it's just a case of basically getting the tech to work and I think this is the first time someone's tried to translate something written in Sphinx, in Debian at least. So we're still figuring out how to do that but I think it's only a matter of time before we can start translating which I'm very excited about because there's these old translations of old versions of policy floating around on the internet and if you speak that language you might be tempted to refer to that instead of the current version of policy and then you might be uploading stuff that's buggy and that's pretty bad. So I'm hoping we can get official translations up and running. Okay, that's everything I had so I'm gonna get off the stage. I thought people could ask questions about the process. We could talk about suggestions for changes to the process or particular bugs. We could talk about how to attract contributors and we could talk about translations, anything to do with policy. Ian, here is the mic. I just wanted to say that the translations is really cool for another reason. If you are a non-native English speaker and you're using one of Debian or one of our derivatives you might need to read that documentation to find out how to make your computer do what you want and the fact that that documentation may now be available, going to be available in your native language and not be years or decades out of date, that's really cool. Yes, so I kind of gave a negative only reason and so I appreciate that. Also it's like, we expect all contributors to be able to use English but you can save people's time if they don't have to decipher something that's not in their native language. So for developers as well it's great. Hello, so I recently had a quite trivial problem with the policy, a minor problem with the policy process but it was annoying enough for me not to second propose change. In fact, the diff that I saw contained also a lot of layout diffs and this made it very, very difficult for me to read what precisely the diff in the contents was. So because it was just some trivial change in line breaks and that made it quite difficult for me to see right on the spot, I mean I could have made a check out and the jit-var diff but I didn't do it so it would probably much, much easier be for people than there would be a more readable diff of the proposed change. That's a great idea. I don't know how to implement it. Does anyone have any thoughts? Can you generate a word diff that can be pasted into a bug email? Is that possible? So what you could do is I suppose that you're having a jit branch for the proposed changes and then you can, instead of doing a jit diff, you can do a jit wdiff, I think, something like that and this gives you a word diff or otherwise you could just take care when you edit the document in your feature branch that you do not introduce any layout changes like line breaks or stuff like that. Right. Okay, so there's normally a branch. If I write a patch, I always have it on a branch. I guess it might be useful to just reference the branch and maybe write in the read me saying like, please push a branch and reference it. Does that seem sensible? Okay, I'm gonna put that in the read me, thank you. It might be worth having a small script that you could run on a mail that maybe one of the policy editors would run. If somebody doesn't push it to a branch, you'd have a script that would feed the patch to get AM on a detached head and produce the word diff and automatically email it to the list saying, oh, it automatically generated this thing and then if that becomes a thing we end up doing a lot, then we can have a robot do it. Yeah, totally. You wanna write it? We're in so many mail robots. Yes, you have. Yeah, I guess I'll investigate how hard that is. Thank you. That's great. Seconding, I guess I hadn't really realized that the seconding had workflow issues so that's really valuable feedback, thank you. The main thing that we need volunteer time on, I guess, is writing patches because as I said, it's pretty time intensive. So I write most of the patches but it's kind of not meant to be that way, right? The policy editors are meant to be reviewing patches more than writing them. But that's just how it is. Sorry, can you take a microphone? Could you explain how does the translation work? Does it translate sentence by sentence or just they translate by the paragraph? It's gonna be standard PO4A which I think works by paragraph. Is that, does anyone have any experience translating? Okay, it's PO5, I see. Yeah, it's PO4A. So Chinese translation would be great because you have a lot of potential developers in China, I'm sure. About translation, how do we expect to keep track of the fact that the updates of the original English policy in other languages or maybe the fact that you have translated policies that is almost up to date and you want to specify to the user, you can refer to it except maybe for this paragraph. Right. How do we expect to do that? As I understand it, the way PO4A works is it tracks whether a translation is up to date and if it's not, the English text replaces the out-of-date translated text, which is wonderful and these unofficial translations can't do that so that's why it's great to have an official translation. Do you have a list of issues that you need help with somewhere accessible publicly? Yes, we do. So last debcom, two of the policy editors, me and Russ, had a triage session or sessions and we went through our entire list and we basically divided it into two, well three but the third list is done now. Things that we think ought to be uncontroversial and are basically in almost all cases waiting for someone to write a patch and things that, it's not clear what should change and so people can dig into them but they should expect it to take longer. That is available if you clone the policy repo and check out a branch called triage, you'll find a file triage.txt, which has that list. That could go somewhere better if someone wants to move that. But yes. So that's on salsa. Yeah, well if you just type deb check out debium policy. So one could make issues out of it, get lab issues. So that's something that actually came up just this week. We, the discussions that happen that lead to a policy change have to be archived because we don't like put all the reasoning for the change into policy. So the problem with salsa issues is that the archiving is a bit less robust than the BTS. So I think we'd probably prefer not to do that. But we could probably publish that triage list better. Does anyone have any thoughts where that could go? Debbie and Wiki, that sounds fine. Yeah, okay. So the bug system has a feature that allows you to have that triage for you be the default view of the bugs. You mean user tags? It's very complicated. If it involves, I think it involves user tags and it also involves setting some other properties somewhere. The dev scripts package has done it. We already have that for the stages of the process. So this question about whether a bug is easy is orthogonal to that, right? Can we do both at once? You can have multiple of these axes and I think have everything classified by both. Okay, maybe you and I could talk about that. Because you probably didn't know it. Well, I was going to do this for the DGIT package and I thought this is far, far too hard. But it might be worth it for policy. I did at least look at the relevant docs and go, oh my God. Right. If you've already done the... Well, we don't want to break what's there, but if we were able to add this information as well, then sure. I think possibly that's possible. Let's talk about that later, thank you. These are some fantastic suggestions. I'm very grateful. I guess you're all just itching to write some hatches. One thing that you might do is you might, I know it's a very small group here and probably not very representative, but if there are particular, are kind of awkward bugs that you want to... Well, okay. So there's time consuming and there's awkward. I mean, not that, I mean, we just closed this morning, one of the most awkward that's been open for 10 years. So that was pretty great. Awkward ones aren't occurring to me. Here's some really difficult, but uncontroversial ones. Documenting multi-arc. Right now, the only docs for multi-arc are the spec and the implementation, which as I understand it, are not the same. Because they realized that aspects of the spec should be changed and so they implemented an improved version, which is great. But right now if you want to understand, I don't understand multi-arc. And if I wanted to, I'd have to read the spec, probably end up reading the code, kind of a drag. It would be great if policy said what multi-arc is and what the different values mean. We tried, helmets grown, had a go, but unfortunately we got stuck. So if anyone else would like to make a fresh attempt at getting multi-arc in, that would be, I think, a huge contribution to Debian to have that written down in policy. Second one, deep package triggers are not in policy. If you want to use one, if you think that a deep package trigger is what you need, you have to start reading the man pages and probably end up reading the code. It's pretty tough. It would be great if that was just right there in policy for you to read and apply. There's the original text file, which is just like a plain text file spec. I think one change was made after that was... Is that triggers? The triggers, yeah. Right. And that, I mean, that's in the deep package somewhere. So you're not completely stuffed. Probably, I mean, certainly this should be in policy. But I think the multi-arc thing is more important because the spec that's on the there is, there's a spec on the wiki and it's quite indigestible. The Ubuntu wiki spec as well, yeah. There's one on the Ubuntu wiki, which I think is the canonical. Oh, right. And neither of those describe completely what was accidentally, sorry, actually implemented. Right. And this situation is not very good. Yeah, it's pretty bad. So, you know, if you're interested in learning about these things and then writing down what you learned, please get involved. Basically for these really tough bugs, the policy editors themselves like me, don't want to drive the bug because then we do nothing else, right? We wouldn't have triage and maintenance. So the idea is that we would like someone other than us to drive something like documenting multi-arc and then we'll be very eager to review patches and discuss it. Cool, we just have one comment from RSC. Yes. Gregorus says, SP Wittens blog posts are also very helpful. Check out the tag Debian policy and it's also syndicated on Planet Debian. So if anyone's following or watching this video afterwards, look that up, it's really good. Thanks. Yes, we have a script that's quite old but it still works fine. That extracts user tag information, basically, from the BTS, it gives you three lists, things that are awaiting a patch, things that are awaiting a second and things that are merged for the next release and I blog that about once a month. That was a suggestion at last, the last one. Nice job. Other hard things. So multi-arc, the package triggers. Let's see. There are some control fields that aren't written down. So I learned this week that there's a tags field that connects to depth tags and that's not in policy. So, you know, if I came across a source package with that field, I wouldn't know what it meant. So if you come across something like that, then consider writing a patch. If you spent time figuring out what the field means and when it's meant to be used, share it. Well, we don't have to continue if there aren't any more questions. Thank you for your interest. Please feel free to speak to me if there's an open bug you'd like to start working on. Thank you. And thank you, video team.