 So I think we're going to get started. This is the new maintainer, Boff. Enrico Zini is going to be coordinating it. If you want to ask questions and stuff, you should raise your hand and try to get my attention, or get someone else to get my attention, if I'm not looking in the right direction. So Enrico. Thank you. Welcome to the NMFT-DAMAM Boff. And this is about the new maintainer process. The point of the Boff is to take advantage of the TEPConf to talk face-to-face between the people who are involved in the NM process. It's a good time to talk to each other about best practices, good ideas, and make a couple of decisions about a few things we're not quite sure. It's not the place to say, let's get rid of the NM Boff. It's not the place to say, I have this idea to redesign it completely from the start. It's the place to talk about what we have and spread a couple of good ideas about the details of what we have. Things to completely redo. There haven't been many proposals recently about completely redoing it, but it was a tradition in the past. And, well, not here. That's for another thing. It's for another place. There are notes about the whole thing. And they're on gobby. I guess by now you know how to open gobby connect to gobby.wnet and open documents. But there you have it. The file is DC11NMboff. Three seconds to open it. Two, one, OK. Well, not that it's particularly readable here, but since I don't know what else to show on the screen. No, well, I'll show a few more things on the screen. So I'll start with some news about the NM process. News number one, work that's been done here has it that mind changelogs is now passed. Who of you knows about mind changelogs? A few, OK, a majority. Mind changelogs is something that doesn't usually exist. It's a technical solution to a social problem. But it was put together like, let's see what happens. And it turned out that it really made a difference. Essentially, if you have experience in Debian and you join the NM process, we can now grab your name through every changelog in the archive, say something like that. And we get the full history of the work done by people. I was mentioned in a changelog in 1999, and that's the first time my name appeared in Debian. And then we go up from there, 2002, 2003, and so on. And then you see all the contributions of people in Debian. Enrico, do you use UDD for that? No, OK. Can't. Too slow. I mean, to get to it. I'm not sure there is the full changelog in UDD. And with this, you also see when you are not the author of the changelog, but also when you are mentioned by someone else, thanks for the patch and all this kind of stuff. Maybe there is the full changelog in UDD. OK, I think there is not. So this is actually more expressive. I won't spend much on technical details, but I can't use a SQL database for it, because I want this. I want to see this, and it doesn't appear here. And it's great, because if people don't package much, but they contribute loads of patches to the BTS, then you can see contributions. Hopefully, people say thanks to them. It's a good practice in Debian to do it, and people are doing it, so that's good. And it's really good. It does case-sensitive word match, so I built a custom index for it, and it's fast. It's case-sensitive, because sometimes you have somebody's name that capitalizes a name and not capitalizes a common word in English. And so we can find Mr. And in this way, but if you were case-sensitive, we couldn't find Mr. And. There's no Mr. And yet. And you can look for many things, and it will be odd. Well, that's roughly the same thing, because I'm the only Vee at the moment in Debian. But there you go. Extremely useful. Yeah, because it's been interrupted. And if you are an AM, you can use this to see what people already know. You can see whether people have experience in Debian, and you can just not ask questions. For very, very active applicants, you can just see, wow, how come this guy's not an ED, or this lady's not an ED? There's experience in Debian for years and continued work, like two uploads a month in the last three years. And it's non-trivial uploads, and I'm not going to ask any task and skills question. I'm just attaching the output of MindChangeLogs to the AM report and done. So that really made everything swifter. Now, it used to be the case before Debcom that such a query would take you about six minutes, and which kind of discouraged using it. Sort of, you used it when you kind of knew in advance that the person had lots of experience, because otherwise, I don't want to wait for like six, seven minutes for it to grab through every unpacked package in Debian to find things. But now, it's fast. It can be used like occasionally, any time, and so on. MindChangeLogs, it's not packaged, but there is a script in the NM templates, just as we have keycheck.shell, we now have MindChangeLogs, which is... That's it. Because, well, yeah, it's implemented server-side with a RESTful script, with a RESTful interface. And that's not RESTful, but it can also be RESTful and whatever. Okay, so that's something I really wanted to announce. Very happy about it. And there has been some work done on the new site. The new site is something that's been waiting for a couple of years to happen. We are redesigning the NM web interface. We've redone the database behind it, so that because the old one was old and crappy and a problem to work with, and there's many new things we'd like to do with the new site. And so the rewrite is on its way. The goal for the end of that conference was to have the old interface running on the new infrastructure with the new database. I'm not sure we'll get there, but we should get close enough, isn't it? Cool, yeah. And then that's the news at DebConf, besides that we went through a few to-do list items that needed discussions between dams and so on for old cases, like, well, whatever. And so, state of things, we now have more application managers than new maintainers, which is great, well, almost, because I think as soon as we assign the many new maintainers that apply during the DebConf, that won't be the case anymore, so feel free to still volunteer. And the NM process takes less. The number of standard template questions has been reduced from 100 to, like, 20. And we have mind-change logs to help with not asking questions. Debian has changed. People can now approach NM with experience, because you can get sponsored uploads and you can become DM. And you can be, if you don't package, there's a non-uploading way of becoming a DD, which does not, you know, it avoids the problem of people who are not interested in packaging, adopting two copy packages just to get into NM. And even for people who choose not to upload, a lot of the NM process is just looking at existing work, because it is possible to start doing a lot of things in Debian without having an account. That really helped. I need to thank, you know, Debian mentors and every team that we have. That's a point of entry for new people. That is great. And then, damnation is becoming a thing of the past. The damn queue tends to be small or empty. And that is another very encouraging thing. However, front desk needs help. If you are an application manager and you'd like to lend a hand to front desk, assigning new applicants to AMs, for example, we could use that. It's not something that takes a lot of time, but it's something that could use responsiveness. Assigning an NM to an AM takes one minute, maximum two, five if you want to do a good job and find an appropriate AM for that NM. But it'd be good if it was done within a couple of days, maximum a week from when the NM applied. So, yeah, if you are an application manager and would like to help from desk, come talk with me or Ganev, we could use the help. Wow, colorful. So, things not many people know but should. MindChangeLogs mentioned. And DD Portfolio. How many of you know about DD Portfolio? OK. DD Portfolio is another big brothery kind of thing. And you put an email address in there. You do not press Enter. You press Tab. Careful. And it will look up a few things that it can know and you can fill in the rest. OK, that sounds about right. And what you get is a list of links about the person, which besides the usual DDPO page and so on, there's links to the activity in the BTS. So, if you see somebody has kind of packages with, somebody doesn't seem to have much package activity, it's easy to have a look at the activity on the BTS. How responsive they are, if they are polite, replying to users, if they engage in flamers, and all that sort of things. That also helps in having a good idea about applicants. And again, avoiding assigning tasks or asking questions. You look at that, you see persons being submitting loads of packages for RC bugs and the packages are well formed. Do you ask them about doing an NMU? Maybe yes, because you want to try and make an NMU doing properly the delayed upload queue and so on. You see somebody has sponsored them in NMUs. Then why bother? And so on, and there's lots of things around here. Right? I'm not the author of it, but the author is Jan Didi, which at the moment, Jan Dittenberger, who I don't think is here. And if you have by any chance any sort of similar information about people, karma, whatever page that you maintain, get in touch and have it added here. Yes, Jan Didi Berner, sorry. Oh, which also has the nice practice of publishing the source code URL at the bottom, which is good. OK, so any questions so far? Then we can move on to discussion. So one problem that is a huge source of delays in the NM process is either the NM or the AM becoming unresponsive during the question and answer part. Something that has been suggested several times already of the history is that we have a way to track who is waiting for whom. Yes. Is it something that you are planning to add? So thanks for the question. Let's go to the first two items to, proposal items to discuss. Well, there's one is, well, open parenthesis. One feature of the new NM site is going to be that, sorry, I'm getting distracted because I want to move it here without killing anybody. OK, so one feature of the new NM website is that it won't have explicit fields for tasking skills past or PNP past, but it will have a log which will allow all sorts of more finer granularity things to happen. Well, we need to see how to update that log, but the idea is that application managers can say, finally replied after a month or waiting or whatever, and we can get more status about how things are going. And we can more reliably compute and we can more reliably see when things get stalled. Obviously, we do not want to add work to the AM. We do not want the AM after receiving each mail to add log into the site and say, oh, I see an email. That's not a good idea. But the idea is to have that in the database and then see what's a good way to update it. Ben, another idea that's been mentioned several times in the past is to have a sort of, for each application, have an email alias, the archives mail. And there have been proposals about having all the conversation go through a sort of mailing list for two people. But that's something we don't like because it makes the communication not personal. You do not want to communicate with your application manager through databaseid at an mdebian.org. It'd be nice to have a humane conversation. But an interesting, possibly better way to do it is to have an optional archiving alias that can be used just by CC-ing mail to it, which has the downside that people may forget to CC. That's something we can talk about, what could be a good way to do it. The idea of having a mailbox with a conversation so far means that if the AM goes missing in action, we already have the conversation. We do not need to chase the AM or the AM about retrieving the mailbox. And we can look at where the conversation got stuck and try to ping one side or the other if an alarm shows up that nothing happens there for a while. Just a brief comment, not a question, about the deep portfolio you mentioned earlier. I think that it is anyway a good practice to anyway ask the applicant to provide himself a list of the things he has done and things are mostly helpful for the projects. Because it helps him realizing what is helpful and what is not, what he is doing and what not. Yeah, we do that. Yeah, yeah, I know. And that's helpful. It was a comment on that. Maybe the mail that we used to ask can be rewarded. Even the advocate is supposed to send as many pointers as possible to somebody's activity. There's a question over there. And the question over there. OK. Yeah, we're getting the point of tracking the communication among AM and AM. In my quite limited experience as AM, I've been doing that for one year with something like five applicants. So essentially, you get stuck in two ways as you well know. One is when the NM stopped replying and one is when the AM stopped replying. So what I like about the idea of having some sort of bug log associated to the process is that we can automatically devise some warnings like, OK, this way, this direction of conversation has been stuck for two weeks. Let's see what's happening. And that would require no chasing action on your part. So we'll be able to do that automatically. And to be honest, I'm personally quite extreme, so I'm not sure I see the point of not having the conversation public. But I can understand why some people see that a problem. But for instance, I think it would be acceptable to have the conversation visible to project members, maybe not on some web page, but just archive on some machine as we do for other email aliases. And your point on not liking having ID at something, which is a very, very valid point, can be resolved by having, for instance, I don't know, a different domain where you have both of the applicant and the mentor and the EM, which have some address at mentors, the BNR, or something like that. So I like to communicate with the real email of people. Sure. It can be something which, I mean, I think it's a matter of feeling. You don't want to send an email to 6324 at something, but maybe you can send an email to your AM at some domain. I even like the idea of having the personal AM email involved in that. I've seen AM conversations that really ended up personal. And I'm even reluctant to open those mailboxes outside the AM process. People have been saying, sorry, I haven't replied to you in the last month. I was in the hospital for depression or something. You do not want to do that. So it's nice to have a personal conversation among people. I would like to keep that very humane side of it. Sometimes I feel bad when I don't review things to kind of reply to this private conversation and maybe provide extra information. It's something that should be done, but I'm like, sorry to interrupt you guys, but and something else was mentioned. I have an observation there. Well, in the MIA process, we use an email address that is composed with the ID and some other part from a QA server. There's a lot of scripts there that log this information in a mailbox. This address has been added to the BCC field. So it can be implemented like that, like having an address that say the conversation log and tell your NM that he can put the address when he wants to this conversation to log on the server and the same with AM. So you can choose which email you want to get in the mailbox log. And also, well, I was thinking about how possible it will be like for putting all the AM reports public, not public, but accessible for the, I don't know, the new maintainer committee or something like that. Yeah, opening them up to the NM committee is interesting. Can somebody out that as a proposal? We need to talk about it, especially because the AM report includes the mailbox of the conversation. And that would be the only thing that worries me, because I mean, yeah, sometimes I've seen something that shouldn't go in front of an audience. But maybe the best way could be to have a BTS sort of email. So it can also be to get people used to CC the BTS in relevant conversations. And that's a test. I think that, well, given the change between Zach and you right now about how this would be useful to have the whole communication archived and this debate about privacy, if each mail, well, this is like only half solving, right? But if each mail could have a pseudo header saying whether to archive or not, whether this is personal or not. Mail follow up too doesn't work. So why should that header work? OK, then next point, yeah? I don't want to leave that point quite yet. I want to, I think it would be exceedingly valuable to have these messages logged. And I want to know if we can find some solution that you like. But I also kind of want to ask, just to get a sense of how other people feel, do other people feel that it's really important that the email address that appears between the NNM and the AM in their email addresses, is it really important if they're personal email addresses or is it really important, is it OK that that be a forwarding address? Who here thinks it's really important to be a personal address? I know you do, obviously. OK, and who here would prefer it be some forwarding address that does archiving, like Zach was proposing or discussing? OK, so reasonably split, I guess. Yeah, I would say I would prefer to have a vote between people who have read those mailboxes. Yeah, I know. That's kind of unfair for me to say it, but that was part of my decision. And I think... Well, I think it's normal that right now, given that the others are personal, people go into personal communication. I think the question is whether for the process it's useful to have those personal communications. So maybe, I'm sure you have a more informal opinion, and probably it is, but I mean, it must not necessarily be in person. I mean, other projects for joining are having fully public discussions and you put on the table what you've done for the project, and if you have something personal, maybe you find some peer in the community that you are in touch with, and you move that part to the private email. Would some of you have problems applying or have had problems applying if the conversation with your AM were public? If I... I know, but... If I can give my input on that. I mean, I have been part of the front desk. I'm not anymore right now, since a few years. But I think it's very important that the AM process is personal. Precisely because it has to be a learning experience for the NM in very many cases. It has to be a case where the NM has to trust the AM that what they're discussing will be done in a right way. And if you take away a personal aspect from that, I think you will lose much more than just... Yeah, just the ability to get things done right. I think that would be the worst mistake you could ever make. Of course, you can still communicate through all the email addresses if that's necessary. But just the fact that you're adding this thing which is then the formal part of... I think that would be a very bad mistake. I just wanted to comment on the idea of mistakes themselves, which happened during the NM process. That as an applicant, you often do make mistakes when there are specific questions that are asked. And while as a full member of the project, you probably will make some mistakes in public, I think it's nice to be able to make some mistakes in private and have somebody show you how to make the mistakes, how to get out of them during the exchange without having to feel like... I mean, I think we could discourage some contributors if we forced them to make a whole bunch of mistakes publicly initially. Yeah, we're kind of mixing up about 10 issues here now, though, because what we started off from saying is that it would be useful to know who has sent emails when. This already would be solved if, for example, you have a magic email address, you CC. All it needs to do is record who has sent that email, record the headers even. I mean, that would already be a big advantage. And I kind of believe that that's depersonalizing the process. I also, again, I think it's slightly, though, artificial, just to say, even if you did have it going through another address, which I don't think is necessary, I think that's a bit artificial, so it's a big problem. I have all the time conversations with bugger numbers, but also have a personal conversation with who I know is behind that. I don't think it's a big issue personally, but as I say, I think CC's seeing something is going to be enough to achieve what we want. You don't need to argue about whether it's private information, so that's a completely different issue. I think I'm happy with CC'ing bug-style things, and if people have something private to talk about, they can avoid CC'ing, and that really helps also to kind of learn how to split public and private conversation, so I can only see merits in that. And I guess we can kind of agree to go on that way. And then there was another kind of interesting tricky point I'd like to discuss, we are a bit short of time, but so teams as the main entry points in Debian. There was something that was raised, there's pros and cons, and can't make up mine yet. So here's the story, at the moment people do stuff, well, the process comes from a time in which people did stuff on their own, and then joined it, Debian didn't know anything about them, asked them loads of questions to try and figure out who the hell they are, and what do they do, and if they can do it, and then decide. And we are moving towards, we've already moved towards something where people start to do things in Debian, in the bit of Debian they like, and then we look at that and say yes, that person needs, well, when they actually need an account, or we'd like to give them voting rights, they apply, and yeah, they get voting rights and accounts and so on. Now, maybe it's the time to document that the best way, the suggested way to enter Debian is to join a team, and wait until the team tells you, yeah, do it, you're ready. Because that would, in part, discourage people who want to join just to have an at Debian org address, which we get sometimes, and it would say, look, you work in Debian, you will be told when it's time for you, and at the same time encourage Debian teams to be proactive until valuable members, yes, valuable members you have to encourage them to apply. So, that is something that, it looks quite good to me. You risk having, it's not a nice word, that was in my private notes, sorry. You risk encouraging a sort of attention-seeking behavior in teams, which could be, worries me a bit, but at the same time, you teach people to work in teams. It's nice to have people that join Debian, get used, you know, come from teams, know how to work in a team, and it's a chaotic system, you kind of set it in motion and you have no idea what's going to happen. So, ideas please. I think it's also a bit of a risk that you might discourage people who are socially awkward. Well, no, I do not want to say that's the only way to join Debian. No, but if you're going to say that's the recommended way, you might discourage them, not saying they wouldn't do it, but you might discourage them, it might be an issue. I should have thought about that. Yeah, but I'm not sure we have still that many socially awkward people completely working alone in Debian. There is still one thing that improves the world, and forces this problem is that when you want to apply, you have to apply yourself. So what about nominating people and just closing the... Because if you want to become a DD, you have to decide, you have to think about it, and maybe you think about it too early or too late, and then you have to fill a form, and then you are an NM. So what about nominating people and allowing existing DDs? Well, I want these people to enter the process, so I open a slot for him. What about that? It's not that different from what we have, because it's not just about filling in the form, you need an advocate. So it's already a kind of two-way negotiation. I want to do it, says the applicant. I want to have you, says the advocate. And only when there's that handshake, when we have that handshake, the name actually shows up in the NM website. So it's mostly a sort of image we present, whether we require one first or the other first. I'm more comfortable to ask the applicant to apply first anyway, because some people may feel pressured into applying, they see their name show up, and it's like getting volunteered for a job or something. You would sort of want to... Yes, Benny? Oh, sorry. Yeah, I think you're right that it's mostly about the image that you present. I think you're right that right now it is a two-way handshake, and I think that your point was really about it should... It would be nice if it were... If there were a clearer way that we encourage DD to ask new maintainers to apply. Yeah. And maybe you and I can... Or maybe you and I and he can work on some text for the NM website to change that, and maybe we can send a DD email and so on. Yeah, that'd be good. Benny? So one thing that we talked about in the DBN Woman Prof yesterday was what to do with the people that come to DBN as a whole and want to help but don't know where to start. And one really good way to help those people would be some sort of matching them into teams to start off with things. So I was hoping that you, who has this matching skills thingy with some DBN women people, and Enrico can talk about this afterwards because I think that this is a really big hole that we have at the moment for these people. And so ideally they would be matched into a team where the team needs help to be done for new people, perhaps somehow with a mentoring process as well. And then eventually these people are already working in that team and then can go forward onto NM from there. I'm sorry I did not understand much. I thoroughly apologise. It wasn't getting here loud enough for me to hear it. Can we just talk about it later? Yeah, sure. Yes? Okay, later. It's getting late, okay. Yeah, sorry. So that's one thing that, okay, we can discuss. It's, you know, still in the air, but it could be a worthwhile image change. I don't know. Then one thing we need is to bring out the message that any Debian activity should be visible somehow if possible. If you run any group in Debian that does anything, whatever, try to acknowledge the work of people as much as you can. It is not something that needs saying because it's something we do already, but in case you forgot to do it in your team or something, find a way to do it because it means that when somebody from your team should become a DD, it means they go through an M fast because you can just point at the work they've done and, yeah, sure. No need to ask, no need to argue, no need to anything. So I don't know what could be done besides mentioning it here. We can put it in the DNM website documentation, but nobody reads it unless applicants. So maybe if people watch the video, if you watch the video and you manage a team, remember to acknowledge every activity of your members. DD portfolios, tile things archived, publicly archived mail English, report pages, BTS logs, whatever. Anything goes as long as you can point, as long as the advocate can point at it and say, look at that, they're really good. Give them an account, yay. Okay, then do we need separate templates for non-uploading DDs? That's a bit technical, not many application managers have handled that, maybe we asked them, but it kind of goes, and also do we need special templates for special groups like Web Team? My opinion is no, and I'll put that in as the start of the discussion. My opinion is no because the templates are templates and the application manager is supposed to not just send them as they are, but adapt them to the kind of person they have in front of them, which usually means removing questions and occasionally means adding a couple more. Actually removing questions, I mostly did it for all the templates, so there's not many questions left to remove. So I would say no, but on the other hand, the actual bits of the templates sometimes are to be fixed. Again, that would be the job of the application managers. So unless you think otherwise, again, I think there's only one AM that has done non-uploading DDs so far, so I can talk to him, but do we need special templates for special groups like the Web Team, something you can chime in if you think it could be useful? But unless we hear otherwise, the way forward would be to just expect that application managers will adapt the templates to the person they have in front. And do we have any non-uploading NMs in the queue? Do we have non-uploading NMs in the queue at the moment? People were one. I think there is at least one right now. They may or may not transition into an uploading DD. I'll look into that later. Maybe I'm not up to date. Maybe there's a visualization issue in the web page. Oh, this is interesting. Erico. Yeah, sorry. The problem of the specific questions for non-uploading DDs is strictly related with the questions. If you are full DD as AM and you ask questions about specific tasks and non-uploading DDs, you can be able to evaluate the answers. This is a problem in my opinion. So maybe it could be useful to have some questions specific. I mean, maybe about Web Team stuff or translation stuff. But on the other hand, we need to be sure that AM knows about that. Right. Good point. If I understand you correctly, the point is that there's no need to make special templates because the AM is supposed to mix and match and personalize the messages, obviously. But it's good to have more team-specific task-specific questions at the moment most of the questions are about packaging. We started collecting team-specific sets of questions. We need more. So if you have a team and you would like... Please contribute questions about the way you work. They're useful for the NM process and they're also useful for people trying to join the team. They can go there, try to answer the questions, see if they have a clue about what the team is doing. Just on the uploading and non-uploading distinction, from my point of view, I think we've done a really good job with the last couple of years, encouraging people in principle that non-packaging whatever people should also apply. Obviously, maybe we need to advertise that a bit out further outside the project and get more people in. What I'm a bit worried about is in exactly the same time frame, I think we've made things much less welcoming for what we would see as regular uploading DDs. For example, from my point of view, although it's not an intention from FD or whatever, there's been a big push to people that you shouldn't apply for NM, you should go off and become a DM first and maybe you've not got enough packages, you don't really need to be a DD at all. Could we have a clear statement somewhere that this is not a requirement, that DM is purely an optional, helpful thing? Sure, DM is optional. DM is just documented as the preferred way to do it. One big example is the Pearl team. The Pearl team does not need DM. If you are in the Pearl team, forget about DM, not needed. People will sponsor for you as soon as you snap your fingers, you just commit subversion and stuff end up in the haircut. Get, sorry, get, get, get, get, get, get. I'm running out of this work. And so that's like the first example of you don't need it. Time's up. Damn, I really wanted to do the next bit. So yeah, you will see applications turn down and suggestions to become a DM when somebody apply and they maintain like one package with minimal work. Because maybe they joined the process a month before. Sure, but some people will also, some people, yeah, I'll finish to answer this, some people will also, because we have abbreviations that are not easy to understand, some people will advocate for NM when they meant DM. So I have a duty when I see that somebody only maintains one package to ask, are you sure this is not an application for DM? And I need to do that. So the point is not that if you maintain one package you don't get in, the point is that the advocate, if you only maintain one package, the advocate should say why they're advocating for NM and not for DM. Okay folks, time is up. I think we should continue the discussion later, but the video team needs a chance to take a break and we have another talk coming up in 15 minutes. So thank you, Enrico.