=== smb` is now known as smb === doko_ is now known as doko === greyback is now known as greyback|lunch === plars is now known as plars-away === greyback|lunch is now known as greyback === rsalveti` is now known as rsalveti === Ursinha` is now known as Ursinha === AlanChicken is now known as AlanBell [16:57] o/ [16:58] 0/ [16:58] o/ [16:58] o/ ;) [17:00] o/ [17:01] * dholbach pings the rest of the CC folks [17:01] o/ [17:01] wendar, do you know if anyone else of the ARB said they were able to make time? [17:01] ajmitch said he'd try, but it is 5am there [17:02] I'm sort of around and not for long :) [17:02] yes, impossibly early - I guess I'd send him back to bed if he'd show up :) [17:02] ok, let's get started then :) [17:02] #startmeeting [17:02] Meeting started Thu Apr 19 17:02:31 2012 UTC. The chair is dholbach. Information about MeetBot at http://wiki.ubuntu.com/meetingology. [17:02] Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired [17:02] #topic Meet-Up with the ARB === meetingology changed the topic of #ubuntu-meeting to: Meet-Up with the ARB [17:02] welcome wendar and stgraber - thanks for making time [17:02] how are you doing? [17:03] surprisingly good for release - 1 week [17:03] :-) [17:03] doing well, just got back from Taiwan yesterday [17:03] how long have you two been on the ARB already? [17:04] since the beginning, so about 1.5 years [17:04] (3 cycles) [17:04] * cprofitt nods [17:05] you've had quite a lot of challenges during this time: getting the board set up, the infrastructure changed - how do you feel things are going now? [17:05] I was concerned in January, it seemed we were behind and dropping further behind [17:05] but, we caught up over the past few months [17:05] What are the biggest challenges, you see, for the ARB moving forward? [17:06] On the whole, the same challenges as REVU had [17:06] How significant are issues with developer not responding to requests for feedback? [17:07] these aren't too bad, when we mark that we need feedback the entry disappears from our queue [17:07] the problem is more with developers needing a lot of help to get their stuff ready for Ubuntu [17:07] so compared to REVU, you think that would be improving the tools and educating the submitter? [17:07] we could keep rejecting them all until they send us something that's perfect, but my guess is that we wouldn't have anything in extras if we were doing that [17:07] yeah, developers not responding doesn't block us, they're just invisible [17:08] I apologize for not being more familiar with the ARB que, is it public? Do you have any way of knowing how anticipated an application is? [17:08] The queue is public [17:08] there isn't currently any rating system for how desirable an application is [17:08] but, right now we just try to get all applications through equally [17:08] wendar: I was thinking in relation to how LP works with bug heat... [17:09] and, really, it's the responsiveness of the developer that slows an app down the most [17:09] * cprofitt nods [17:09] so if it was easier for the submitter to get it right, you feel the general process and tools would be good enough and things would get in in a jiffy? [17:09] ... and they were responsive [17:09] yes [17:10] right now we have ~6 old apps, from before we required the developer to do their own packaging [17:10] those require a lot more work than the new process, so we've grandfathered them [17:10] but, it does mean they're held up longer in the queue [17:11] I anticipate we can clear those out in this cycle [17:11] how many apps are in the que? how many were approved this last cycle? [17:11] there are a total of 20 apps currently in the queue [17:11] we launched 8 last cycle [17:11] there is one more that we approved pending 1 change from the developer [17:11] but, the developer hasn't gotten back with the fix yet [17:12] how many of those 20 that are still in the que were there are the start of this cycle... and how many new ones came in? [17:12] (it was one window that always appeared in Spanish) [17:12] all apps in the queue currently are new this cycle [17:13] I don't know how many came in total [17:13] I know we process 2-5 new apps each week [17:14] but, I don't have a count of how many are brand new each week, and how many are a developer submitting a response to an existing request [17:14] 20 is without the ones that "need work"? [17:14] do you feel, as the communinty grows, that this process can scale? [17:14] dholbach: right, because we can't see or update the "need work" one, so we consider them as not being in the queue [17:14] stgraber, gotcha [17:14] we'll need new volunteers to scale up [17:15] dholbach: ideally we'd have some way of expiring these and rejecting them, but that's not possible in myapps [17:15] * ajmitch is sort of here now :) [17:15] ajmitch, go back to bed! :) [17:15] but, yes, the process itself is working fine (barring a few bugs in the submission system) [17:15] stgraber, do you know if there's a bug filed to make that possible somehow? [17:15] dholbach: yes, I talked to achuni about that a couple of days ago [17:16] and, we can easily accomodate new volunteers as we get them (even without making them full voting members) [17:16] we sorted through a few related bugs there [17:16] in the mail exchange somebody mentioned a arb-helpers team and I think that's a great idea [17:16] if that'd get rolling in Q, that'd be a huge win already [17:16] we're tracking the most critical bugs on our Agenda actions [17:16] https://wiki.ubuntu.com/AppReviewBoard/Agenda [17:16] how are applications taken in the que? First come first server or someother method? [17:17] 1) pick off the quick responses [17:17] (like "you submitted a binary package, please submit a PPA...") [17:17] 2) pick off those that need slightly more investigation [17:18] 3) clear out old apps that need packaging [17:18] And, we each give slightly higher priority to apps that we've personally adopted. [17:19] To see that app all the way through to publishing. [17:19] so as a specific question... what has happened with TagPlayer? [17:19] That's one of the old ones, needs to be packaged. [17:20] currently in the staging PPA & I had highvoltage look over it a couple of days ago [17:20] it looks like you have a number of interesting problems to tackle - do you have a priority list of "meta issues" you'd like to fix (or see fixed) in Q? [17:20] It's been through several rounds with the developer. [17:20] Initially it wouldn't work installed in /opt, which is a requirement. [17:21] * cprofitt nods [17:21] dholback: what is "Q"? Quickly? [17:21] precise+1 :) [17:21] sorry :) [17:21] oh, that Q [17:21] some mythical as-yet-unannounced name [17:21] hi everyone [17:22] yes, the issues on our agenda page are the blockers for us [17:22] if those bugs in MyApps could be fixed, it would help enormously [17:22] there are also some bugs in Quickly that are blockers for those apps getting through [17:22] so, they should be the easiest to approve, but actually all require manual work [17:23] wendar: is there a way we the CC can help with those blockers? [17:23] czajkowski: probably not now, there was progress made on them this week [17:23] aye, those seem to be in hand [17:23] Is there any other kind of help you would like to see? [17:24] Thanks for the answers on those things... it has given me a better understanding of what hurdles the ARB faces. [17:24] In terms of the CC specifically, I was concerned about our relation to the Canonical Community Team, but now I think that was a simple mis-communication [17:24] They thought there were 70 apps pending in the queue [17:24] ah, good [17:24] so, were feeling a bit panic'd, and like the ARB needed a rescue [17:24] might the 70 come from this page maybe: https://wiki.ubuntu.com/AppReviewBoard/ToReview? [17:25] ah, so perhaps I should clarify the 70 apps figure [17:25] that is a different list than - https://myapps.developer.ubuntu.com/dev/arb/ [17:25] Jono asked me to provide stats on ARB apps in the queue [17:25] dholbach/dpm: where does that page come from? [17:26] right but that includes the needs-information ones we can't do anything about and that aren't visible in the queue ;) [17:26] wendar: I put that together a couple of days ago [17:26] so 70 was the sum of "Needs information" + "Pending review" + "Review in progress" [17:26] dpm: right, but the queue is "pending review" + "review in progress" [17:26] I thought they all were relevant [17:26] it required guessing the ID of the apps in needs info state, and they cannot be adjusted [17:26] okay, that makes sense [17:26] some will probably stay in needs-information forever [17:26] dpm: is there any process to 'drop' apps after a certain period of time is the developer does not respond to a request? [17:26] dpm: they are, this is why the bugs were blockers [17:26] or until we can get some way to expire/reject them [17:27] yes, as far as our process goes, "Needs information" is equivalent to "Rejected" [17:27] if the developer doesn't respond, they don't get help [17:27] as in "Needs information" there are also apps that need input from the ARB, due to the MyApps bug, as ajmitch mentions [17:27] but actually, this is just a number [17:27] dpm: I knew that we couldn't see some apps, and there were some that the developer had responded to but who hadn't resubmitted for review [17:27] yes [17:27] This might be a good question for the CC: whether it's worth putting together some more caring way to reach out to developers who haven't responded in a while [17:28] what I'm trying to say is that what we are discussing here is not the size of the queue, so we shouldn't put too much focus on it [17:28] wendar: I think, personal thought, that reaching out one additional time has value... but worry about how that scales [17:28] after a lengthy discussion with achuni on this the other evening, I think we'll get a way to be able to manage the apps in that state [17:28] okay, so that's our highest priority bug [17:28] so if there was any misunderstanding there this should clear it up :) [17:29] so there's more apps in the queue than 20, but it's hard to tell them apart [17:29] I do think having a target for applications getting from submitted to Review in Progress should have a target timeline [17:29] that means we can expect a quick bump of old submissions that need triaging, sometime in the next few weeks [17:29] dholbach, correct [17:30] so trying to sum up the discussion up until now there seem to be difficulties or possible improvements in 1) the review infrastructure, 2) the packaging/distro bits, 3) the workflow and 4) the team [17:30] dholbach: that's mostly due to an old bug. Apps are supposed to reappear in the queue once the developer responds. [17:30] dholbach: but, there's a chance we will need a feature to tell them apart in the future [17:31] it is outside of our control if the applications have issues (though tools provided to developers could help)... but ensuring a time from submission to an application getting reviewed is important. [17:31] cprofitt: I agree [17:31] cprofitt: right now our response time is good, generally less than a week for new submissions [17:31] great [17:32] I do think it would be nice to know that an application has been 'in and out' for a developer to fix an issue [17:32] cprofitt: in terms of priorities for next cycle, I'd like to first focus on clearing out the remaining backlog, and then on increasing our response time [17:32] it's working through & approving some of the older ones that takes a bit more time [17:32] er, decreasing :) [17:32] it looks like they may come back and simply say Pending Review again... [17:32] +1 wendar [17:33] wendar: do you think increasing the board would help ? [17:33] when did we start requiring apps to be packaged? [17:33] wendar: maybe a bit off topic for this meeting, but do you think we could bring up the arb-helpers idea at UDS? it sounds like a possible way to get some of the usual ubuntu developers (like motus) involved [17:33] as I know asking someone to commit to 5 hrs a week for some people is not possible [17:33] cprofitt: in January we switched to requiring a PPA [17:33] So I'd like to reask the question about the relationship with the Community team in the light that the particular "70 apps" number was not a worry for the community team. You felt that in trying to help we were putting too much pressure on the ARB. If the Community team can help in the future, how do you think we can work together to ensure the Free Software app developer process succeds? [17:33] highvoltage: yes, I think that's a great topic for UDS, maybe even a BOF [17:35] dpm: I see two greatest areas of help, one is where you've been very helpful in the past, which is maintaining the contacts inside Canonical to get our bug and feature requests through for the submission site and developer.ubuntu.com [17:35] * ajmitch agrees, getting us in contact with the right people at the right time is very helpful [17:35] The other we could use help with is inspiring the developers. [17:36] wendar, by developers you mean app developers or Ubuntu (platform) developers? [17:36] Now that we've got the queue running smoothly, my greatest concern is the app developers who don't respond. [17:36] * ajmitch is sure the arb developers need inspiration at times as well :) [17:36] Why don't they respond? Is there some way we can serve their needs better? [17:37] I think the Community team could have some good perspectives there. [17:38] Whether we need to survey the app developers, or put together some training sessions. [17:38] Or other ideas. [17:38] I'm not exactly sure what's needed, but you all are aces at this. [17:39] wendar: would more board members help with your queuses/reviews? [17:39] czajkowski: yes, we'll need to restaff soon [17:39] only if those that join are going to be active [17:39] so you feel the issue with the Community team is resolved now and we ... sort of ... know how to move forward? [17:39] we're also seeking volunteers who aren't voters [17:39] wendar: similar to bug-squad and bug-control? [17:40] wendar: but do you think you need more than the current number, many more? [17:40] * highvoltage would probably be better in a arb-helpers kind of team than on the arb team itself (since I can't contribute to the levels that the others can every week) [17:40] dholbach: I think so, the clash in perspective was really just a difference between "panic mode" and "the queue is running pretty well now, let's work on other things" [17:41] highvoltage: honestly, you're doing great, and I'd rather keep you on the board [17:41] highvoltage: the idea is that the board should mostly be doing the final review/vote [17:41] I feel we're not going to resolve all open issues (points 1) to 4) I mentioned above) now and specific UDS sessions for all of them might help - right now in the CC meeting I'm personally mostly interested in the ARB team aspects (if that's alright :)) [17:41] highvoltage: and the volunteers would be doing the leg work (some of us do both) [17:41] How is the communication working for you in the team? [17:42] * stgraber disappears, time for some food ;) [17:42] in the team, it's mostly IRC, and votes on the mailing list [17:42] stgraber, bon appétit [17:42] We have monthly meetings, which are good for catching up on any questions about more unusual apps or changes in process [17:42] wendar: thanks for the kind words :) [17:42] most of us lurk in #ubuntu-arb & comment when there are questions [17:43] we're pretty informal, and that seems to work well for us [17:43] so you feel you mostly pass on the baton quickly enough or document what needs to be documented? [17:43] yes, that seems to be working [17:43] wendar has done a great job with documenting stuff on the wiki [17:43] highvoltage, here's some info on the team, which exists already, but is inactive: https://lists.ubuntu.com/archives/app-review-board/2012-February/000388.html [17:43] https://launchpad.net/~ubuntu-app-review-contributors [17:43] and, no conflicts whatsoever in the team, which is nice [17:44] dpm, sounds like that would fit well on the ARB agenda page :-) [17:44] dpm: great [17:44] * ajmitch needs to update the agenda page for the next meeting [17:44] sounds good [17:45] Is there anything else you can think of which would make apps in Ubuntu a success? [17:45] dholbach: for clarity, you mean your focus is on recruiting new members or non-member volunteers (sounds great!) [17:45] better tools for developers [17:46] Quickly is okay, but needs work. [17:46] Other tools have a pretty steep on-ramp for new developers. [17:46] part of that problem is too many options, I think :) [17:46] And, pkgme has great promise for automated packaging, but doesn't produce ARB-compatible apps yet. [17:46] dpm: I hear we're to talk to you about developer.ubuntu.com at UDS [17:47] If Quickly could be replaced by something Qt/PyQt based then it could be used to target multiple platforms. I think that would be exciting to app developers. [17:47] ajmitch, you can talk to me about d.u.c at any time :) [17:47] wendar, I just thought since the arb-helpers mail was from Feb, it might fit well on the agenda page, so you can track it better [17:47] Develop on Ubuntu, run everywhere. [17:47] wendar, not sure if we're talking about the same thing :) [17:47] ScottK: I'd be thrilled [17:48] * ScottK <-- Not volunteering. [17:48] ScottK, there is work on a pyqt template for quickly, by xdatap1 [17:48] ScottK: darn [17:48] come on, I thought you'd be volunteering, ScottK ;) [17:48] dholbach: I was back-referring to [17:48] I feel we're not going to resolve all open issues (points 1) to 4) I mentioned above) now and specific UDS sessions for all of them might help - right now in the CC meeting I'm personally mostly interested in the ARB team aspects (if that's alright :)) [17:48] ah ok [17:49] dholbach: and, yes, adding arb-helpers to agenda page is good [17:49] yeah, I felt that we wouldn't be able to cover all aspects (like packaging problems, infrastructure improvements, etc.) in this meeting, so maybe the community/team aspects were probably of most interest in the CC meeting [17:49] dholbach: on going action item [17:49] so arb-helpers, team communication, restaffing, relationship with other teams and the like [17:49] yes, makes sense [17:50] personally without my CC hat on, I'm interested in a lot more than those, so I'll make time at UDS to be in the sessions :) [17:50] In that context, I'd say our greatest concern is how to recruit new volunteers, and how to keep up motivation in existing ones. [17:50] It seems that it's easiest to keep motivated when we have a sense that things are rolling along well. [17:51] sometimes my review time is a bit more sporadic, though highvoltage & I are trying out getting together on irc once a week to look at things [17:51] I could imagine that motivation in review teams is often very closely tied to getting thing through, so having moments of success - where you know you're happy, the submitter is happy and lots of users are happy as well [17:51] It was pretty discouraging back in January when we were behind, dropping further behind, and getting almost daily messages asking for status updates. [17:51] working together on something might be motivational as well [17:52] I pretty much hated working on ARB at that point, and heard the same from others. [17:52] dholbach: yes, I think that helps in the rare cases we have overlapping timezones :) [17:52] It's better now, it's managable. [17:52] I will try to make a session at UDS too [17:52] wendar: yes, that was a hard time to be on the ARB! [17:52] ajmitch, even if you don't - getting a mail from your team mate saying "hey, I figured X out, I submitted it to the branch" is very nice and motivational :) [17:52] I feel we need to ensure that the ARB and the process is well supported and functional as the community grows [17:52] So, it's a matter of keeping that flow going, to keep motivation at a steady level. [17:53] reviewing just often isn't fun work [17:53] I think one of the harder parts is writing up a nice rejection email [17:54] wendar, I can see that pressure doesn't help if you face a lot of problems - and it is a hard problem to solve, but also a very important problem to solve - I hope with multiple hats on that was understanding and diplomatic enough :)) [17:54] ajmitch: would having 'stock' responses like bug-control help with that? [17:54] cprofitt: we do [17:54] * cprofitt nods [17:54] dholbach: Yes, thanks. [17:54] cprofitt: it was cases like zero-ballistics which I rejected the other day, where the app was GPL but it depended on an 'open-source' but non-commercial library that took some time [17:55] dholbach: It sounds backwards, but the two months of no external pressure was enormously helpful. [17:55] I for one appreciate the hard work you have all put in on the ARB. Thank you. [17:55] it has been very helpful to hear of all this from you and get a better overview over what you are working on [17:55] dholbach: Sometimes self-motivation is the best motivation. [17:55] for now I have no more questions, but sure will have more at UDS or before :) [17:55] Thank you all, we really appreciate the support. [17:55] * highvoltage usually finds motivation in wendar's self-motivation [17:55] highvoltage: agreed [17:56] I am good as well... this has been very informative and I too will ensure I make a session at UDS [17:56] highvoltage: aw, thanks :) [17:56] I'd like to thank you all for the hard work you put into this. Making apps a success in Ubuntu is more important than many realise, so I hope you will keep up the good work and ask for help if you need any. [17:57] Thanks! [17:57] are there blueprints registered on LP yet to subscribe to? [17:57] dholbach: thanks, we'll keep on trying to get through the queue :) [17:57] ajmitch: We should probably create them. [17:57] yes, and work with dpm to get them in [17:57] I can only but join the thank yous for your hard work [17:57] thanks dpm too :) [17:57] Gwaihir, pleia2, czajkowski: more questions from you? [17:58] ys, thank you dpm [17:58] all set, thanks for coming [17:58] thanks to the cc for setting this up! [17:58] #topic Any other business === meetingology changed the topic of #ubuntu-meeting to: Any other business [17:58] dholbach, nope, been following the discussion and it was pretty exhaustive [17:59] CoC comments review is up for the next meeting, does anybody have anything else? [17:59] we'll be doing a call for nominations for our new membership boards soon [18:00] no [18:00] we've agreed to do away with regional boards and the new boards will have meetings at 12:00 UTC and 22:00 UTC respectively, just waiting to hear back from a few board members about which timeslot they prefer so we know how many spots we have to fill [18:00] * dpm goes for dinner [18:00] see you all! [18:00] thanks dpm [18:01] thanks dpm! [18:01] pleia2, thanks a lot for looking into this [18:01] I think that's it :) [18:01] ok perfect [18:01] I think that's a wrap - thanks everyone for coming [18:01] thanks dholbach for running the meeting [18:02] I'll attempt a summary to keep the discussion going and prepare for UDS [18:02] who wants to update the wiki pages? [18:02] dholbach: thanks, sorry I was a little late :) [18:02] Gwaihir seems to volunteer for chairing [18:02] ajmitch, man - that's totally understandable if it's 5 over there :) [18:02] dholbach, yep, count me in [18:02] I can update the wiki, but if someone else could write the summary for this meeting that'd be great (I've written a lot o them lately) [18:02] I'll do that [18:03] thanks :) [18:03] #action Gwaihir to chair next meeting [18:03] ACTION: Gwaihir to chair next meeting [18:03] #action dholbach to summarise meeting [18:03] ACTION: dholbach to summarise meeting [18:03] #action pleia2 to update wiki [18:03] ACTION: pleia2 to update wiki [18:03] #endmeeting === meetingology changed the topic of #ubuntu-meeting to: Ubuntu Meeting Grounds | Calendar/Scheduled meetings: http://fridge.ubuntu.com/calendar | Logs: https://wiki.ubuntu.com/MeetingLogs | Meetingology documentation: https://wiki.ubuntu.com/meetingology [18:03] Meeting ended Thu Apr 19 18:03:17 2012 UTC. [18:03] Minutes (wiki): http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-04-19-17.02.moin.txt [18:03] Minutes (html): http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-04-19-17.02.html [18:03] THANKS EVERYONE