I've kind of changed this scope of this talk since I sent in the abstract. Now I want to talk about essentially two things. Firstly, I want to talk about reorganizing the current policy documents because there is more than one document. I'm not really happy with the content of the current technical policy document itself. The second thing that I'm not happy about is the policy change process. There have been, it's currently kind of stalled and Russ and I are the only ones actually active on the policy change and there have been, I don't know, several hundred bugs that are on the BTS and that scare me enough that I don't like going in and looking at them because it detests me. And most of these things are bugs which are stuck in a state of limbo. I don't know if the discussion is over or I'm not a domain expert and there have been a lot of contradictory testimonies there that I'm not sure which way I should jump.  And that was not exactly pleasant. So before we jumped into some rather radical suggestions that I'm going to bring forth today I wanted to do a little meta introduction. Why do we need to make policy? What does policy do? What are the different kinds of policy documents or policy life documents that we are floating around? So there are a number of different things. The main one that drove the technical policy document was we are creating an OS, we are integrating bunches of software written by all kinds of people and there is only bare minimum of maintenance or structure that pulls these things together. The FHS is one such approach that kind of provides some kind of guideline for building. But that doesn't address the things to the level of detail that we must. Apart from the integration requirements there are the system packaging. How maintenance steps are to be called. There is also the fact that I think we ought to be able to say that you call Deep Package gently controlled by or gen changes other parts of the packaging infrastructure but I'm not sure how far we go in that. Because some of that is just the calling interface of the Deep Package maybe it shouldn't be in policy. There are update requirements that are released in one move from previous version to the next version. That has some implications on how you do your packaging. There are few standards that are designed to reduce bugs. The library is simple versioning stuff that we are talking about is one of these kind of things. There is the developer's definition is truck full of best practices and it's a company of depth. And there are others who are trucking through the nuts. And for a new developer just getting into developing there are all kinds of how-to's and what-to's. But there's capital all over the place. And the contents of all these documents is different. There are some things that are absolutely required for integration. You don't do that. Your package breaks or the release breaks and the release managers come and hit you on the head with a hammer. There are some things that the project has decided on feature to provide. User changes in configuration files are never lost or should not be lost when you do the package update. This is the feature that was decided by the project as something that we support. This is, there's no reason, there's not integration issue. It is a user support feature. There are other such things that we have. And then there are things that, you know, for the most part are the things that you ought to do. And if there are exceptions to the rule, you should be able to defend that your package falls into such an exception. This is, thanks to Dwight, he mentioned that there might be things that we might make mandatory in the future but we are just trying it out and we are waiting out what kind of people implement it. This is one of the current failures in policy. There is no way to stage a complex change that might require a transition period. Well, we did do a producer share dog. Don't talk about that to me. That belongs to a major P.S. policy. Build arch and build in-depth targets is a good example of this particular problem. That one has been floating around for a long time. And how long has it taken us to do the user share dog transition? Haven't you finished? Seven or eight years. I wouldn't call that to play something that quality- Yeah, but it wasn't particularly the fault but it wasn't in policy right when we chose to do it with this though. I always thought it was my fault. It was our fault not saying, well, what's the way to release change de-hackage to actually have the feature that we need to just move the directory in one atomic step and be done with it. Yeah. At that point of time getting changed into de-hackage was harder than getting changed into quality right now. Hopefully, yeah. Then there are things which are nice to have but are not critical which there are lots of things like that in the middle of the description. And there are aesthetically pleasing things and subjective best policies like not having a period at the end of your short description. Which maybe one's about and I always go right. Is working slow or not? I don't know because I will never see it. There were various different tests on the short description that we ended up taking out. I don't know if that was one of them. The capital letter one I know is not there anymore. So, we have used this broad categorization. There are things that maintenance must do or is it a decrease in the quality or the features that the way it's been influenced. Things that maintenance should do are demonstrated there to see the exception. And then there are things that are just near recommendations. This is the much-shoulded main thing in policy. And I'm open to whether we need to increase the number of categories that we have. I don't see how we could but these need not be set in stone. Other standard organizations tend to follow that because we're pretty well done as well. But we are certainly different from the IETF for example in what we need. Yes. But these words. Okay. What are the current problems with the policy document? I'm just mighty con it. I'm sure other people have things to add. The current policy is loaded. It started its life as the package documentation. Julian and I shoved a whole lot of things. We put a lot of things in from the packaging manual which used to be separate and we threw a whole lot of things out. But I don't think we are going to continue this. And I think we kind of burnt out before we actually were through. Subsequently, the much-shoulded main labels are not consistent or correct. If they were consistent and correct, we would never need the release team to give us a list of RC bugs. I have no idea how many policy documents there are. I know there is the burn policy, there is the extract post policy, there is the menu policy, there is an e-max policy. There ought to be a Python policy but there isn't really. There is a PAM policy sort of. There is a Kerler's policy sort of. There is a WebEx policy sort of. There is a tech policy which I think is less sort of than more real. There are a couple others as well. I want to develop all of these. And I guess I can kind of sort of fit in the AC Linux policy but... So one thing that has not happened is it seems like it used to be that the policy documents would eventually have a goal of migrating into the demian policy package and be included with it for the more recent policies that have shown up that process doesn't seem to be happening. There is a lot of policy processes not happening but that is one of them. And I think that it is not clear now to people who are developing policies that the demian policy central package is actually interested in incorporating their policies. And I think we, personally, I would like to get back to that point. I think there is a lot of value in having a single document where if you are not packaging a tech package you just ignore that part. But... Injection, you are not meeting this kind of effect. Any policy is equal to any other policy. If I upload a package with a policy document in it, what value does it have? Does it have the same value as, say, the technical policy or the foreign policy or anything else? I kind of don't agree with that because when we maintain this viewpoint, that's untenable. There are 10,000 source packages out there. If any one of them might have uploaded a policy which affects my packages, how the heck am I supposed to know? I mean, I don't even think I have looked at the user-shared doc of all the packages that I even installed. I know I'm supposed to, but I don't really. I mean, how many people do? All of them. All right, so we need to have some idea of how many there are. They're also getting, because there's so many of these things floating around, it's getting really hard to tell if your package is policy-compliant. I think there is that question now. Not every single rule that we have in policy has a clear rationale. And it might have been clear to the people who first got it into policy, but those people are long gone. We have no idea why it is there. And from time to time, there is discussion on why doc-slash-debian-slash-rule should be made by it, for example. The best that we have is, occasionally, you find a bug reference, and then a bug reference came from Nailingless to thread a bot at the same time. And we have to... I would like to change this aspect of policy. And of course, I don't know how many of you have heard in the previous talk, I would like to have Sulu board that helps policy-compliant checkers like Rintian and Linda being talked about at the same time as we were talking about the policy change itself. So it is clear to the people who are doing the checks what exactly they mean. One easy way to do that, well, one more straightforward approach there, as an alternative to Nailingism policy is to require everybody who submits a policy change to include this to at least one of Linda and Linda. I kind of like... There are some things that we may want to debate as possible policy changes which don't really make sense to approach that way. A good example would be, say that we wanted to debate whether we wanted all the NIT scripts to follow the LSB and NIT script standard. It's very difficult to, particularly the output formats, it's very difficult to write a Lintian check for that. You can test whether it at least tries to follow us, which is about that. Yeah. Well, I would rather, as far as possible, try to be language neutral. Linda is in Python, Rintian is Perl, and there might be other things which are written in OCaml that are something... Objective C. So my radical proposal number one is that we get rid of the current set of policy documents and we start writing a new technical policy document from scratch. And here is my case for it. The current policy, as I said, is bloated. We like to talk to these patients. We don't know what to much report about. It hasn't actually been written by a consistent editorial policy base. It rambles that the language is different. It changes from first person, active voice, massive voice, as you go from one paragraph to the next. There are tense changes that go on in the same section. So it will just become a more pleasant documentary. Hence, Joy, yes, we might want to... Policy can be sliced and diced away. You might want to say that if my package is compliant with all the... You do this or you release it through the hammer, actually, you kind of do it. It would be nice if we could have a smaller section as these other muscles. These are the should... You probably should do these both. And then there's the rest of this. On the other hand, if I'm working with an X package and I kind of know the rest of it, I want to know what are the X specific causes. I want to see all the causes, must, should, and random tips about X in one place instead of having to go hunting through. So I am proposing that we use DocBook for the new policy manager. This will allow us to create an overarching multi-part book. Each part in this policy book can be what is currently a separate policy document. So you can start with technical policy as one part and the developers reference at the last part and all these Perl, Python... I forgot in the list that we came up with... All those... So you mentioned at the start that the policy started as Deepakage documentation and one of the things that's been an issue over the last few years is that why we don't want to have certain kinds of best practice Deepakage operating and Deepakage documentation. Deepakage developers manual, I think is the term. Why we don't want to have it in policy. Nobody's actually written a Deepakage developers manual. So what I was going to ask was, once we are in a position where we can include and exclude, slice and dice the complete policy manual, is it possible that the Deepakage developers manual could once again find a home in that assembly? I hope that the Deepakage maintainers feel free to take whatever they want from this current policy manual. We do need to figure out, and I don't know where, how to do so, is there are things that Deepakage's internal documentation of how the program works. On the other hand, there are also things that Deepakage maintainers ought to be able to defend on their kind of packaging interface, so to say. But there are things that you must do that are Deepakage operational instructions that you must do if you're going to interoperate properly with other packages, but that are also, in some sense, they also ought to be part of Deepakage and Manpage suites. So they fall in a pathway house between Deepakage documentation and policy. Well, I kind of think of this as similar to MPAs, right? If you write it properly, you have an API that you publish. There are also optional parts about things that you optionally allow when they're not part of the strict API that you are also providing. And similarly, Deepakage has to provide a certain set of functionality. For example, Deepakage had better created .dev files by some invocation or the other. This is not something that Deepakage maintainers can tell. We decided not to do that. I think it's kind of an interesting question as to whether or not it should be, whether or not policy ideally should contain, should be independent of the specific implementation of the package installation program that we happen to be using. In other words, should the policy documents say, that Deepakage is an AR archive that consists of two members, and data, I mean, do we want to dive into that level? Or do we want to say you have to use Deepakage and be done with it? I mean, if you were writing like an IEPF standard, you wouldn't say you have to use Deepakage. You would say it's an AR archive, blah, blah, blah, blah. Yeah, I think that we want to talk about what we want main hitters to use. I mean, we don't want main hitters to build them by hand unless they're doing something weird. So, by the way, in policy, this is what you put together to get your debt. I mean, this is how you get your debt, how you call Deepakage debt. It's kind of useful to have that sort of interface specified because you don't have to write tools that go in exactly that business. And that allows us to change some things here in the project. I've certainly written tools that go in our entire project because it's faster to use. Because then running things would have Deepakage, but that's it. There are two levels of things to talk about. One is the spec for the packaging system itself. Yes. And that is what we're talking about, that the packaging system has the spec. Yes. We might not want that to be here. What we are talking about is the other thing. I don't care about the spec for Deepakage. I want to care about what Deepakage maintenance needs to know how to talk to our packaging system. It seems to me like we definitely need to see if we can't engage the Deepakage to the maintainers now that there's a somewhat more active team into taking on some of the stuff. The thing is that we're going to have a policy team and that policy team is not going to be Deepakage at first. No. In fact, I would... Why do you think Deepakage at first should be at some level? At some level. Really? Well, I can tell you roughly what a debt looks like. You might not need to know how process archive works, but you do need to know what the... Yeah, and the detailed specification of exactly how the debt was put together, I would really rather have the Deepakage maintainers be maintaining that instead of having policy maintainers maintain that. For among other things, while there's going to be a policy team that's like the core team, I would really like to have... be able to draw in people who are not that intimately familiar in one way or the other. One of the things I want to come up in the rest of the talk is that we're going to follow up on the Winning Express in every aspect of policy change. And Deepakage maintenance... I have done my share of hacking of Deepakage, and I'm one of the few people who have managed not to disappear after working on Deepakage, which is what happens when we repackage the data. So my concern is simply to try to make sure that things don't get taken out of policy for a good and right reason. It's got nevertheless taken out of policy and without ending up with... One point, really. The policy concentrates a lot about explaining the package relationships. And it could perhaps... the part where the policy may or may not want to dictate which of the tools at which level has to follow this specification. You know, when it says recommend field, of course the policy should mention the recommend field because the packageers want to use it. But the policy may or may not want to dictate which part of the packaging suit enforces the field. You know, Deepakage doesn't care about it, but apps does. So the policy is orthogonal, is above the policy. So the policy should describe the behavior that is expected of the packaging system. But not just Deepakage. Right. And don't care about the actual education. But if the behavior changes over time. But we don't want... we want the behavior to be consistent for the package, maintain it and rely on certain behavior. That if I put something, my control file, this is how it will affect my package. If I put something in my maintainer script, this is how my maintainer script will be called and this is the action that will be taken. At the same time, I think there's a place for informational notes that we happen to know that this is broken at the moment. Say, remember, recommends was broken and deselect for years. Uploaders currently can't be wrapped with the old stable Deepakage. That's a good example. So I think it's still worth doing. That's how we wanted to work, but we know that there are currently problems. You posted a bug against policy seven years ago. About the copyright of the current policy. I have no clue. Yes you do. So we probably won't want to... So Ian wrote a lot of all, right? He added it. So Ian wrote a lot of that. Can we just go and grab him? Ian is one of the people... There are a lot of people who have added things. Everybody who submitted a policy bug would put a patch. We have to change down all these things and ask them what copyright we want from this and make sure that they have the same copyright or, as I said, throw policy out. Start from scratch. Create a quick consistent copyright for this and make everybody who wants to put in anything agree to that statement. So the big concern I have about throwing it out and starting over... I mean, I think that what you get at the end of that it might be really nice, but it has the same problem as whatever anybody thinks about fixing a software package by throwing it out and rewriting it because you often end up with a different set of bugs and you end up with a giant lag between when you threw out the old one and when you had to work on it. That's true. But the thing is, I think with policy, there is this adage that says you always throw out your first implementation and your second implementation. I would say that a giant lag where nothing is happening is basically where we are right now and also, unlike software, you can refer to two policy documents at once. It would probably suck, but you can't do it. I think that's... I contend that way before learning is frozen. We can't have a new document. How many pages of policy do you open? Many. But the thing is, if we actually start going through the review process, you will find that it won't be that many pages. One thing I would say about copyright is that changes that were submitted once... Once there is at least a copyright that we can look at, whether it's true or not, I think it's perfectly reasonable to say that people submitting patches at that point either agree to that copyright or we're being negligent. And I think... Not lawyer, but I think a court... Why is it frozen copyright? I mentioned one thing. The package of manual integration was actually not an integration. We just slept on to the document. It stopped on in part. We didn't take everything. Three appendices came off. I still have to go back and refer to the old public packaging manual for a couple of things. I think I'd have to dig it up from archive.org. Yes. Because some of it... Some of it is a record manual for duplication. And some of it is a specification. So there's two sections describing change of files. One describes the idea, which it should, really. And the other describes the formant, the idea of the formant where about 50 pages apart. And I was fixing it, but I wasn't brave enough to actually rip it out all and combine it to one section. And I just ripped out the most obvious parts and cross-referenced it both and then posted the page and said, okay, this page does something. And it was like 150 kilobytes or plus, minus, plus, minus, plus, minus. And I don't think anyone actually read the page. They just said, okay, Joe is doing something... It should be good. Let's just look at the final version. Okay, it looks as confused as before. Okay, let's go in. Let's go in. I mean, from a policy document, you can talk about the possibility of talking in a different game format. Yeah, in one of those sections. Not sure which one, but somewhere. That would be a great example of something that the politicians would say, you don't get to do that anymore. Sorry, we have one change going for that. Yeah. So if we do go ahead and start a new policy document, the new document can be built into every policy rule that comes in. It can have a normative section, a rational, informative, additional nodes, and packet checking pseudocode, which is language, neutral, and kind of sort of... It is sometimes easier to express some things in pseudocode, than it is in English. I would also like to say that if we go with SGML or XML documents, you can do SGML entity declarations. So you can have... At the end, you can have policy document based... ordered by priority. You have all the must things come in and so on. And you can have this similar policy document, which says this is ordered by subject, and in the subject, you're pulling all the rules down. So every time a rule comes in, if we can identify the severity, is it a must, is it a failure, is it one of those, you know, the rest of it? And again, specify the subject. And I know that specifying categorization is always hard, and you probably have to come back and redo it. But that is going to be, you know, making consistent categorization in the life order, hierarchy of subjects, and probably easier to do with this new format, then it is to go ahead and change our country.  So I don't want to move away from devian doc onto doc. Because I get indices and cross-references and I can slice and dice and create. So the main trick of the document, the overarching document, can be informative and we can say only the things that are pulled in, all these policy dictums that are pulled in, only those parts are normative. So you can put in a matrix of nice introductory material and all kinds of things. Is all those still developing devian doc? What is he? He's not. If it gets a bug, it will get fixed. There are no features being added. Doc, on the other hand, seems to be fairly alive, in a large community and you can convert doc-book format into any kind of output format. RTF or I've seen. I mean as a policy contributor, one of the things that I would want if we were going to use doc-book is I would want a style guide that specifies what doc-book tags we're actually going to use because doc-book has like 5,000 tags and it's insane. Any time I write doc-book I spend more time reading the doc-book. I think that's just adding a new section of policy filling out of some template. Yes. That should be easy enough to do. And I haven't walked the doc-book book. I haven't actually read it yet. Yeah, I mean if someone is willing to you, for example, would be willing to write a style guide that says, you know, now she'll use the following tags for the following purpose. That would make it way greatly reduce the barrier of entry for trying to use doc-book to do policy. Inventation guide. Inventation guide. I see indentations best. This is the other thing. Policy isn't consistent. We need to review it and improve the mice. Especially if you're going to make a more follower structure for each rule as opposed to just adding paragraph which might have one or two or zero actual policy rules depending on the paragraph. I think it would make policy easier to read. One of the things that I definitely want to do when I get out of any kind of policy review is that we have this odd situation right now and it's what you brought up earlier where there's the release team determines the RC bugs for particular release. And policy has a set of musts. And I think that some degree, I think that we should allow ourselves a bit of divergence between those two things for any given release. I think the release manager should be able to say there's this odd must which we're just not going to enforce for this release. Because it's going to delay the release. I think that we should be back into a position where you can assume that if it says must in policy it's an RC bug for release unless there's a special exception listed and I don't feel like we're there right now. So we can sort of start off from the GOES document that the release team put together in AJ's tenure I think and that persisted through mine and the current release. And that's written in an attempt to be this style of policy dictums rather than the informative notes and it's just I shall do the following things. This is the authoritative list of musts. Which makes me think that if we do start this kind of a rewrite one of the ways that you can start on that write all the RC bugs first and then go back and start going through the current policy the annual looking for the shoulds and the musts that didn't make the RC bug list and then you have if we have this period where we have two policies which we're going to end up with if we have this the more days to get it merged them before learning then at least we can have maybe the new policy can very quickly become the release policy it has all the critical stuff and then we can migrate the rest of the stuff over as we can find the source of power. This is the scary part we do need help from everybody else just the two of us it didn't want to happen and I'm actually we are looking for people who have demonstrated motivation and desire to work on policy to come join the team. I really think the situation we're going to end is that if we don't get a lot of people actively interested in contributing to this kind of document we're going to have to just maintain current document in some factor or another because I don't know I'm not sure how long we can this is getting to be to onerous and burden to maintain the current structure in manager justice to the project because we are not serving the project or the policy team right now so I would if we can't get some of these radical changes in and get to the point where I think it is sustainable I am going to just ask for somebody else to take over I'm going to start out I don't think this is sustainable right now I'm referencing just the state of the document or the state of the practice and that's the second part of the project and I'm running out of time we should let you continue some material will have to move to other places like DPEC's documentation developer's reference and I think there's some stuff in developer's reference that actually should migrate back but and multi-part books we can have a one-spot place where you can get one gigantic 1200 page document maybe that starts off with I'm not saying it all is part of the internet process so it starts off with a maybe a two-page thing that says these are the RC books these are the shirts and then pulls in other things like e-max quality or mind-policy is that a mind-policy? ouch where is it? it's in the policy it's like a menu mind I thought there were many policies there but it was also in mind-policy nobody notices this because there are 300 differences it's like a page in the back this concludes the changing the current structure essentially what we have done is set a stock book it's GML entities where you can publish the policy documents depending on whether you want it priority based or you want it subject-based can be done provide images where we can pull in other policy documents to create an overwriting document that you can give to the new maintainers and say go spend five years read through all this come back what's the fourth word on the second page? one thing I'd like to have in my other pattern is that I'd like to be in a position where Ubuntu could add a few bits saying these are the things that we do differently here are the things you must do as in Ubuntu package and potentially have those be referensible in some way from the white on white in some way in some way and we can have a common glossary we have not had a decent glossary or an index of anything in the policy and I think that it should be doable with another thing I would be interested in saying is talking about changing the document structure and so on transform to let you spit out each of the musts we are basically talking about two non-construction policy there are going to be two matrix documents one matrix document does it by you get all the musts first and then you get all this to the center and the second thing which comes from the same set of XML entities gives you the same thing by category or subject basically and these policies are going to have a fair amount of explanatory text explaining one thing we should shut out we should actually have more it could have more than it does now in fact but in terms of having to be able to show what is before this before release the idea is that what I'm envisioning here is that the political policy section is going to have a severity level of subject rule an additional informative rationale would have seen a separate section of why we have this rule and then possibly pseudo code for package checking and then you can apply an XML transform and pull out whichever of those pieces you want including the mentioned guys in this applied accessibility transform to pull out the super so then they can make sure that they watch a policy-blessed version of the pseudo code if you want to include all the other policies that would make that possible rewriting those to the new structure as long as they are written in some kind of HTML we ought to be able to just say that includes that as a chapter or as a part in this I would like to see everything move to well most of them are pretty small most of the other supplementary ones are actually not that large and then creating personal have already written a devian doc to doc these kind of front-sectors chapters in policy they are actually documents on their own you could have a devian operating system as a document you know and that's one thing we can read about you know and one document could be called a devian policy on programming languages and then it would include all the pearl and python stuff because in the interest of readability when you say task and skills tell people just read the operating system part sure the one that we are going to do by subject the structure of that policy that version of the policy document can indeed be but still the table of contents that is three pages long is still intimidating so splitting it up is actually okay at least nesting it so it's all of this can be hammered out as long as we agree on these principles we write the components and I think we can slice and dice it over one at the end and figure out which looks the best and you don't have to go ahead you don't have to have a static setup most of these the matrix documents that I am calling them are not normative you don't have any number you can create your own this is my view of the policy document as long as you have what are the database terms as long as you have good precision and good coverage then it doesn't matter which order you are presenting it in one thing I would like to have that I guess feeds into a reorgan document is has policy chapter number references and I have not done it for a long time I don't know if you have for us but going through and updating the policy number references I think Frank did it a little while back it's a ghastly chore and some kind of permeability that just identifies the name of the what we are putting in could we have a UID I just said we would name it well it's probably long in the output then if you are using anchors it's a thing that says ref coolant policy 10.1 or whatever having just policy short string what you do is for the web page you turn it into a URL and for the output of the console for the output of the console you need to maintain a database of hyper reps to hyper piles and then if we've got a devian policy command you can type devian policy name or you can map it to a number 5 2 minutes later getting into the second half of this I'm not happy with different policy change process before I go on and describe what's wrong with it and how I think we can fix it I want to have a look at what I think are the problems of the policy change process the first thing is that we obviously want changes that are going in to be technically correct we there should be somewhat consistent in the rest of policy because well I don't know why it makes it easier reading it makes it doesn't principle of these surprise I just want the policy to be consistent document this means that you don't want to be talking about things that aren't true it also means that this procrastination should be made to what students just know what in the US is known as the Hail Mary pass just throw the football up in there and you hope that somebody in the other end is going to pass it and you get bored we don't want to do an iterative design process through policy changes it would be nice to have those policies these are the things that are on their way in maybe if you are planning on doing something like this then here is what some other people are doing so that we don't end up with iterative design by committees who aren't talking to each other or something like that and there is we need the policy process should become far more transparent and I've got proposals in for that this is our adopt change the change should not be too receptive very many packages become instantly buggy then there should be a transition plan there can be exceptions to this we haven't usually had exceptions to this so far but I'm saying that exceptions should be there but they should be permissible but if there is going to be an exception like this where the policy change can cause packages to become instantly buggy all at once I don't want to be in the hot seat I want the rest of the technical committee to be in the prime plan with me I think that's a great idea involving the technical committee in these decisions it gives the technical committee more to do on other things hey hey hey I'm telling you to do it right now well it may almost just be complaining about that so I don't think that was ever his complaint in terms of policy not making anything insta buggy the mantra that has been repeated over and over for years is policy is not a stick to beat maintainers with and I don't remember who originated that saying people have been missbooking me for years exactly and even in terms of some interactions that I recall I don't remember who we had with you as the policy maintainer there seems to be this gap where we need it's certainly within the bailout of policy to decide how packages should behave so that they can interoperate on some particular point and in practice today those packages are not interacting with each other properly so in effect I would say they are already buggy in that they do not form a cohesive group of packages but there still seems to be a difficulty in getting policy wording in place even when a decision seems to have been agreed upon a lot of this happened before the delegation because I didn't believe that I had the right to make changes to the policy because I didn't see any power devolving to me I just ran into a developer who happened to be in the proper group on master so I had to commit right to policy now that we are proper delegates I see us maybe with the backing from the technical committee to actually have the right to make this kind of changes and then developers to check it the other point about that is that the constitution says that the technical committee is a stick to be maintainers with the release team has always desperately wanted a stick to be maintainers with in controversial maybe we can make more use of the technical committee to say look we just made a decision this is the decision you know this is worth following the devian governance model and let's go forward the next thing about policy changes the change has to be reviewed in depth it has to be in the open AJ was scared of a star chamber sessions where decisions are made so I say that anybody can contribute to the discussion it should be held on a publicly accessible archived open building list that we already have devian policy there should be no policy decision made behind the scenes by people that are known and suddenly there is a new policy dictum that everybody has to follow well there can be a lot of IRC but the wrong way I have complete logs the one thing about IRC the one thing about IRC though you're just quoting me at that point because I only said you can't post your logs on websites the one thing about IRC though too is that it works for some of those and not for others I'm not particularly an IRC person I'm happy to use IRC if I need to for a particular purpose but I'm unlikely to kind of hang out there in general it's an interaction style and the next thing that I've got here for the work of policy which has never been the case policy proposal should be addressed in a timely fashion I'm going to put a strict time limit it goes through in whatever time limit we choose one month, two months or IRC gets dropped or it gets handed over to the technical committee or it gets handed over to the developer to throw out into the form of a GA it just doesn't keep on hanging on the BTS for the policy forever with no action being taken I thought that was what the current process already said but I'm not sure about it the current process kind of says that it doesn't I don't think it specifies actions it doesn't say that there is going to be a limit on the discussion you can leave the discussion I'm limited in a correct way I also before I was a delegate I didn't say I had the right to say that this person I'm going to trust more and even to the five people who say that of course I'm going to go with what this guy said even if I know that person to be if Joey and France tell me something about the way that we install the works and such should be the policy or utility I don't care if there are 50 people who have just gone through it and I'm telling me that that's not the way DI works and they shouldn't be working that way if it does domain experts I think we should treat specially and now I think we have the right being delegates to actually make a decision and say this guy is a domain expert I'm going to listen to him Goal is still rough consensus I don't want the policy policy maintainers are not domain experts in everything they shouldn't be driving they were willing nearly there are times when we can't tell if there is a consensus over what should be them there are things hey I thought I knew about the simple words name but in terms of I don't so I might not know right decision I get two different experts telling me like in a quote two expert witnesses exactly the opposite way we need to be able to shove it back up to the technical committee those are the guys who are long beards, white head hair etc so under any non-technical issue that we can't decide which is just a matter of subjective aesthetics we shove it back to the developer body and we say that this is the policy team can't deal with this we don't know which way to go you guys decide the next thing that we have been warned about is package maintainers who are affected by policy changes sometimes are unaware there is something that needs their attention and this needs to be improved we need to be proactive about finding people who are going to be affected by policy changes getting their input in this is the place where I think we can borrow a model from the IDTF and if we say if we reach the rough consensus on the policy mailing list that's the point at which we should accumulate whatever we reach the rough consensus on on a regular basis I would like this in the this is the goal policy as a state machine state A is we are detecting some recent data following policy I've got a new proposal we are in state A state B is when we have some discussion and there somebody has got some kind of a rough solution we don't have the perfect solution but we are kind of getting there this is state C option we are calling the guys who actually know what they are talking about state D is we are close to a working solution you create the policy bandwidth, rational tests etc they are nearly there then this is kind of a contribution I thought that I would like to have a bunch of people either policy maintainer who has not the proposal to sign up on it if they know what the domain is or some number of people who are in the domain say that this thing looks same I don't want to have to come to this point where I have no idea what people are talking about this proposal has come through I don't know what the ramifications are what the impact might be I want just like if you say I sign up on to this proposal I want a bunch of people to sign up on it before it goes anywhere I would be worried about to define that too much this is this is not going to be this is my idea I was trying to be funny I thought the people would understand state C the results states are either the changes accepted or we decided it is not a policy matter it timed out because we couldn't teach a conclusion and no policy was or we couldn't find a solution at all or we refer to the technical committee as being too hard for us who are policy folk and we give it to the DC to the white guys we refer it to the developer body or we just kind of reject it and if the delegates reject it it goes straight to the technical committee to I don't know I think it only goes to the technical committee if the people who proposed it decide they want to appeal I just didn't want to give the policy being a policy delegate I didn't want to give me the power of detecting things out of hand without them being any review if you want the review to be somebody anybody can call in on the technical committee any time they want and maybe I should just remove this I think asking the proposal to appeal if they want to so I propose we continue using the BTS but I say as we use the user tags to monitor progress and we use automated mails to remind us about milestones and I also want to propose something called WM policy announced no discussion was there when you are close to formating a policy you send mail to the announce people should look on the mail to announce to see if their packages are affected by the time stop goes to announce you have a flipped out solution you have a problem rational solution and if you want to object you can we can use WM devil's announce and just won't want to step on any towards I think about one reason against the develop announce is that it's listed read by 500 people general intimidation issue you don't necessarily want everybody to look at you while you make your policy this is the final state this is the final state it's equivalent to an IETF last call and the IETF last call was sent to the whole IETF announce list I've got three slides maybe we can rush through those and come back to so this is what we should be able to do knowing me you know that there are going to be typos in policy I don't want to have to go through the whole process just to fix my typos this is kind of sort of like what we have now if there is actually policy is wrong about something we want it to have a normal bug we use user tag like I say and policy is stated because we don't know what to fix it yet gaps in policy or new proposals are going wish list again in state A if a solution is proposed either initially or just thereafter we move over to state B and I might be over-formalizing this user tag bit so I'm willing to listen to push back this was my first take on the process this is basically implementing the state diagram using DTS I want a strict time limit for this stage if we can't find a solution in a month we might not find a solution we so as you can put for the guy who know what they're doing they don't have any they might not want to respond to us so again there is a time limit you ask them you wait politely for a response for a week or so if nobody responds we kind of you know move on we don't like to pop the proposal die there then again I want to have sign off so that I know that this is okay formal policy language we've been through this in the previous final reviews and discussions are sent at this stage again with a time limit this is where we kind of publish it maybe this is an ideal that I don't think I have followed in all cases because usually I've been trying to do this it should meet the concerns of everybody which is not possible at the end of this discussion period we need a solution we can't just let it stagnate whatever if we the maintenance are satisfied we can accept it if the policy maintenance thing that purpose thing does not meet the concerns of all maintenance etc. and follow it no solution has been reached then we pass the buck technical committee or to the developer body for a GR or whatever what have you or the social committee for those students actually will come again we talk about it and I think this is what I have I went through the state diagrams I converted into how you use the BTS user tags to kind of follow the progress of this so the couple of things that are different from what we currently do is there is far more involvement of the technical committee we push things to them when we don't know what the heck is going on that is the body that is set up to do that secondly I propose just like we do for GR we set a time limit we can set a long time limit if people are concerned that there won't be enough discussion but we should have a finite period where a proposal is either accepted shot down or sent on to the technical committee for resolution so I think that is largely excellent indeed the one comment I have that occasionally we are probably going to find ourselves in situations where we think this is a good idea but the technology isn't there yet and we may need to account for that by losing the discussion that took place while we go off and get all of our cards in order but keep the discussion around somewhere until the technology exists to let us submit this proposal okay how would you finish with that we could do it with an additional suspended state and then a general policy that once a year we review all suspended bugs and see if we can reopen them that's one route you can take I have a fear that the suspended state discussions might tend to accumulate and hang on unless you are saying that if at the end of the year it hasn't come onto the sub pension we just close it we can do that we can always close it too now and later we can close it on our card and reopen it later if in any case the policy is being re-written well the bugs concerning the previous policy document will be referring to an non-existent document anymore well the swaying future we do have to go through the previous bugs because the bugs are not against the document the bugs are against policy and even if we are re-writing the document the policy is not supposed to be you know we are not going to go through the policy to understand that but in any case if policy currently is defined as documenting the behavior well some things need to be changed maybe what should be done is to tell maintainers that if you have a pending bug well we are starting from scratch check the proposal check as it is being formulated and if your bug still applies tell it there because we will be mass-closing them no I think it should be up to Russ and I to actually look at the bug it doesn't apply to the new policy or the issue that has been answered and then either close it saying that this is no longer relevant or close it saying that the new policy addresses your concerns there are definitely some stuff currently in the existing bug database that are clearly reasonable changes that should simply be applied and I think that some of the stuff that has come for like nine years that's sitting in open discussion states we may just close those and say please start again if you think this is still an issue but it's a great thing but it has to be done on a bug case by case I'm going to do that I'm going to help with the 3S and go through all of the bugs