[00:00:29] awjr: did brion leave? [00:00:39] https://gerrit.wikimedia.org/r/#/c/58332/ < i am desperate to see this merged for tomorrow [00:00:55] brion already verified it "Looks fine to me, except a double-escaping problem. :)" [00:01:17] ^ awjr so the js has been reviewed ... [00:02:10] oh, sorry, should've looked at previous comments [00:02:56] i just had to switch on the a/c for the first time this year - it's currently 83F in my house and im sweating like crazy, i think my brains are starting to boil [00:03:00] "fine except for problem" is not a mandate to merge [00:03:20] im taking a closer look at brion's comments now [00:03:46] MaxSem: is search currently being broken for everyone on a windows phone sufficient? :) [00:04:07] i dont think that's his point, jdlrobson :p [00:04:30] I can start cursing every WP owner in Twitter. not like they're not guilty [00:05:04] awjr: it also points out at how woeful we are at prioritizing code review. The original patch was posted on the 9th April so a fix has been sitting here for 6 days without attention till today but that's an orthogonal conversation... [00:05:11] i wish i knew the solution to this [00:05:14] jdlrobson: why was the search output double escaped to begin with? [00:05:21] awjr: it always has been in production [00:05:39] it's just previously we only did autocomplete on terms which were at least 2 characters long [00:05:44] now we do it for 1 character long strings [00:06:18] jdlrobson: re the prioriziation, today was the first i've heard of the issue, and there's nothing in mingle tracking it - so unless im told otherwise, i use the cards in mingle to determine code review priorty [00:06:49] awjr: the bug came up after last weeks deployment [00:06:55] we'd already done prioritization at that point [00:07:07] this is a problem of 2 week iterations :) [00:07:19] can we /should we add bugs mid iteration [00:07:20] ? [00:07:26] priority can change at any moment - it's not frozen in place at the start of an iteration [00:07:55] we can totally add bugs mid iteration, but that's up to Maryana (as is prioritization of said bug against the rest of the work for the iteration) [00:07:56] anyway tangent conversation - is there any reason we can't merge this code? [00:08:29] i can't find ori or brion or juliusz (for obvious reasons) who are my usual go to's in this situation [00:08:39] anything can change at any time, but prioritization is up to Maryana, and as long as she's (or whoever is the product owner) is aware of the potential cost of introducing new work mid-iteration, it's totally fine [00:08:43] and it's currently listed as a 'major' bug https://bugzilla.wikimedia.org/show_bug.cgi?id=40986 [00:09:33] I see no point in dragging bugs other than really complex ones into mingle [00:09:33] and you added the work to the iteration yourself by going ahead and doing it, even though it wasn't added to the story wall :p [00:09:47] for this, MaxSem [00:09:48] awjr: i ALWAYS give bugs priority [00:09:57] bugs are a penalty of bad development you [00:09:57] v [00:09:59] so we can have them prioritized against the other stuff we're doing [00:10:02] you've said this before yourself [00:10:15] yes, i don't disagree, that is not my point [00:10:40] awjr: i think there is obviously a discussion to be had right now - but right now the question is what's stopping us from merging this code? [00:10:45] my point is this was totally invisible to me as was its priority - we've otherwise been tracking bugs on the story wall [00:10:54] it's fully unit tested and everything [00:11:43] jdlrobson: i dont feel confident enough with the JS to merge this - the way the double escaping is being handled doesn't seem right to me, but i dont have enough context to feel confident in this [00:12:30] * Maryana reads up [00:12:33] if brion come's online either today or tomorrow am and is happy with this patch and michelle is ok with it can we merge this? if so i will send a mail [00:12:41] awjr: but i really think using mingle for bugs is broken [00:12:47] we have a tool for that - bugzilla [00:12:51] jdlrobson: of course [00:13:01] if something is marked of high importance i automatically prioritize that over new stories [00:13:04] (in regards to merging this post cut-off) [00:13:25] i review the bug queue every morning [00:13:37] jdlrobson: and that is totally invisible to the rest of the team unless you put it in mingle. also, a 'high priority' bug isn't necessarily higher priority than other work happening in the iteration, Maryana needs to make that call [00:13:46] awjr: it's not if you subscribe to the bug list :) [00:14:08] jdlrobson: how can i tell the relative priority of something in bugzilla against the rest of our work tracked in mingle? [00:14:34] if you just go off of what's in bugzilla, that also doesn't give Maryana a chance to rate the priority [00:14:45] awjr: if it it's a bug it should get priority automatically.. it's a no brainer to me. We should be striving not to make bugs [00:15:31] hmm, but not all bugs are created equal. i don't really care about enhancements or bugs introduced to devices that 2 people use [00:15:42] it's a tough problem [00:15:55] at one point, jcmish and i were going over the bug list each week to see if anything needed to be prioritized [00:16:01] well this shows to me we need to rethink/review how we treat our bugs [00:16:10] we stopped because bugs were coming in sporadically/unpredictably [00:16:10] Maryana: that doesn't work as bugs pop up all the time [00:16:10] jdlrobson: see the second bullet point: http://meta.wikimedia.org/wiki/Mobile_team/Mobile_web/Roles_and_responsibilities#Product_owner [00:16:13] it's a daily thing [00:16:17] yep :) [00:16:21] and we've been using mingle for tracking bugs in our iterations all along… or at least i thought we were [00:16:41] i've been trying to, yes, awjr [00:16:59] i think the point jdlrobson is making is that it's hard to know what to do with bugs that come in mid-iteration [00:17:24] we can decide on some process to upwards prioritize them from now on [00:17:46] some kind of "dire bug" card that jdlrobson can hand to me :) [00:17:48] so traditionally this is something that might come up during a daily scrum, but we do every other day, so that's probably not the best venue [00:18:24] that might still work [00:18:25] I really think bugs in mingle is broken until we have some kind of mingle-bugzilla automated workflow [00:18:57] in an ideal world any bug that is marked as high priority in bugzilla should appear in the story wall of the current iteration imo [00:19:08] what about high priority but low severity? [00:19:09] it's non-ideal, but i wouldn't say it's 'broken', it takes 2s to create a card in mingle to track a bug (its current work status, its priority) [00:19:12] or whatever it's called in bugzilla... [00:19:25] when you have a really critical issue but it only affects two people [00:19:31] jdlrobson: don't forget that pretty much anyone can set priority of bugs in bugzilla [00:19:40] awjr: which is a good thing [00:19:49] not always :) [00:19:59] wikipedians are going to mark everything as high priority [00:20:14] i agree jdlrobson, but again, refer to bullet point #2 :) http://meta.wikimedia.org/wiki/Mobile_team/Mobile_web/Roles_and_responsibilities#Product_owner [00:20:17] they pretty much invented that XKCD "you must support my workflow" meme [00:20:28] jdlrobson, I'd say that the problem here is Juliusz's vacation [00:20:39] awjr: bullet points aside it's broken [00:20:57] what specifically is broken, jdlrobson? [00:21:01] the fact is it's so annoying having to 1) create a card for a bug when it's already on bugzilla 2) move a card to in development when there is an ASSIGNED property in bugzilla 3) move a card to ready for testing when there is a RESOLVED FIXED field in bugzilla. [00:21:20] jdlrobson: that is a pain in the ass, not something that's broken [00:21:54] we can figure out how to make it less of a pain in the ass [00:22:15] but this has been, i thought, our process for dealing with this stuff [00:22:36] so, short of changing the software, how would you make this better jdlrobson? [00:23:05] awjr: agree to give bugs with patches priority in code review. [00:23:19] and trust that your team are wisely spending their time [00:23:29] jdlrobson: but we, as a team, have already agreed that the prioritization buck stops with the product owner [00:24:13] and i think that having to look in two different places to determine priority is not a good solution, particularly when in one of those places /anyone/ can set the priority [00:25:48] awjr: you must understand what i'm hearing here - i am hearing "jon you are wasting your time writing code to fix bugs rather than working on stories Maryana(product) are writing" yet I don't think my fixing bugs is interfering with our iterations [00:26:23] if something is set as high priority I still reserve the right to question that priority and talk to maryana about it if a community member disagrees/thinks we should be focusing on - i choose not to as i believe that is a waste of mine and Maryana's time [00:26:23] jdlrobson: that is not at all what i am saying, and i apologize if it's coming off that way [00:27:04] my point was we're using different systems for determining priority, which is not a good thing, and is precisely why i had no idea the patchset in question was such a big deal until today [00:27:45] to me a bug on a windows phone that stops searching is a no brainer that needs to be fixed asap as this effects a significant number of our user base so i automatically look into fixing it [00:28:01] brion, you able to spare 10 minutes? wanted to get your opinion on deployment approach on ZeroRatedMobileAccess. [00:28:12] i see that we are using different systems and that is indeed bad and needs to be resolved [00:28:21] jdlrobson: and of course it's your prerogative to work on whatever, but unless we're all looking at our work queues with a shared understanding of priority, it's not fair to be upset that that patchset hasn't been reviewed yet! [00:28:46] but the problem i see is that we are as a team not paying attention/caring for the bug queue [00:28:47] jdlrobson: i understand that, but that needs to be conveyed to the rest of the team somehow - that's the critical step that was missing [00:28:58] jdlrobson: then let's fix that! [00:29:05] awjr: agreed but i'm not sure what that is other than review bugs first [00:29:32] i think relying on another tool (such as mingle) just complicates matters [00:30:18] regardless of the tools, can we agree that the product owner should be setting the priorities of bugs for the team relative to the rest of the work we have planned? [00:30:34] awjr: that's a huge task bug tracking should be a shared responsibility [00:30:57] it relies on understanding the bug, understanding its impact on a daily basis [00:31:05] this is why we have a bug wrangler.. [00:31:16] i agree but that is different than having one person be the final ersponsibility for priority, just like with the rest of our work [00:32:04] just like we all have a role in defining the work that we do, we should all have a role in coping with the bugs - but the final priority is set by one person [00:32:30] it seems to me the problem is upstreaming the bug information to Maryana and making sure there's enough context/information for her to make an informed decision [00:32:40] awjr: so every time i/member of community decides to fix a bug they have to OK it via maryana? or would this be more an after thing - when patches come in Maryana has to assess priority? [00:33:01] i dont think it needs to be cut and dry, jdlrobson [00:33:48] ideally the priority would be set /before/ the bug gets fixed (like, shortly after its been reported) [00:34:34] awjr: that's not always workable. This is where my concern about trusting each other comes in and is the thing that most worries us [00:34:40] *worries me [00:34:54] if Maryana is in a meeting do i just forget about it? [00:35:20] in that case, you should at least find a way to communicate the urgency with the rest of the team [00:35:31] why don't we make that a bigger part of standups? [00:35:34] to start [00:35:39] and see how far that gets us [00:35:52] awjr: sometimes it's just easier to fix it [00:36:17] jdlrobson: right, but then how am i supposed to it's an urgent fix that needs review unless its somehow communicated to me? [00:36:28] awjr: there is the word bug in the commit summary :) [00:36:44] it all goes back to the fact we have different ways of reviewing [00:36:56] i review bugs first regardless of whether they are in the story wall or not :) [00:37:11] even for bugs that are 'low' priority? [00:37:16] or enhancements/ [00:37:41] Maryana: i think that's a good idea [00:37:58] awjr: no as it should be clear from the bug report and by trusting that developers are working on the right and most important things [00:38:43] jdlrobson: i get that, but as humans, we all have different perspectives on what is 'important' - that is why we give the power of prioritization to one person; to unequivocally settle that question. [00:39:49] awjr: then what's stopping you from looking at a patch and before spending time on code reviewing asking the originator/maryana whether it is important (unless it's obvious) [00:40:24] imagine MobileFrontend had a thriving developer community with bug fixes coming in left right and center [00:41:29] jdlrobson: well, like i said before, i've been using priorities set in Mingle as my guide for what to code review. when i set aside time for code review, i do it in priority order from mingle. if i exhaust that and still have time, i move on to other patchsets. but usually i dont have more time and move on to other work [00:43:31] the nice thing about keeping priorities in one place is i don't have to stop and ask what the priority of something is; and i can know at any time of day or night, anywhere in the world, whenever i feel like working on something, what the priority is [00:48:52] awjr, you got 10 minutes? i think brion is occupied, and i believe you can answer my questions as well. [00:49:00] sure dr0ptp4kt, what's up? [00:49:19] looking for advice on deployment approach with some zero stuff. [00:49:37] able to get on skype? [00:50:20] dr0ptp4kt: can you give me a few minutes? [00:50:27] awjr, yep [00:50:33] awjr, lemme know once ready [00:51:51] awjr: it might work for you but it's not working for me…the only time i ever go to mingle is when i'm picking something to work on or moving it over to code review :) i stay away from it as much as i can [00:55:05] jdlrobson: honestly, that's all i use it for too… and since we define our work priorities there, that's where i look to know what to do next [00:55:54] it's nice to have a common tool where we can at-a-glance know what the priority is, what's actively being worked on (so we don't step on eachother's toes), and know what we need to be doing next [00:56:10] especially when we don't all work during the same hours in the same space [05:33:32] dr0ptp4kt, here? [07:06:02] MaxSem, ping [07:06:14] hey yurik [07:06:41] MaxSem, hi, i juts replied re deploymetn [07:06:59] Zero ext master branch cannot be deployed yet [07:07:40] can you pick up the revision of the decoupling, not later [07:08:05] since the related MF changes will be deployed today - will Zero continue functioning? [07:08:25] (if we don't deploy it) [07:08:50] note that 1.22wmf2 already has a latish Zero [07:10:09] MaxSem, https://gerrit.wikimedia.org/r/gitweb?p=mediawiki%2Fextensions%2FZeroRatedMobileAccess.git;a=summary [07:10:27] jrobson's checkin is fine [07:10:36] everything afterwards should not be deployed just yet [07:11:02] aha [07:11:13] (simply because settings - meta Zero:xxx pages have not been created yet) [07:29:35] grrr [07:29:59] master is supposed to be deploymnet-ready at all times [07:32:17] Всегда готов! [08:09:29] LOL ori-l, where did you dig that one up! [08:09:48] MaxSem, master is deployment ready, the settings are not :) [08:09:50] bug dr0ptp4kt [08:09:57] its on his plate now :) [10:11:57] MaxSem, so when do you want to deploy? [10:12:09] I don't mind next monday [10:17:17] MaxSem, i won't be around begining of the next week - i will have a few days off and then flying back [10:17:38] not like you really need me i guess [10:17:48] because it won't be any of my stuff just yet [14:07:58] MaxSem: can you send me the link for the UA info again? [14:08:21] http://staging.wmflabs.org/ua.php [14:10:24] thanks again [14:38:16] New review: Brion VIBBER; "(1 comment)" [mediawiki/extensions/MobileFrontend] (master); V: 1 C: 1; - https://gerrit.wikimedia.org/r/58332 [14:59:11] [Commons-iOS] brion pushed 1 new commit to master: http://git.io/9d4yRA [14:59:11] Commons-iOS/master 41d0851 Brion Vibber: Language mapping for Portuguese/Brazilian Portuguese [15:02:30] [Commons-iOS] brion pushed 4 new commits to master: http://git.io/PwR5dQ [15:02:30] Commons-iOS/master 9b037c4 Monte Hurd: About page.... [15:02:30] Commons-iOS/master d596c4b Monte Hurd: Changed about page commons link. Simplified version replace. [15:02:30] Commons-iOS/master e6190a0 Monte Hurd: Improved about page... [16:48:37] oh sweet, Xcode updates in the app store are actually small [16:48:42] instead of a full 2gb download [16:57:02] dr0ptp4kt: do you have access to fenari yet? [16:57:12] no, just tried ssh'ing, in fact. [16:57:16] ok [16:57:19] should i just ask tomasz for that? [16:57:33] im actually not sure who the right person is for that these days - i can look into it [16:57:58] okay, thank you. i was going to look on the actual box to see what version of code is there. [16:58:09] dr0ptp4kt: i just saw your email wondering what the current status of production is for zero [16:58:21] you can figure that out on fenari [16:58:26] or, you can just look in the production branches [16:58:29] awjr: :) [16:59:41] so dr0ptp4kt the first thing you want to do is figure out what branches are currently being used in production [16:59:52] you can figure that out by looking at http://noc.wikimedia.org/conf/highlight.php?file=wikiversions.dat [17:00:01] (also on fenari in /home/wikipedia/common/wikiversions.dat) [17:00:44] the values on the left side of that text file are the specific projects, the values on the right are the branch that they're currently using [17:00:55] i.e., enwiki php-1.22wmf1 * [17:01:20] maxsem@fenari:/h/w/c/php-1.22wmf2/extensions/ZeroRatedMobileAccess$ git log -1 [17:01:20] commit 888c4225e65d768b0200cb9d12ee9cf311597f80 [17:01:20] Author: Yuri Astrakhan [17:01:36] MaxSem, ? [17:02:01] maxsem@fenari:/h/w/c/php-1.22wmf1/extensions/ZeroRatedMobileAccess$ git log -1 [17:02:01] commit 0a239dda9fd41b809d7e6e3cbda859a17c644034 [17:02:01] Author: Translation updater bot [17:02:02] yeah dr0ptp4kt, so enwiki = english wikipedia, branch = 1.22wmf1 (in the actual branch name, there is no 'php-' prefix) [17:02:19] yurik, discussing what's deployed ^^^ [17:03:28] dr0ptp4kt: to get the specific branches checked out on your local machine, you can follow the specific steps here: https://wikitech.wikimedia.org/wiki/How_to_deploy_code#Case_1c:_extension_update or if you want to be a little more expedient, just checkout the remote branch locally [17:04:06] if you do a git branch -r from a clone of core, you'll see a bunch of remote branches like: [17:04:07] origin/wmf/1.21wmf5 [17:04:07] origin/wmf/1.21wmf6 [17:04:07] origin/wmf/1.21wmf7 [17:04:07] origin/wmf/1.21wmf8 [17:04:08] origin/wmf/1.21wmf9 [17:04:09] origin/wmf/1.22wmf1 [17:04:25] origin/wmf/* are what are used for production [17:13:29] dr0ptp4kt: pm [17:41:48] dr0ptp4kt & yurik, would it be safe to assume that wmf2 should be reverted to whatever is in wmf1? [17:42:15] New review: Jdlrobson; "Desktop uses jquery suggestions plugin. We could use this but I've always felt something like this i..." [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58332 [17:43:12] New review: Jdlrobson; "ps. I've noticed that highlighting is completely broken on deployed wikipedia anyway since the stron..." [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58332 [17:57:45] New patchset: Jdlrobson; "Rewrite search as an overlay" [mediawiki/extensions/MobileFrontend] (master) - https://gerrit.wikimedia.org/r/58332 [17:58:39] MaxSem: what's the latest auto detection mechanism out of the box for MF ? I have a user with a problem "Hi Jon, I upgraded to Mediawiki 1.20 on me dev machine, and things [17:58:39] seem to work fine. [17:58:41] However using MF for MW 1.20 has no auto-detect, so it's not very [17:58:41] useful to me :)" [17:59:19] Do we have a wiki page explaining the above? [17:59:33] if they want autodetection, they should use master MW+MF [18:00:15] MaxSem: also see http://www.mediawiki.org/w/index.php?title=Extension_talk:MobileFrontend&offset=20130416091705&lqt_mustshow=26314#Howto_switch_to_mobile_Version_26314 [18:00:18] there are a few different ways that can do it, but the easy ones have been introduced relatively recently, like within the last 3 or 4 mos [18:00:34] Can I suggest a page? I'm getting *lots* of queries around this? [18:00:50] there seems to be lots of interest in the current situaton [18:01:09] i dont think we have a page currently documenting any of the possible ways, with the excepiton of maybe how we do it with varnish [18:02:11] awjr: ok if I knock one up can we add some brief notes? [18:02:21] yeah totes [18:02:23] be bold! [18:02:49] jdlrobson: maybe a subpage of mediawiki.org/wiki/Extension:MobileFrontend [18:02:58] why subpage? [18:03:04] or section :) [18:03:06] people never notice them [18:03:07] whatever [18:03:21] also should we set MobileFrontend Release status to something other than stable - as that doesn't really seem true right now :) [18:03:22] just personal preference, i dont like long pages [18:03:37] if it's not in TOC, you can assume that it's only seqarchable, but not discoverable [18:03:57] jdlrobson, MF's status is rolling updates [18:04:09] each of them is kinda stable [18:04:20] MaxSem: i usually create a section on a main page for a subpage and either make the section header a link, or put a link to the subpage as the main content in the section (for something like this) [18:04:23] not according to http://www.mediawiki.org/w/index.php?title=Extension:MobileFrontend MaxSem :) [18:04:26] it's table relative to Mediawiki core [18:04:26] as in stable enough to run on WMF [18:06:25] ie stable enough for us cowboys [18:06:39] and cowgals [18:07:51] not to mention cowaliens [18:08:29] awjr: MaxSem what's the link to varnish configuration ? [18:08:50] operations/puppet/templates/varnish [18:09:43] mhurd: apple rejected it *again* [18:09:50] MaxSem: is there a mediawiki page for that? [18:10:32] YuviPanda|Meds: :( [18:10:43] WHAT THE FUCK [18:10:44] "We found that your app includes the ability to collect charitable donations within the app, which is not in compliance with the App Store Review Guidelines " [18:10:50] YuviPanda|Meds: ? [18:10:58] mhurd: that's their reason for rejection [18:11:05] YuviPanda|Meds: that makes no sense! [18:11:10] indeed [18:11:12] the commons app? [18:11:13] YuviPanda|Meds: gah! [18:11:15] did we have a 'donate' link somewhere? [18:11:16] Maryana: yeah [18:11:19] wtf [18:11:21] that's crazy [18:11:52] did they see the words "donate image" and think that was a chariatable contribution?? [18:11:55] Maryana: no [18:11:58] Maryana: they sent us a screenshot [18:12:05] Maryana: somehow they've managed to navigate to donate.wikimedia.org [18:12:11] from the commons app? [18:12:13] yes [18:12:20] *in* the commons app itself. [18:12:39] I *think* they went to the license screen and went from there [18:12:47] mhurd: do you have access to iTunes connect? [18:12:48] that is insane [18:13:14] YuviPanda|Meds: yes [18:13:19] YuviPanda|Meds: i'll login [18:13:24] oh, and I think they might also want us to flag the app as 18+ [18:13:29] also [18:13:31] "- Developer must act on objectionable content reports within 24 hours by removing the content and ejecting the user who provided the offending content " [18:13:33] hahaha, sure [18:13:53] wat [18:13:56] @_@ [18:14:09] it's only the user's own content that will be shown, right? [18:14:09] let me paste the entire thing somewhere [18:14:13] ragesoss: yup [18:14:23] gotta protect you from yourself [18:14:26] i dont even [18:14:34] @_@ [18:14:39] http://dpaste.de/4cdj4/ [18:14:49] awjr: MaxSem can you help me flesh out http://www.mediawiki.org/wiki/Extension:MobileFrontend/Configuring_Browser_Auto-Detection [18:14:56] 18.2 section is so fun [18:14:56] yeah jdlrobson, but later [18:15:31] ragesoss: Maryana http://dpaste.de/4cdj4/ [18:15:40] just read it. [18:15:55] it bottles the mind. [18:16:04] jdlrobson, have you actually tried http://www.mediawiki.org/wiki/Extension:MobileFrontend/Configuring_Browser_Auto-Detection#Apache_Redirects ? [18:16:08] * YuviPanda|Meds bottles ragesoss [18:16:13] yuvipanda|meds: well, on the plus side, the fundraising team will be happy to hear that we can collect donations via mobile, despite no one having worked on this ever… [18:16:25] :D [18:16:25] Maryana: hehe :P [18:16:58] Maryana: so that can be construed as a bug. There might be a donate link buried somewhere in the CC license text, and apparently apple wants us to not allow users to click that [18:17:06] jdlrobson: varnish config can be found here: https://gerrit.wikimedia.org/r/gitweb?p=operations/puppet.git;a=tree;f=templates/varnish;h=ffd0b24bc45a8fa092fe4b3719d5002db79e8aca;hb=HEAD particularly in device-detection.inc.vcl.erb, mobile-frontend.inc.vcl.erb [18:17:35] awjr: can you update the mediawiki page instead? [18:17:41] it sounds like they're ok with sending users to an external link to donate, yuvipanda|meds [18:17:55] Maryana: yup. so that's a fixable 'bug' [18:18:02] YuviPanda|Meds: i can't see the screenshot - could you post it [18:18:05] we just need to pop users out to safari instead of in the app for anything [18:18:17] mhurd: can you go to https://itunesconnect.apple.com/WebObjects/iTunesConnect.woa/da/rejectionReasons?adamId=630901780 [18:18:30] mhurd: it's easy to miss, called 'Screneshot_0' [18:18:32] except spelt right [18:18:39] if you still can't find it i'll paste it [18:19:05] still no image :( [18:19:10] okay, paste comin up [18:19:25] mhurd: http://a93.phobos.apple.com/us/r30/Purple/v4/f0/f6/46/f0f646ef-0bbb-e6c8-d8ed-f04d0f2e4ccd/temp..bdjlgmdm.png [18:19:48] YuviPanda|Meds: thanks! [18:19:52] :) [18:20:08] YuviPanda|Meds: btw hope you're feeling better!! [18:20:28] mhurd: thanks :) The meds have kicked in and I no longer feel like my lower jaw is possessed by demons [18:20:51] YuviPanda|Meds: oh man! [18:22:14] soooo... no other users' pics for the iCrap app?:) [18:22:26] not yet :P [18:24:10] YuviPanda|Meds: they must have reached the donation page via the licensing link at the bottom of the details page, and by following links on that to the full site and from there to a donate button… i guess? [18:24:18] yup [18:24:21] that is very convoluted [18:24:25] but the only way I could think of [18:24:27] YuviPanda|Meds: could we link to a plain-text license page w / no links [18:24:55] we could do that but that'll be painful [18:24:59] action=raw is mostly eek [18:25:12] mhurd: can we make all links going out from that webview pop up in safari? [18:25:21] what links are you using for license? you should just link to the human-readable creative commons pages [18:25:36] lemme check [18:26:03] why not link to the license in Safari in the first place? [18:26:10] that'd work too [18:26:12] plus less code! [18:26:25] Maryana: I think that's what is being linked to currently. [18:26:54] so how did they get from a creative commons domain back to a wikimedia domain? [18:27:33] link: http://creativecommons.org/licenses/by-sa/3.0/ [18:27:36] Maryana: our nearby feature makes me feel bad about myself [18:27:36] :D [18:27:46] even when I travel I'm not near anyone [18:27:52] maybe we could change it to this one: http://creativecommons.org/licenses/by-sa/3.0/legalcode [18:28:11] which seems to have fewer links [18:28:26] mhurd, yep, that's what mobile web is using :) [18:28:40] mhurd: but can't we just make all link navigations pop to Safari? I'm sure Apple will find a way to 'break out' of there :) [18:28:52] mhurd: I mean, they went to donate.wikimedia.org from the original page... [18:29:27] Maryana: however, I'm not sure what we're going to do about the second part [18:29:28] re: flagging [18:29:35] we might get rejected again for that [18:29:51] and IIRC Commons doesn't really have a 'flag' thing [18:30:05] and even if it did, apple's definition of 'Objectionable' is not really going to be in line with Commons' [18:30:11] ragesoss: ^ [18:30:20] yeah, that i have no idea about. how did we deal with this on the wikipedia app for iOS? [18:30:29] they never asked. [18:30:50] it seems like they misunderstand what the app displays, in terms of user-generated content. [18:31:01] I think it didn't occur to them that Wikipedia is 'user generated'. [18:31:16] ragesoss: indeed. If it didn't turn up for Wiki where you see everyone else's, but this where you (currently) see only yours... [18:31:19] YuviPanda|Meds: generally i prefer to minimize jumping in and out of the app (to safari and back) if it can be avoided [18:31:49] hmm, mhurd but in this case we just want that webview to show people the license, right? having them wander to donate from that seems a bit awkward... [18:31:56] yeah. they probably actually *couldn't* justify passing the Wikipedia app, if they are taking their policy seriously. [18:32:03] mmm, does 18.2 cover displaying people's own pics to themselves? [18:32:05] but the Commons app, they just don't understand it. [18:32:09] yup [18:32:38] MaxSem: I don't see how it could, or every camera app and gallery would run afoul of it. [18:32:52] hehe, let's ban them [18:32:57] YuviPanda|Meds: i'll double-check links from http://creativecommons.org/licenses/by-sa/3.0/legalcode to confirm that it would even be an option [18:33:23] haha max [18:33:26] :) [18:33:27] so if our app doesn't yet have other users' pics, WTF are they objecting to? [18:33:27] mhurd: definitely is [18:33:38] mhurd: hit first link on top, scroll down a bit, bam! [18:33:40] yuvipanda|meds - is there an actual human we can talk to at apple? [18:33:43] :) [18:33:54] to explain this? or is it all faceless corporate drones? [18:34:10] apple is staffed by mandroids and fembots [18:34:12] so Maryana [18:34:16] Maryana, I'm afraid they're all either biomechanoids or jerks. Jobs style! [18:34:17] Use the field below to ask questions or provide additional information to the App Review team. [18:34:17] ' [18:34:20] can't you just have the second link deep open in safari instead of in-app browser? [18:34:20] and a textbox under it [18:34:22] YuviPanda|Meds: oh i meant "be an option to not-jump out if there's no way to get to donate page from the plain(er) text link" [18:34:24] Maryana: so we could respond on that [18:34:44] yes we definitely can [18:34:46] mhurd: yeah, I'm saying it is possible with just 2 steps :) [18:35:08] in fact I can't figure out *how* they got from our first link to the donate page [18:35:13] since it links to *creative* commons [18:35:17] and the screenshot is *our* donate page [18:36:39] YuviPanda|Meds: ah - i just did the same 2 steps - gah! [18:37:09] Maryana: the iTunes connect page has a reply form. Not sure how much of a human it goes to, though [18:37:14] it might be just automated responses [18:37:49]