17:02:31 #startmeeting 17:02:31 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:31 17:02:31 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:38 #topic Meet-Up with the ARB 17:02:53 welcome wendar and stgraber - thanks for making time 17:02:55 how are you doing? 17:03:09 surprisingly good for release - 1 week 17:03:14 :-) 17:03:27 doing well, just got back from Taiwan yesterday 17:03:38 how long have you two been on the ARB already? 17:04:00 since the beginning, so about 1.5 years 17:04:10 (3 cycles) 17:04:17 * cprofitt nods 17:05:01 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:40 I was concerned in January, it seemed we were behind and dropping further behind 17:05:53 but, we caught up over the past few months 17:05:55 What are the biggest challenges, you see, for the ARB moving forward? 17:06:22 On the whole, the same challenges as REVU had 17:06:40 How significant are issues with developer not responding to requests for feedback? 17:07:09 these aren't too bad, when we mark that we need feedback the entry disappears from our queue 17:07:25 the problem is more with developers needing a lot of help to get their stuff ready for Ubuntu 17:07:29 so compared to REVU, you think that would be improving the tools and educating the submitter? 17:07:53 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:55 yeah, developers not responding doesn't block us, they're just invisible 17:08:13 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:25 The queue is public 17:08:40 there isn't currently any rating system for how desirable an application is 17:08:55 but, right now we just try to get all applications through equally 17:08:57 wendar: I was thinking in relation to how LP works with bug heat... 17:09:21 and, really, it's the responsiveness of the developer that slows an app down the most 17:09:31 * cprofitt nods 17:09:32 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:36 ... and they were responsive 17:09:49 yes 17:10:12 right now we have ~6 old apps, from before we required the developer to do their own packaging 17:10:38 those require a lot more work than the new process, so we've grandfathered them 17:10:54 but, it does mean they're held up longer in the queue 17:11:09 I anticipate we can clear those out in this cycle 17:11:09 how many apps are in the que? how many were approved this last cycle? 17:11:21 there are a total of 20 apps currently in the queue 17:11:31 we launched 8 last cycle 17:11:46 there is one more that we approved pending 1 change from the developer 17:11:58 but, the developer hasn't gotten back with the fix yet 17:12:15 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:15 (it was one window that always appeared in Spanish) 17:12:48 all apps in the queue currently are new this cycle 17:13:04 I don't know how many came in total 17:13:15 I know we process 2-5 new apps each week 17:14:00 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:14 20 is without the ones that "need work"? 17:14:21 do you feel, as the communinty grows, that this process can scale? 17:14:43 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:52 stgraber, gotcha 17:14:55 we'll need new volunteers to scale up 17:15:14 dholbach: ideally we'd have some way of expiring these and rejecting them, but that's not possible in myapps 17:15:17 * ajmitch is sort of here now :) 17:15:24 ajmitch, go back to bed! :) 17:15:25 but, yes, the process itself is working fine (barring a few bugs in the submission system) 17:15:36 stgraber, do you know if there's a bug filed to make that possible somehow? 17:15:57 dholbach: yes, I talked to achuni about that a couple of days ago 17:16:00 and, we can easily accomodate new volunteers as we get them (even without making them full voting members) 17:16:15 we sorted through a few related bugs there 17:16:22 in the mail exchange somebody mentioned a arb-helpers team and I think that's a great idea 17:16:44 if that'd get rolling in Q, that'd be a huge win already 17:16:46 we're tracking the most critical bugs on our Agenda actions 17:16:47 https://wiki.ubuntu.com/AppReviewBoard/Agenda 17:16:51 how are applications taken in the que? First come first server or someother method? 17:17:16 1) pick off the quick responses 17:17:38 (like "you submitted a binary package, please submit a PPA...") 17:17:57 2) pick off those that need slightly more investigation 17:18:05 3) clear out old apps that need packaging 17:18:42 And, we each give slightly higher priority to apps that we've personally adopted. 17:19:02 To see that app all the way through to publishing. 17:19:22 so as a specific question... what has happened with TagPlayer? 17:19:55 That's one of the old ones, needs to be packaged. 17:20:19 currently in the staging PPA & I had highvoltage look over it a couple of days ago 17:20: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:20 It's been through several rounds with the developer. 17:20:39 Initially it wouldn't work installed in /opt, which is a requirement. 17:21:09 * cprofitt nods 17:21:28 dholback: what is "Q"? Quickly? 17:21:36 precise+1 :) 17:21:43 sorry :) 17:21:47 oh, that Q 17:21:53 some mythical as-yet-unannounced name 17:21:57 hi everyone 17:22:02 yes, the issues on our agenda page are the blockers for us 17:22:25 if those bugs in MyApps could be fixed, it would help enormously 17:22:39 there are also some bugs in Quickly that are blockers for those apps getting through 17:22:55 so, they should be the easiest to approve, but actually all require manual work 17:23:05 wendar: is there a way we the CC can help with those blockers? 17:23:30 czajkowski: probably not now, there was progress made on them this week 17:23:50 aye, those seem to be in hand 17:23:53 Is there any other kind of help you would like to see? 17:24:07 Thanks for the answers on those things... it has given me a better understanding of what hurdles the ARB faces. 17:24:22 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:35 They thought there were 70 apps pending in the queue 17:24:44 ah, good 17:24:56 so, were feeling a bit panic'd, and like the ARB needed a rescue 17:24:58 might the 70 come from this page maybe: https://wiki.ubuntu.com/AppReviewBoard/ToReview? 17:25:18 ah, so perhaps I should clarify the 70 apps figure 17:25:27 that is a different list than - https://myapps.developer.ubuntu.com/dev/arb/ 17:25:38 Jono asked me to provide stats on ARB apps in the queue 17:25:55 dholbach/dpm: where does that page come from? 17:26:02 right but that includes the needs-information ones we can't do anything about and that aren't visible in the queue ;) 17:26:07 wendar: I put that together a couple of days ago 17:26:11 so 70 was the sum of "Needs information" + "Pending review" + "Review in progress" 17:26:32 dpm: right, but the queue is "pending review" + "review in progress" 17:26:32 I thought they all were relevant 17:26:37 it required guessing the ID of the apps in needs info state, and they cannot be adjusted 17:26:39 okay, that makes sense 17:26:47 some will probably stay in needs-information forever 17:26:50 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:52 dpm: they are, this is why the bugs were blockers 17:26:53 or until we can get some way to expire/reject them 17:27:00 yes, as far as our process goes, "Needs information" is equivalent to "Rejected" 17:27:15 if the developer doesn't respond, they don't get help 17:27:16 as in "Needs information" there are also apps that need input from the ARB, due to the MyApps bug, as ajmitch mentions 17:27:34 but actually, this is just a number 17:27:34 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:42 yes 17:27:45 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:18 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:19 wendar: I think, personal thought, that reaching out one additional time has value... but worry about how that scales 17:28:19 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:41 okay, so that's our highest priority bug 17:28:55 so if there was any misunderstanding there this should clear it up :) 17:29:25 so there's more apps in the queue than 20, but it's hard to tell them apart 17:29:30 I do think having a target for applications getting from submitted to Review in Progress should have a target timeline 17:29:31 that means we can expect a quick bump of old submissions that need triaging, sometime in the next few weeks 17:29:45 dholbach, correct 17:30:39 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:39 dholbach: that's mostly due to an old bug. Apps are supposed to reappear in the queue once the developer responds. 17:30:58 dholbach: but, there's a chance we will need a feature to tell them apart in the future 17:31:03 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:14 cprofitt: I agree 17:31:36 cprofitt: right now our response time is good, generally less than a week for new submissions 17:31:54 great 17:32:13 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:14 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:16 it's working through & approving some of the older ones that takes a bit more time 17:32:26 er, decreasing :) 17:32:29 it looks like they may come back and simply say Pending Review again... 17:32:37 +1 wendar 17:33:05 wendar: do you think increasing the board would help ? 17:33:11 when did we start requiring apps to be packaged? 17:33:12 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:19 as I know asking someone to commit to 5 hrs a week for some people is not possible 17:33:29 cprofitt: in January we switched to requiring a PPA 17:33:47 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:57 highvoltage: yes, I think that's a great topic for UDS, maybe even a BOF 17:35:11 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:37 * ajmitch agrees, getting us in contact with the right people at the right time is very helpful 17:35:44 The other we could use help with is inspiring the developers. 17:36:03 wendar, by developers you mean app developers or Ubuntu (platform) developers? 17:36:17 Now that we've got the queue running smoothly, my greatest concern is the app developers who don't respond. 17:36:27 * ajmitch is sure the arb developers need inspiration at times as well :) 17:36:42 Why don't they respond? Is there some way we can serve their needs better? 17:37:17 I think the Community team could have some good perspectives there. 17:38:23 Whether we need to survey the app developers, or put together some training sessions. 17:38:27 Or other ideas. 17:38:46 I'm not exactly sure what's needed, but you all are aces at this. 17:39:00 wendar: would more board members help with your queuses/reviews? 17:39:26 czajkowski: yes, we'll need to restaff soon 17:39:32 only if those that join are going to be active 17:39:42 so you feel the issue with the Community team is resolved now and we ... sort of ... know how to move forward? 17:39:43 we're also seeking volunteers who aren't voters 17:39:58 wendar: similar to bug-squad and bug-control? 17:40:08 wendar: but do you think you need more than the current number, many more? 17:40:25 * 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:35 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:10 highvoltage: honestly, you're doing great, and I'd rather keep you on the board 17:41:27 highvoltage: the idea is that the board should mostly be doing the final review/vote 17:41:38 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:45 highvoltage: and the volunteers would be doing the leg work (some of us do both) 17:41:58 How is the communication working for you in the team? 17:42:15 * stgraber disappears, time for some food ;) 17:42:20 in the team, it's mostly IRC, and votes on the mailing list 17:42:25 stgraber, bon appétit 17:42:44 We have monthly meetings, which are good for catching up on any questions about more unusual apps or changes in process 17:42:50 wendar: thanks for the kind words :) 17:42:50 most of us lurk in #ubuntu-arb & comment when there are questions 17:43:05 we're pretty informal, and that seems to work well for us 17:43:17 so you feel you mostly pass on the baton quickly enough or document what needs to be documented? 17:43:33 yes, that seems to be working 17:43:38 wendar has done a great job with documenting stuff on the wiki 17:43:40 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:43 https://launchpad.net/~ubuntu-app-review-contributors 17:43:45 and, no conflicts whatsoever in the team, which is nice 17:44:22 dpm, sounds like that would fit well on the ARB agenda page :-) 17:44:28 dpm: great 17:44:44 * ajmitch needs to update the agenda page for the next meeting 17:44:54 sounds good 17:45:21 Is there anything else you can think of which would make apps in Ubuntu a success? 17:45:29 dholbach: for clarity, you mean your focus is on recruiting new members or non-member volunteers (sounds great!) 17:45:48 better tools for developers 17:46:09 Quickly is okay, but needs work. 17:46:21 Other tools have a pretty steep on-ramp for new developers. 17:46:39 part of that problem is too many options, I think :) 17:46:45 And, pkgme has great promise for automated packaging, but doesn't produce ARB-compatible apps yet. 17:46:57 dpm: I hear we're to talk to you about developer.ubuntu.com at UDS 17:47:29 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:34 ajmitch, you can talk to me about d.u.c at any time :) 17:47:44 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:50 Develop on Ubuntu, run everywhere. 17:47:51 wendar, not sure if we're talking about the same thing :) 17:47:56 ScottK: I'd be thrilled 17:48:09 * ScottK <-- Not volunteering. 17:48:10 ScottK, there is work on a pyqt template for quickly, by xdatap1 17:48:15 ScottK: darn 17:48:26 come on, I thought you'd be volunteering, ScottK ;) 17:48:30 dholbach: I was back-referring to 17:48:31 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:49 ah ok 17:49:22 dholbach: and, yes, adding arb-helpers to agenda page is good 17:49:33 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:34 dholbach: on going action item 17:49:50 so arb-helpers, team communication, restaffing, relationship with other teams and the like 17:49:56 yes, makes sense 17:50:16 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:23 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:50 It seems that it's easiest to keep motivated when we have a sense that things are rolling along well. 17:51:18 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:31 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:32 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:46 working together on something might be motivational as well 17:52:01 I pretty much hated working on ARB at that point, and heard the same from others. 17:52:08 dholbach: yes, I think that helps in the rare cases we have overlapping timezones :) 17:52:14 It's better now, it's managable. 17:52:15 I will try to make a session at UDS too 17:52:19 wendar: yes, that was a hard time to be on the ARB! 17:52:47 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:52 I feel we need to ensure that the ARB and the process is well supported and functional as the community grows 17:52:54 So, it's a matter of keeping that flow going, to keep motivation at a steady level. 17:53:31 reviewing just often isn't fun work 17:53:51 I think one of the harder parts is writing up a nice rejection email 17:54:06 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:08 ajmitch: would having 'stock' responses like bug-control help with that? 17:54:17 cprofitt: we do 17:54:36 * cprofitt nods 17:54:45 dholbach: Yes, thanks. 17:54:53 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:05 dholbach: It sounds backwards, but the two months of no external pressure was enormously helpful. 17:55:09 I for one appreciate the hard work you have all put in on the ARB. Thank you. 17:55:16 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:21 dholbach: Sometimes self-motivation is the best motivation. 17:55:38 for now I have no more questions, but sure will have more at UDS or before :) 17:55:43 Thank you all, we really appreciate the support. 17:55:45 * highvoltage usually finds motivation in wendar's self-motivation 17:55:56 highvoltage: agreed 17:56:06 I am good as well... this has been very informative and I too will ensure I make a session at UDS 17:56:10 highvoltage: aw, thanks :) 17:56:25 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:03 Thanks! 17:57:05 are there blueprints registered on LP yet to subscribe to? 17:57:19 dholbach: thanks, we'll keep on trying to get through the queue :) 17:57:34 ajmitch: We should probably create them. 17:57:45 yes, and work with dpm to get them in 17:57:47 I can only but join the thank yous for your hard work 17:57:48 thanks dpm too :) 17:57:55 Gwaihir, pleia2, czajkowski: more questions from you? 17:58:06 ys, thank you dpm 17:58:26 all set, thanks for coming 17:58:34 thanks to the cc for setting this up! 17:58:46 #topic Any other business 17:58:47 dholbach, nope, been following the discussion and it was pretty exhaustive 17:59:30 CoC comments review is up for the next meeting, does anybody have anything else? 17:59:43 we'll be doing a call for nominations for our new membership boards soon 18:00:08 no 18:00:24 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:44 * dpm goes for dinner 18:00:51 see you all! 18:00:57 thanks dpm 18:01:02 thanks dpm! 18:01:10 pleia2, thanks a lot for looking into this 18:01:12 I think that's it :) 18:01:28 ok perfect 18:01:45 I think that's a wrap - thanks everyone for coming 18:01:57 thanks dholbach for running the meeting 18:02:04 I'll attempt a summary to keep the discussion going and prepare for UDS 18:02:12 who wants to update the wiki pages? 18:02:25 dholbach: thanks, sorry I was a little late :) 18:02:29 Gwaihir seems to volunteer for chairing 18:02:41 ajmitch, man - that's totally understandable if it's 5 over there :) 18:02:47 dholbach, yep, count me in 18:02:48 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:57 I'll do that 18:02:59 thanks :) 18:03:02 #action Gwaihir to chair next meeting 18:03:02 * meetingology Gwaihir to chair next meeting 18:03:09 #action dholbach to summarise meeting 18:03:09 * meetingology dholbach to summarise meeting 18:03:14 #action pleia2 to update wiki 18:03:14 * meetingology pleia2 to update wiki 18:03:17 #endmeeting