 Yeah, so David Bremner is going to lead us through the sponsorship booth. Thanks, David. So it's the end of the week and we're all tired. So I don't know, hopefully we can get a little interesting discussion going. I think it's not so interesting if I tell you what to think. So let's start with a survey. Who here is not yet a DD? Who's one or two, three, four? So you have experience of the sponsoring process from the the sponsoring side. And I think that's part of what we want to talk about today. And what's that? Fond size is too big. What's the feeling? Larger. Okay, how's that? It's okay. Okay, so who here is sponsoring regularly? So you notice I'm not raising my hand. So you might wonder why I'm doing this. Well, you know, somebody had to do it. Although after Ashish did a session, maybe somebody didn't. Anyway, I'm doing it. Okay, who here occasionally sponsors? So the rest of the DDs, essentially, occasionally sponsored. And so, well, I guess the first thing I wanted to talk about is why do we sponsor? I mean, so as individuals and as a project, why do we even have this process? I'm not saying we shouldn't have this process. I'd just like to articulate why I think it seems like a reasonable place to start to ask if we're doing this, why are we doing this? Anybody want the mic? Yes. I'm going to get some exercise out of Lucas today. Although actually Lucas is already in much better shape. We should swap. I should run the mic. Go ahead. To get upload rights, you need to have experience in packaging. And you don't get them, well, and you need to get the experience. So it's a chicken and egg problem. So to get the experience, you have to do the packaging, but you still need someone to actually upload it to the archive. So that's why we have the sponsoring process. It's necessary. So training. It also serves as a kind of mentoring, even if it's a one-off thing, not a stable relationship. Okay. I mean, I think as a project, that's the obvious goal, right? I mean, somebody yesterday remarked that most leaf packages are useless. They didn't say it quite that strongly. Okay. Lots of packages that first-time packages want to package have a fairly narrow audience. And, well, that might explain why they have trouble getting sponsors sometimes. But maybe that's not the main issue, right? So maybe it helps us be less, I don't know, pissed off at people for wanting to package obscure things when it's the process that's the point somehow. Okay. So there's injecting a little... Anybody else want to... Other reasons? I mean, do you think there's other compelling reasons that we should sponsor other than training and developing new, full DDs, eventually? In my case, I sponsored a package because I was interested in the package itself, and it added new features that I was interested in. Okay. So of course, that's perfectly legitimate. To have useful software, obviously. Right. So... Most of the sponsored uploads I've done were basically for people I knew, friends or old friends or ex-colleagues who asked me, can you help me here? Usually not because I thought it was useful, because in that case, if that's really something that I would do it myself, or not find out about it. But yeah, that's what I think. So, doing favors for friends. Okay. Sure. I could add guilt to that list. So, I'm orphaning a package, and I'm sponsoring it because I feel a bit bad about orphaning it. Why do I feel bad about orphaning it? Because upstream is great. So, anyway, that's a different story. Okay. So, I guess we have a variety of motivations. If we think about... I mean, some of the ideas we talked about in Ashisha's session involved sort of the project developing new methodologies and websites and sort of the project doing stuff. And I guess if we're going to do that, then we need a project motivation, right? I mean, if we see sponsoring as an extension of our own packaging, that's fine, right? Nothing wrong with that. But no reason that Debian should help us sponsor our pet packages any more than it does help us package them, I guess. So, I guess the biggest complaint... Oh, yes, this is a good question from Arnos, and I think we talked about this in Ashisha's session as well. But should we push people more to teams when they start out? I don't know. Plus one from Pap's. Anybody want the mic on that? Anybody think teams are a terrible idea? I know for a fact there are people within Debian that think teams are not... Certainly that they're not a panacea. But is there anybody who think that they're a bad idea for new packages? I guess it must depend on the team, right? So, I find a lot of responses that I write to mentors, which is not a huge number, but of the responses that I write to the list, a lot of them suggest teams for people to try. And so, I think it's all very well to say we should push people towards teams rather than mentors, but they don't know what team to go to. So that's part of the process. I think that most teams have the same problems as Debian mentors means long delays before someone replies, some RFS which aren't replied to, different requirements based on responding, even if it's a bit less of a problem for the different requirements, or if you have a problem, still apply. Right. It could be worse, in fact, on some teams than the general... I mean, I don't know that it is, but... Anything else about teams? People want to... Yes? I think that if you sponsor a package from someone, you are already a team of two persons, and I don't quite understand the difference or the distinction which is made between team maintenance and sponsoring. Maybe sponsoring is the most elemental form of team. Okay. Well, I mean, I guess we have sort of a generally positive feeling about teams, but it's not clear... I mean, I got one thing we talked about in the last session was, well, if we had some whizbang infrastructure, then it could somehow have team-specific aspects to it so that it could be reused for teams to manage their stuff. And I mean, in Package Pro, we somehow use PET as a way to manage this workflow for people coming into the teams. I mean, the way you request sponsorship is you work on a package, and it's observed to be done, but I don't know how... This doesn't work, right? If you don't have a homogeneous, very homogeneous setting. Okay. I guess from the sponsoring point of view, there are certainly issues, and I know that we have a few sponsors here and some on IRC. There's a question of waiting, long waits. I think what's more aggravating for people is that there's a high degree of uncertainty. So it's not just that it will take a while, but you have no sense of is there being progress made or are people just politely ignoring me because this is a really stinky piece of software? I took a simple approach to avoid that problem completely. I wrote a small page explaining when I was actually sponsoring, and it explains you have to approach me on IRC, do not send me emails, I don't want a backlog of sponsoring a request, and if you can't reach me, I'm not going to sponsor. So talk to me directly, live communication, and if there is direct communication, we can talk about sponsoring, if it isn't, well, I'm not going to keep an eye on what I could have been sponsoring somewhere else. There's like this mentor Debian Net site that's piling up with packages that could have been uploaded. We need to have a completely different approach to that to actually get those into the archive, I think. So who here prefers to be approached on IRC for sponsoring requests? So to each their own, I guess. So as she's talked about, some efforts to improve the feedback on mentors to make sure that people get some response. Their mail wasn't lost, for example. And I think that's a worthy goal. But looking at how sort of incremental a goal that is, and that we haven't managed to achieve that, is a bit worrying as far as more ambitious goals. So Arno mentions on Gobi here that there's a sense of unfairness from people. And we had this same discussion before, the sense that requirements vary a lot between sponsors. I don't know what the answer to that is. I think as long as sponsorship is a matter of individual developers doing it, then this will continue to be as idiosyncratic as we are. So that sort of segues into my next... All right. So does anybody have any ideas about this issue of fairness or perception of unfairness? First of all, is it real? I don't know. Obviously a perception is real sort of by definition. But do you think it is unfair that different sponsors have fairly wildly different, well, I mean, within policy and sometimes slightly outside policy standards? Joey would like the mic. Joey, the bearded guy. You were just stretching. I guess it is somewhat unfair, but I also think you can't really avoid that, because people are going to be different anyway. People with more experience are going to have stricter standards than fresh cities, simply because they have more experience in knowing where to look and knowing what to do before uploading. So yeah, it's probably unfair, but I don't think there's anything we can or should do about that. Unfair to people who are trying to upload, but also unfair to not just to them, but also people who are actually trying to use a package and find a slightly more buggy package because it was uploaded by a less experienced person who didn't see a bug before uploading. Like I said, it's not something we can actually do anything about, I think. Anybody else? So hopefully you can all see the various items on Gobi, and if some of them appeal to you, feel free to bring them up. So what about this concept of having a mentor's team? I'm not sure, so it's just a brainstorming idea. I'm not sure if I think it's a good idea or a bad idea. So we have a QA team, which takes care of lost and lonely packages, and is great fun to be on, I hear. Stop snickering. So this would presumably have a kind of similar role, would look at the lost and lonely, unsponsored packages, or maybe we would say, okay, you want to sponsor packages, great, please join this team and let's all work together this way. I mean, I don't know that you can force people, but you could suggest, right? I mean, say, hey, we think it would be great if people sponsoring would join this team and we'll be a bit more organized about this. So first of all, who thinks it's a terrible idea and we should stop discussing it right now? So that's kind of an endorsement. Who here would join such a team? Oh, you think it's a terrible idea. Good. I don't think it's a good idea, at least. We have a lot of teams that are not working very well and getting another one is not going to improve things. I think it's a lot better to point people to existing working teams and try to get their training there than trying to get the busy people that could have been spending some minute sponsoring to join up in a team that's not going to work very well because everyone is busy elsewhere. So I don't think we need yet another team, which I suspect will end up as a non-functioning team. So it's, yeah, it's certainly true. I mean, there won't magically be more DDs who are willing to sponsor because we call them a team, right? That's for sure. So how exactly do you think that team and how would that compare to the already existing mentoring scheme of Debian women? I really don't know that. So maybe you could tell me, can you tell us, me, ignorant me, about it? So my response is we don't need it because we already have it. We just need to advertise it more. Okay, so this is the mentoring team of Debian women? Yeah, I don't think of it as a team because it's meant to be one-on-one personal mentoring. Okay. But it's still, yeah, it's a mentoring effort. Yeah. So one thing that I'm not sure about in version 1.0 of this buff, Ashish said that he thought 20% of packages coming to mentors could go to a team. That number seems low to me, but I don't have anything to back that up. I mean, if really only 20% of the packages on the Debian Mentors list should be sponsored by some team, that leaves a lot left over, right? And so then the answer clearly isn't direct people to the right team. People have a better feeling about shall we all make up our own statistics? I mean, what's your... With regards to Mentors Debian Net, I think a lot could be done to make it more useful. Every time you upload a source package, it should be built automatically to see if it's basically building and logs should be provided if you want to look at it. It's running some tests, but we should do as many automated tests on the source as we can running it through the source checkers, the LinkedIn stuff, or anything we can think of that could improve the transfer, someone actually detecting problems automatically. Then the mentors, well, the sponsors would have less work because packages will be rejected earlier, and the sponsors would have an easier way of getting feedback without any humans being involved. So I just gave Ashish a mic because he's been working on expo.debian.net, which is a replacement for mentors. Is this on? Okay, hi. And so maybe the short form of your question is that mentors could provide a lot more information, or the sponsoring package site could provide a lot more information. Not just information, but also feedback to the people that want sponsoring. Right. Before people look at it, automated systems should look at them and... Can you just load a package from expo to show that it already happens? Can I load a package? I mean, you have the projector, so that would be helpful. I don't think I have an account or anything. Yeah, just on the web. Go to expo.debian.net, click something. I'm sorry I arrived late. It seems like what you talked about was having reliable information by automated tools that prospective sponsors can use to automatically check a package's quality without downloading the source package themselves as part of the sponsoring upload. And so here's an example package on expo.debian.net. You can see that there's a bunch of quality assurance information labeled info. For example, info package has lintian warnings. What are they? Oh, yeah, W package needs version to dev helper build depends. So this code is actually pretty modular. I've just done some of the work of polishing it up so it actually works. There's a lot more work that we could do. It's really easy to write new QA plugins also. And if you scroll down even farther, you can see there's a comment box, except you're not logged in. But were you to log in, you would see a comment box there. Okay. What is my name? What was the question? Increase the font size? Well, control plus. Yeah. Enough? See, if it didn't have all this shiny stuff on the left, we had the colorful stuff. One other thing I want to point out is there's a whole bunch of QA plugins, not just lintian. I think my favorite is that it checks the watch file to see if it's the latest upstream release. This tool does not build the packages. It would be definitely possible to add a QA plugin that actually does building and then checks it builds in a P builder. My perspective on this is that I want to just bring this site to the point where it can replace mentors.demi.net. I don't want to write all those QA plugins because I have so much else to do. And because I want there to be a much bigger community involved in editing this program. So I'm extremely interested in mentoring people who want to hack on pretty modular Python to add that functionality. And I can totally wave my hands at the end of this bath and talk with anybody who wants to do that. So I guess it's not so clear to me this notion of a mentor's team has much uptake, but I feel like it's worth floating and seeing if people think it could serve a useful function. I mean, people join the QA team, right? So people are willing to do somewhat onerous things. The QA team might not be the best example. People are not willing to join the QA team. But also I thought the QA team isn't a team, but it's an effort of all of Debian developers. Yeah, and known at the same time. Yeah, exactly. Okay. I think in terms of a mentor's team, I guess I have this microphone so I'm going to keep talking. In terms of a mentor's team, one thing that might be interesting would be to rotate. So one thing that Launchpad does for code review of the Launchpad code itself is they have a reviewer on staff always around an IRC, and that trades off in four-hour periods or something. So you always know that between 4 p.m. and 8 p.m. in some time zone, if you came onto IRC, somebody would be there and review your patch and give you feedback immediately. And that rotates. Does anybody think that would be a valuable structural addition? I mean, it's one of those non-packaging contributions almost, right, that we should think about. I mean, sometimes you're a little focused on packaging things, but... Lucas? You can ask... Well, let me rephrase. Who here has reviewed a package in the past year? Unmentoso? Anywhere at all for anybody. Okay. So of you, would any of you be willing to sign up for maybe once a week slots to be on the IRC channel for two hours to review packages as people hop into the channel? Maybe a few. Okay. What do you think? Can you hand? So... Go ahead. So the IRC channel is already pretty active with developers and non-developers reviewing each other's packages and stuff, so I'm not sure if that... I mean, it introduces a bit of predictability to the process, but I'm not sure how much it adds. Well, it seems like then maybe the reason... If you ask the question, why are people not getting their packages reviewed, maybe the answer goes something like, because they fail to show up on IRC. And if it's simply that they fail to show up, then what can we do to throw them into the IRC channel? So let me answer... respond to that briefly. Although I hate to get Ashish and I going here and bore the rest of you. People show up on IRC asking for sponsorship, and that almost never works. People ask for review, and that almost... Well, that quite often works. So for whatever reason, people hanging out on the IRC channel are less interested in actual sponsoring. I think it's also a question of perception. At least a couple of people I've spoken with that had been uploading to mentors and were really disappointed with the experience was basically expecting something more to happen. They were just sitting around hoping that the rest would happen magically and were very disappointed when it didn't. So telling them exactly what should happen next. Up front and in the face, maybe when they upload, I don't know how it actually should be done, but a lot of people expect Debian to fix the rest, and that doesn't work. I mean, one thing we could do is, when you upload your package to Expo, we could add some timeouts to the system and if within some number of days you haven't received any comments, we tell you, we send you an email saying, hey, has anyone reviewed your package? If not, then take these next steps like hop on IRC, and then if within M days it's not in the archive, then we ask you, is there anything you can do? Here's a list of things you can do. Do you think that just pinging the mentee would help that way? Can we work on writing that email after this? One thing that is a bit strange about Mentos, it's based on the assumption that every package should eventually get into Debian, which is not true because there are many more free applications available on the web, and we want to package in Debian. Lots of crap is available and we don't want it in Debian. And maybe what we should do if we use Expo as a central tool for reviews, it asks the person asking for sponsorship, for his motivations for uploading this to Debian and also ask for a state-of-the-art review of alternatives of that software available already in Debian and elsewhere. There is also a few lists with guidelines for sponsoring. I have one list and I'm aware of at least two or three others. And maybe the prospective packet maintainers should be pointed to these lists to see if they want to approach one of the authors and get them to be their sponsor. I know someone except emails, I get them on IRC and some explains that they want to have these set of requirements in place before they touch the packet. And I think just pointing people to the list of willing sponsors is more effective than hoping they will find them on their own. Or maybe just a common contact point for all the possible sponsors. We register that we are interested with the summary on what requirements we have and then everyone will have a list in a week or some mechanism to actually find potential sponsors. At the moment, I don't think there is any common or global list of potential sponsors in Debian. So it's an interesting idea. It would just be a wiki page, right? I mean something like that. You wanted to say something, Lukas? One thing along those lines that somebody else suggested is I guess DKG isn't here, so I'll repeat it for him. He said that he would be interested in reviewing and perhaps sponsoring one package per month. And it might be valuable for the expo site to let DD sign up to say, we will email you about one package per month rather than subscribing to the flood of requests for sponsorship mails that is Debian mentors. Is that something that other people are interested in? Just to get a show of hands? Like saying how many packages you would sponsor on expo per month or review, and then it'll email you exactly that many over the course of that month. I think one reason for the not huge amount of enthusiasm would be that people generally aren't interested in sponsoring everything. So I think there would need to be some sort of classification. Perhaps one for the mic. So during the discussions about how we can improve mentors.debian.net that led towards Debian Expo was the idea of metrics of a package. And you could use these metrics to match between people willing to sponsor things and the packages that they might be willing to sponsor. We came up with quite a lot of metrics. I think I reviewed some of the pages that people had written about how they, what sort of packages they sponsored and what their requirements were. And then came up with a list of things that would be either automatable or could have a questionnaire kind of thing that the sponsors could fill in. So things like the maintainer is in NM or is willing to enter NM. Is it a native package? What section is it? Does it have a watch file or not? Does it use CDBS? Does it use DevHelper? Does it use Managers scripts? Are there any LinkedIn errors? So that sort of thing. So you could more easily find packages that you're likely to be willing to sponsor. And on the other side of things, these sponsors could see that X number of Debian developers are willing to look at the package and or the package does not meet the requirements of these other sponsors. For the following reasons. Yeah, and then they could work on those reasons and that would improve the package and make it more likely to get it into the archive. Some of the metrics should also be properties of the person looking for a sponsor. At least I am more willing to sponsor packages with the prospective maintainer plan to actually spend time on maintaining the package. I get the impression that some people just do a one-off packaging effort and expect to drop it in the archive and then leave. I'm not really interested in sponsoring that kind of thing because that's just leaving them with the problem of keeping an eye on that package. So one of the reasons I want people on the IRC, I want to ask them how much time do you actually plan to spend on maintaining this package? How much time do you have spare to actually talk to upstream? What kind of process do they actually plan to use to maintain the package in Debian? And that's equally important to make sure that the quality of the packages in the archive stay high because it's not a dumping ground for whatever package you can find on the web. It's supposed to be an integrated and well-polished distribution. So along those lines, one thing that sort of bothers me is when I see a few times there's some maintainers of packages who aren't DMs and aren't DDs and who repeatedly seem to offer parentheses updated package to the Debian mentors list for sponsorship. And it's good that they're updating their package. That's excellent. The follow-up should be that somebody in the community has a DM or DD status so that we can stop being flooded with updated packages mails. And in fact, those people who are updating their packages are exactly the kind of people who are putting in the work that you're asking for. But we don't tell people very clearly like after N uploads, you should start hunting around for a DM status. And so I guess what I want to see us do is for packages when we see updated package on the Debian mentors list and again doing this myself, talk to those people and ask them have you considered getting DM status yet? I have a question. Why updated packages show up on mentors again? Because it's really easier to sponsor somebody who you already sponsored once and you know what this person knows already and well, I ask all my sponsors to send future requests directly to me and not to mentors and even new packages, completely new packages I want them to send directly to me. It would be really easy to build into expo as a workflow. When someone wants to submit a package it could be asked whether it's a new version of an existing package and then the former sponsor gets notified. To end quickly to answer the question a little bit about why people why we see these updated messages at all a lot of the when I have read these threads often it seems that the original sponsor didn't respond to this person's emails and this person has no idea why and simply thinks that they should go and ask the public list since they didn't get an answer from their previous sponsor. Most of the time they don't even ask the previous sponsor because even my sponsors sometimes do that and I reply to them in private and ask why didn't you ask me first I would upload it in 24 hours. Personally I must admit that I find uploading to mentors that is convenient for me. I have one place to keep track of the source package and some people have been sponsoring has not really a website where they can put the source. Can you speak up a bit? I can try. But I said I find fetching the source from the mentors site quite convenient for some people that don't have another place to put it and just getting it in there is more convenient for me so it's perfectly okay for me to update via mentors. I think the distinction is between putting stuff on mentors.dba.net or expo and posting a request for sponsorship on the mentors list and I think the question was why do people I've sponsored go to the mentors list and ask for sponsorship rather than coming back to me and I don't know I mean she's posited one possible explanation. People I guess on the other hand maybe not every sponsor feels like you do. Generally I sponsor very few packages but by the time I decide to sponsor something I decided to sponsor it for its full life cycle so other people might have different approaches they say okay I have time today I'll sponsor a package but it's not a well I guess it's decided where debconscious next year or 2013. To offer one more answer to why people don't ask their previous sponsor so in your case you told them but then for no obvious reason they then went to the list is that right yeah I mean he said yes so it's not that fact they may have missed that message because they were that paragraph because they were so excited about the rest of the uploading part and the fact that people should go back to their original sponsors isn't so clearly written in every single place in the documentation which where it should be. In all my responses to sponsorship request in my signature there's a link to my guidelines and one of the questions in there is what should I do if I will need another upload and in the answer I wrote that one should simply simply ask me again. Are there any mentees in the room who use debut mentors and try to get sponsored uploads? Okay we'll never mind that. So I guess we have about five minutes left does that seem about right? So I mean I think we had a reasonable fairly low key conversation today and between last debconf and this debconf we meaning Ashish replacementors.dbn.net so what's one thing that we can do before next debconf in this process? The mic. I think the matching system that Paul Weiss described would be a win-win both for the sponsors and the sponsors would save a lot of time in basically saying the same things and people having to wait longer than they should. What is the system? So he described a sort of set of features of packages which can be used to characterize an RFS and be matched against features that sponsors sort of consider as requirements to sponsor something and that could be used as sort of giving automated feedback to sponsors just by knowing what are the requirements of the sponsors and I was just wondering Paul is this an idea or is there a plan about implementing it and if there isn't maybe we should be asking people from Debian mentors whether anyone would be for you Paul is is there a plan to implement the packaging tagging stuff that you talked about as part of the inspiration for Expo I personally don't plan to do that Ashish might want to or someone else Debian mentors you could ask for volunteers in Debian I'm sure there's people with Python skills in mentors it's not a terribly complex thing yeah well I want to also ask is there anyone here who wants to help be developed Expo app and write some Python web code okay okay well we do have some other contributors who are showing up on IRC so hopefully hopefully they can but if not then like you said so Serfim are you willing to be the contact point for that idea put your name on a wiki and say hey if you want to talk about this let's okay but that's something okay great okay I have to tell my talkmeister that I'm out of time and we should any last comments we have lots of spaces to fill with talk today okay well thank you all for coming and thank you all for contributing to the discussion