DC13 Mentors BoF preparation Possible topics of discussion: - sponsorship-requests: 18 months in, does it work? what should we do now? → can we get some metrics from the BTS/UDD on closure of bugs, time from opening to closing by an upload? Seems like a great idea. I can mentor someone in writing that code. Who will write that code? (: Intent To Package bug close delay could be one metric Questions: What % of ITPs are closed by someone other than submitter? What does the mean+stdev of (ITP, RFS, upload) timeline look like? UDD has arrival date, and closed date -> of note, RFSs are closed manually but you can use the ITP closure date effectively as RFS closure, except for NEW processing plus Bart Martens and Monica have a script to close RFSs when package hits NEW -> move that to mentors.d.n? yes -> someone needs to file a bug and/or submit a patch to m.d.n -> someone needs to get in touch with Bart & Monica to suggest we do this -> action item'd! -> subjective impressions makes things easier to track probably bremner says we think it made things worse, in terms of mailing list traffic, but now metadata manipulation issue is fixed laarmen says debian-mentors list used to have more questions, and he liked that (I'd like if someone could verify this) maybe people are unaware of the debian-mentors mailing list we could test this by surveying people who submitted RFSs to sponsorship-requests Asheesh suggests that perhaps the reply-to for the bug when sent to the mentors list should be the bug+submitter, to keep the traffic in one place and make sure the submitter sees it (which the one person here who submitted an RFS recently semi-did not) and/or pseudo-header in RFS template that causes the submitter to receive updates and/or mail-followup-to and/or when people use "l" in mutt to reply-to-list, then they lose that reply-to data Perhaps using mail-followup-to plus reply-to might debian-mentors receives most messages in PTS forwarding - what can be done to make sponsoring easier, less time consuming and more attactive for sponsors? → training for new developers on how to sponsor Do we know why non-sponsor DDs don't sponsor? Could merge all the various lists of things to check as a sponsor URLs to those lists: http://mentors.debian.net/intro-reviewers https://wiki.debian.org/DebianMentorsNet#Metrics https://wiki.debian.org/SponsorChecklist https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package https://wiki.debian.org/DebianMentorsFaq https://mentors.debian.net/sponsors/guidelines http://firewoes.debian.net/ http://debuild.me/ http://ftp-master.debian.org/REJECT-FAQ.html https://wiki.debian.org/Games/Checklist https://wiki.debian.org/LucaFalavigna/NEWChecklist many checklists from individual DDs Discussion: Do we need packages to be perfect before they get uploaded? Sometimes people see issues in packages and report them to mentoree but then someone else uploads it and the DD with the high quality standards goes WAT bremner suggests: perhaps first upload could go to experimental with a lower quality threshold Upload "non-perfected" packages to experimental, iterate, then go to unstable. perhaps ftpmaster will reject them (great, feedback!) Issue with the iteration: the sponsor needs to commit to reupload once the issues are fixed. → more automated QA checks (see below) → encourage skilled non-DDs to do reviews (having "non-skilled" non-DDs doing reviews would encourage learning and increase the amount of review going on) → encourage skilled DDs to make mistakes while reviewing so that others feel it's OK could be we could modify their messages in transit to the mailing list → more publicity for sponsors. e.g. improve http://udd.debian.org/sponsorstats.cgi and push it to DPN or planet weekly My impression as a non-DD seeking sponsorship of packages is that fairly frequently a DD will come along and sponsor a load of packages in one go, then stop. They don't necessarily have any interest in the individual packages they are sponsoring and so it's unlikely they'll sponsor again unless they happen to have free time again. I've recently asked for repeated sponsorship directly with previous sponsors and had no reply at all (which I'm not complaining about, just pointing out my experience). - what could we do to make the sponsorship process less tedious? → throw in some debuild.me love into mentors.d.n (automatic package builds and checks on the built packages) → more automatic checks (https://wiki.debian.org/HowToPackageForDebian#Check_points_for_any_package) and write more tools -> firehose converters for http://firewoes.debian.net/ http://debuild.me/ → do we really need to strive for perfection before the first upload ("release early, release often")? → create a culture of sponsors listing "blockers" and "nice to fix" Possibility: writing a sponsor-package-check tool that would tell a potential sponsor a checklist of things to do or run to check a package. Who writes this tool? pabs is volunteering also possibly using e.g. lintian profiles - improving the culture of debian-mentors IRC and mailing list → getting more verbose help; less "RTFM" → moving from "troubleshooting" to "mentoring" → overall moving towards a more welcoming environment for everybody Letting DDs and non-DDs put up profiles in e.g. m.d.n for e.g. home town pride, language-, possibly timezone or skill-local-tutoring. Of course the mentors.d.n people are looking for webdev-knowledgable people. Please join #debexpo on oftc. ----- Action items: * bremner will ask Monica to make her script in m.d.n * asheesh has pinged a recent sponsoree to take a look at writing the sponsor-package-check tool