 Those of you who saw Mehdi's talk that's from the DPL will have seen the slides where he mentioned what the motivation road naps can be and also trying to find some ways to actually get that rolling started. So this is what this part is about. Two mics, you can pass them around and one for passing around and one for running around there. So if you have a question or something to say, just be sure to write it down so you can get your question on video as well. Thanks. Hi. Everyone in the room saw the slides about the roadmap or not? If you didn't, raise your hand. Okay. So I'm going to show them quickly because we're a bit out of time. So it was about to work on a document with the goals that we set for the project, have agreed in the decision process on how to get things on the roadmap and what's part of the roadmap and what's part of the roadmap. It's similar to what we used to have, the release goals, but they were bound to release and only cover the technical aspect of the project. In the roadmap, we could have ideas about the infrastructure, about the documentation, about the organization, about how to spend money, whatever. So it's not only technical aspects about packaging or getting stuff done in the archive. So there is a roadmap document in Gobi. Yeah, some people found it. I've put some items on the agenda. So we are going to discuss first the... So nobody has the responsibility today on the roadmap. So at some point, there is a delegation that should be done so that the team in charge of that will be able to have legitimacy to decide on the content of the roadmap. And for that, I put some ideas about the tasks of that team. Then discuss which team should be in charge of that. Is it an existing team? We'll create a new team to take care of that. And then get some ideas from the actual content of the roadmap. I shamelessly took what was for the release goal. So it was about SMAR. It was about finding an advocate for the idea to make sure work is getting done. It's not useful to have something if there is no one pushing to get things implemented. And it was about having an idea which is generally... where there is generally consensus. Otherwise, we will not asking the team to decide blindly on the things. There should be debate among developers and enter the richer consensus. And if not, the technical committee could decide which side to take or which solution to implement because that's their role today. So first one, tasks. So for me, it was about getting the proposal, reviewing them, ensuring that there is some currency to not have conflicting ideas or ideas that overlap. It was about deciding about the content of the roadmap. So after the review, they make a proposal for the project. It gets published. And... Well, yeah, that's all. Having predict reviews because at some point maybe some ideas are not relevant anymore. So you can drop them from the roadmap or get new things added. And measurement of the results was added by Pub maybe. So for me, it was the status. Get or the progress. So maybe we should add the... It's part of the review. If you review something, you have to measure it. So look at how... Yeah, yeah, sure, sure. It's above. It's supposed to be, okay. So I have two different comments or questions. The first one is what's the positioning of this compared to DEP, the enhancement proposals? Maybe you can answer this one. I can answer the other one after. So for me, the DEP is a tool to get things documented and implemented. It could be the same process. But there is no one. I mean, managing all the DEPs and making sure that there are still active advocates, that they are still making progress if they need something or not. DEPs can also be seen as focused on the technical side, which is not the whole point. And also, it's not convenient to show what are the current things. So we could have another document somewhere on the Wiki, for example, to say, this is the roadmap for 2006, 2016, maybe with links to DEPs. But yeah, DEPs could be a way to implement the roadmap. I discussed yesterday a bit with Sam about DEPs as well. So basically, DEPs are maybe too descriptive. Roadmap is a bit higher level. Maybe DEPs are a tool to detail how we implement something in the roadmap and try to build consensus. And sometimes it can be also the other way around. We build a DEP, but it's not clear if we have some conscientious. So at that point, it might make sense to get back to the technical committee to sort of see whether it's good enough or not, if it can be blessed in some way. In that case, maybe it can be included in the roadmap or not. It depends on the level of the DEP. So for the reasons, we used to have a Wiki page. I can show you an example. So it's all on the Wiki. For example, if we take something that was documented. So you have a description and then the implementation details. You have advocates, some contact point if there is one. Same status of the work that has been done. Usually you can also find a link to the BTS with the user tags if people file bugs and tag it them properly. So you can see the progress of the goal. What about it? It could be as simple as that. It's actually different. People do have comments about this part? Or the task? Yes, actually. I'm all for more communication about how people want to improve Debian and more documentation about that. I see the point in having a team in charge of ensuring that the process stays alive that deals with the infrastructure to measure progress, etc. I'm not so sure about the fact that that team needs to be delegated. It seems more to me, similar to me to the policy team for example where people are just helping document the state of things rather than decide on the content of what should go up to the technical committee. That's the difference between policy and technical committee. The one thing that could be delegated is decide the content of the roadmap but that's a recursive power. You decide the roadmap and then you delegate the forward to decide what's in it. I wonder if we shouldn't think of, first, of what are the higher priorities. The powers that it gives to be on the roadmap and then decide if it should be a delegated team. If all the roadmap, that's what you wrote at line 10, if all the roadmap bugs are asses, then we need a delegation that overlaps with the release team. My proposal for this could be that the team is in charge of the paperwork but the actual decision of what's in their roadmap is taken by all the developers through voting. People propose goals, they get seconds for their goals and then eventually we vote which of those goals we want and which goals we don't want. Who votes? All the developers? The same process as the GR? Like a GR for the goals and whichever goal is on top of further discussion, it gets accepted and whatever is below further discussion doesn't get accepted. I'm usually not convinced. It's going to work like that. That was my idea. It's a way to see if people are agreeing with the idea, if there is some consensus but I think we can also discuss that on meeting this and see if there is a strong disagreement. I'm not sure there is a need, a real need to make votes on it. For the release goals, for example in the past, we didn't need to do votes and there wasn't big fights about what's a release goal and what's not. I don't expect it to be much different from what release goals used to be. There's a couple of release goals out there that we have not implemented yet and they've been there for 10 years. One of the problems I think with this approach that we've had was to define a goal with a deadline and then find out that volunteers are probably just not going to be able to deliver in time and then we had to sort of be flexible about how we interpret the release goal. If we had DEPs with owners or however you call that stuff people responsible for driving the progress until it gets to a point where the committee or the Debian Project at Large is ready to say yes, we will roll with this, we will take it and put it into the next release then maybe the motivation for the team leaders or these little task leaders, DEP owners would be hired to actually drive consensus within the sub-project, within the DEP so that they then meet the deadline. The difference is let's not declare a release goal in the beginning of the process and then fail to meet it. Let's make it clear that whichever team around the DEP manages to have something ready by the time that we need to freeze is going to be included and have it be more of a rolling process. I hope that's clear. I think what you're saying is we shouldn't commit to things before they're ready and if that's true then it prevents us from being able to use a tentative commitment to drive motivation to succeed at that commitment. That's actually like some, if we were all voting on them then I'm sure there are release goals that I could have helped with that I didn't know about but if I were confronted with them to vote on them then I would have known about them and I would have been more likely to help with them. I'm not saying voting necessarily is the only way to do that but I like some important publicity phase before something is done or not. Sam Hartman, I think I'm all for a publicity phase where people are trying to get support for cool goals and I think having process behind that, well having ways of doing that would be great but I think that should be well before the commitment phase. Lessons that was kind of hard for me to learn that Anthony Towns was very good at beating into people when I first joined Debian over half its lifetime ago was that the people who do the work kind of do get to decide what work it's done. If you don't, that basically Debian is about enabling people to do work it's not about mandating what work they will do. That's pretty early in our constitution and I get really worried about committing to things before they're ready because that sounds a lot like telling people what work they're supposed to be doing. I think Keith Packard was basically talking about this goal setting as a way to enable people to do work and to coordinate but it shouldn't be a stick to hit people with either to discourage them from doing work that is to say we shouldn't have anti-goals and it shouldn't be a way to force people into doing what you want them to do because both of those things don't work very well in Debian. Yeah, I have two remarks about that so indeed it's not a way to discourage individual initiatives it was actually part of my slides and the only thing I find interesting important actually for the team that will be in charge is that sometimes you can have two proposals which are conflicting and we have to make sure that all the items are coherent in the way we are going to make things in Debian and so for now there is the technical committee who handles the conflicts so we can say we have a process to have that for the commitment, time commitment it's actually not very important to say where it will be we can say when it's ready, like for the leaders what I see for the roadmap is a way to promote someone's work and by promoting it, hopefully you can get more volunteers to get it done and that's the most important part is make them more visible in what they do in the project Does that mean you're suggesting it should only be goals where someone is already taking charge of the work though or do you think we can also have a roadmap item where no one's doing it at the moment So are these goals with inactive advocates in the past didn't work pretty well? We can have some section with this this is something that should be done and then try to find volunteers to do the work but it should be advertised as not active I'm not sure how much it should be I think very very strongly that we shouldn't have goals that people haven't signed up to do work on because then it becomes a wish list we might have very good ideas or very bad ideas but we need some people to actually do the work and we can't and we don't want to force people to do work If we want a wish list, we can certainly have that but that's a different thing If we don't promote some ideas, they won't be done anytime in the future and we could say that for example ideas with no advocates could be part of the roadmap for 6 months for example for one year and if there is still no activity there, we could drop them but at least we try to promote the idea and gather volunteers for it I think that should be a different list basically I don't think that we should have ideas As I said, could be another section in the document If you're looking for something to do here, suggest a list that's fine but it doesn't necessarily enable people to do the things we want to enable by giving them kind of the mandate which I think a release goal or an item on a roadmap implies It can also become a kind of precursor stage that if you think something is amazing and should be on the roadmap then it's your responsibility to gather some people who do have the knowledge to do that work And then the roadmap team's role can be to make sure that you're thinking carefully about who you should be collaborating with in case you're forgetting people I think that's the part that I find most exciting that there could be a team that if I sort of say hey, I think that all of our foos should bar then they say, oh, that's great make sure you talk to this person who also does a foo then I make sure that I'm collaborating with the right people early on I'd like to second that idea I think one of the most important things that a team can do here is to avoid late conflict so it really is incredibly frustrating when you have some great idea and you're moving forward and there's a lot of momentum and you've talked to nine of the ten teams you were supposed to and team number ten is like, no, not in a million years, I would never do that and instead it's great to get them involved to have some people who help you get them involved early enough in the process and basically once you have enough advocates and stuff to be able to answer questions like, so if we were going to make Debian a better operating system for containerized software how would we go about it? would this be a reasonable way rather than getting 90% of the way done and then discovering, oh, no, someone who's in the critical path won't support it and I understand that sometimes the answer is, well, we don't know so you can only answer this, would this be a reasonable way not necessarily, is this the way we would choose because we don't normally, you know, we normally let multiple options flourish in parallel for a certain phase but at least learning the people who are going to be hard cells early can really avoid stop energy being injected I was just looking if there are questions about energy yeah, if someone can make the bet then that would be great so I guess we kind of agree on the idea of the tasks there's no disagreement about it so for the reason, the goals we used to raise automatically the severity to be important that allowed in the past people to ease and abuse so it doesn't conflict with the real stimulus perimeter the question is, should we keep it or not? I guess the question is also how this works in practice it doesn't necessarily make sense to remove lots of packages because they haven't yet got a new feature that is in the roadmap I don't know what other people think if it's not contradicting, there's a question of there could be bugs that are a bit wish list basically but removing the package won't actually further the goal so removing the package because, yeah I'm personally not for it you're for which? for removing packages because the bug wasn't... but imagine our roadmap feature is everything must be able to communicate by carrier pageant and we haven't yet implemented this in LibreOffice it doesn't, to me, make sense to remove LibreOffice because there's a wish list bug asking for it the severity is important, it's not really critical so it will not get removed well and still stays the release team jurisdiction to decide what to actually release and if we have a release goal that says we want CD1 to be entirely reproducible it's their call to wait or not wait until this wishful thing we might want to achieve at the end of the day is achieved or not so I'd consider the severity, bug severity quite a detail of this discussion really well not really actually because in the past it was really helping people I mean during the release goals to make things that are easily done in the archive so, yeah so Nils has about that well I kind of forgot that it's more of a detail but what I would like to see is a more extensive list of higher powers being on a being a release goal gives for example one thing that could be done is get FTP masters to prioritize new processing for packages related to a release goal that does not need to be done for each and every release goal but for some of them it could be really relevant to a faster new processing and that's a way to provide incentive for setting up a release goal again I'm not really convinced that the important wishlist thing either makes sense because these days the NMU policy is fairly liberal you can just NMU things with 15 days delay which is generally enough for almost everything so for me the main deciding feature is whether or not it's RC or not and it's going to be staying in non RC so it's not really a big deal for me at least at least we asked the question sorry? yeah, I think he finished something so everyone has access to Gobi so now the question is which team should get this organized my idea for now was the technical committee because in the constitution so the membership is limited in time so they had to renew the team members so you don't have people taking away the roadmap for a specific set of developers with some view it gets renewed and ensures that it remains neutral it's actually also the body in deviant to reserve conflicts between developers and offers advice so for me it's the best candidate for now and I'm not for creating new teams because I think we have too many already are there some comments on it? what's the position of the technical committee? well technically the technical committee hasn't taken any decision on that so I cannot say what the technical committee opinion is what I can say is my own opinion is that I can see the value of having the TC being that body the only thing I worry about is having the other appeal court that the TC is for the rest of the problems that said that kind of everything looks like it could be done by any other team or motivated members that would be setting up tools and having a nice process for that it's just wishful thinking that we can find people to do that or I'd be thrilled to discover that it is not so the technical committee could be the fallback but I don't think it's a good fallback I had kind of the same opinion about having the TC being the deviant policy maintainers that's more of a last resort idea and if we don't find anyone else to do that job then the TC might be the one to do it but it would be a better place if it were not the case So about the policy because it was the last point So in the constitution you already decided on technical policy so you don't have to maintain the package I mean technically but you could decide whether there was some disagreement on some points so it's not about getting technical work done on the package I guess For the roadmap it's not really a fallback I mean it's really the first one when you have conflicting ideas and when you have to get some compromises or consensus or some solution decided or whatever if you have another team which handles that they still have to go to the technical committee to get it resolved in some way So having a technical committee in charge of the roadmap is also a way to get the process faster Well then maybe we disagree on how the actual process of the roadmap would look like and what I understood from what you're saying is that you assume that there would be a lot of arbitration which I think might not be the case most of the things we can put on the roadmap are 98% of the time non-conflicting Yeah if it's true that most of the roadmap items are non-conflicting which is what I was going to say also then it seems that the purpose of the roadmap team would be to serve as like to provide motivation or to help people think through their ideas but then the roadmap team in my view a different vision of the roadmap team if you assume for now hypothetically there are zero conflicts is the let me help you do what you want team where you know if I come up let me do what I want team and I say hey I really want to change permissions on Varmail and sure we can eventually I'll have to make a patch to policy or whatever and get the technical committee to agree and I need to figure out who in the project actually cares about the permissions of Varmail then the let me help you do what I want team will say okay so you need to talk to these IMAPD maintainers and post fix maintainer and exit maintainer and even the send mail maintainer I'll be like right thanks I forgot about send mail and that is a success of the let me help you do what I want team and so I think that hopefully and so if you have people on the tech committee who sort of signed up to help arbitrate then that is sort of an anti-negative perspective that is like how do I help this suck the least and that mindset is a very different mindset from the mindset of how do I explore the whole list of everything going on in Debian to hand you more work to do to people to contact and I'm not responsible I'm just helping you figure out what you need to do so in that sense I think that there's different reasons to get involved in one or the other yeah I was actually trying to see the technical committee with new positive tasks instead of I think someone if they don't want that I mean I think they just pushed someone into the technical committee on the promise of it being a job where you had to have a responsiveness of one week in about an hour a week whereas this might be a rather higher work Sue I think it's very important that I would like to see the technical committee be perceived and move towards a mode where we are moving things forward in a positive way than rather than an anti-negative way I do think that the technical committee can do some of the do what do help me find the right people to talk to work we probably have good skills in that regard but I do think that ultimately you're going to have to do a fair amount of work up front of getting substantial energy behind your goal before you can claim any large project resource for review just to make workloads manageable okay the most important question actually about the team is are there some volunteers for the let me help you to do what you want to do thank you that's the second problem actually I would volunteer as long as there are many other people involved so maybe let me put it this way like if you're willing to possibly volunteer for that raise your hand this is not a commitment just curious if anyone else finds that idea interesting okay let me just get the names yeah really really keep your hands up and let him take the names yeah he's writing down some names you're not setting up for anything I mean so that we can discuss with people about their commitment to get that done and it's very important to not sorry what's the qualification to be on the team was the question you don't necessarily have to be very technical it should cover all what we do it should cover all what we do in Debian so in that way it's very important to have a diverse team not focused on the technical aspects so everyone is welcome even non uploading DDs even DMs even non DDs so yeah if you want to volunteer John Sullivan had his hand up to you just so you have that on the list any time just who is the realist okay your name is Kate right as unfortunate as it might sound for your grand plans this kind of looks like the project that we should have some sort of attempt out there and then iterate and trying to get the whole road across the whole thing and going directly saying the technical committee is in charge of arbitrating between the project and having a very complex process about that seems like too early for that and if we have a team of some people that are ready to announce a quickie thingy that we have on the wiki saying these are the constraints we want to have for roadmap items and we start with that and then if in six months we have a dozen of them then someone will come up with some system to make that more manageable and if in six months we have nothing then so I think my point exactly is that I think it just needs to be tried that's what we are here right I mean okay the second half of my point is that it just needs to be tried with a team of people that happen to be motivated and then we can re-discuss what exactly are so how are we going to do it we could start by creating a mailing list and start discussing how to make things making a call for proposals for example get things reviewed on some wiki page and then make some announcement this first set of proposals and yeah I don't imagine something complicated really my problem with this team so far or who is going to decide is this really sane because if we are only here to the okay you have a nice idea why not but it looks good does it really make sense so yes the good thing about the technical committee is that it's a technical body so if they sign up for something you have few chances of appeal within them so you're rather sure that you can go forward without having other people coming yes there are two points if there is a rough consensus on the idea there shouldn't be any need to go to the technical committee to decide on it so it should be pretty straightforward and then as didier commented I have as I said I have the feeling that they see themselves as a court to decide on problems which so it doesn't match what you said for the roadmap maybe the idea is that we drive them towards other people in Debian that could be interested and then we invite them to present their results to in Debian Devil to give two weeks for comments if there are no objections then we validate otherwise we maybe seek some advice from the technical committee like every developer they can still make comments so I don't think it's necessary to bind the process to some team and wait for their comments specifically or if someone is motivated by a project and he has a few negative reactions somewhat he wonders should I go ahead should I not go ahead I think it's still good I think they did not understand my point or maybe some other bad words but maybe they can what you can have people against for various reasons sometimes it's a good reason to stop but sometimes it's not a good reason to stop but I think earlier I think we have not much conflicts on the release goals and so if there is some conflict we could say ok it's not part of this roadmap of this year but the decision will be delayed for this specific point and then we publish the list that Yes for really technical goals you usually have consensus for more policy related goals I mean for example I try to drive a depth 14 on the bit layout I think I have a broad consensus around it but you still have a few people who say well this is useless because what matters it works for blah blah blah if there are only concerns about uselessness I think it's ok yeah but it would be nice to be able to I mean I'm a depth driver I'm not so confident yet to say to move it to the accepted so maybe TC could help here well I guess maybe a part of the question is if the technical committee is the kind of court or appeal then who makes an initial decision is that just a kind of consensus of a list or do we need or not any more formal way to make the initial decision amongst the people that's why I mentioned the delegation initially and for me it makes sense to make the team delegate well the technical committee has the power to offer advice that's clearly a case where we could just let me help you team could just recommend to the goal owner that you should go to the technical committee and ask for advice about whether it's an acceptable state or not I think that if you view the technical committee as a court of appeal and that's how you approach it you will regret that decision for a very long time I don't think people see it like that I hope they don't I'm just saying let's not start yeah yeah sure that's why I mean I proposed to the technical committee to take that insurance because I think they have real value on that they showed that they know how to discuss with people reach consensus etc there's still one global thing I think we should keep in mind is that it's quite unusual for the project to rely on having someone external say this is the good thing you should do it and having the technical committee vouch for all the things that are on the roadmap kind of changes this to if I want to do something in Debian I need to have someone say it is okay and that's where I would much much more like something where a team of motivated people prepare an initial roadmap ish that is good enough and then for things that that are controversial then we should have a wide project wide discussion anyway and if it's still very controversial and very important then at that point you can have an external body say okay well we spent some time thinking about it and it's important enough so that we rule that it is on the roadmap but having the TC agreement on all the roadmap items as default sounds kind of scary to me in a nutshell before finishing if you have a deep disagreement on some goals so obviously it's not a project goal so there is no doubt that item shouldn't be part of the roadmap yet until somewhere consensus is reached so it's up to anyone to comment on the ideas and say why it's important or why we shouldn't be doing it yeah so I think we are running out of time it's midday so the other section was about proposing ideas for the roadmap you can do it later in the gobby document yeah other questions okay anyway we are running out of time so thanks for being here we will stay in touch there will be some announcements soon I guess see you soon