Re: [WikimediaMobile] Wikipedia iOS app moving to GH
FYI, spent some time this morning refactoring the epic https://phabricator.wikimedia.org/T98970, scope has been reduced to CI (moving CD into its own epic https://phabricator.wikimedia.org/T102547) and clarified/elaborated many other sections. On Thu, Jul 23, 2015 at 3:14 PM, Brian Gerstle bgers...@wikimedia.org wrote: The (rough) epic definition is already on Phabricator: https://phabricator.wikimedia.org/T98970. I've defined some metrics there already, but admittedly—and thanks for calling us out on this—we don't really have baselines*. I think there are some feasible ways to get a rough starting point, which I can brainstorm w/ the team. We were planning (or I should say, I was hoping) to gather more code metrics anyway, so I'm glad to have an excuse to hook it up sooner ;-). FWIW, I also think having patches tested as part of code review https://github.com/bgerstle/apps-ios-wikipedia/pull/3 would also work as a sufficient definition of success. Our goal here is to do that as quickly, easily, and cheaply as possible so we can get back to focusing on the app. * I think it's fair to say that the coverage at point of migration was already low (~10% based on my Travis-covered fork) and hasn't changed much. On Thu, Jul 23, 2015 at 2:04 PM, Greg Grossmeier g...@wikimedia.org wrote: Brian and the Reading team: On Wed, Jul 22, 2015 at 3:40 AM, Brian Gerstle bgers...@wikimedia.org wrote: By using GitHub with Travis CI, the team believes it will work faster, improve testing, grow developer confidence in making code changes, and, most importantly, deploy fewer bugs to production. Given that, I am requesting you/your team create a set of KPIs to review in 3 or 4 months to determine if this change had the intended outcome. It's hard to make these things quantifiable as useful KPIs (that prevent eg gaming the system) but I think it'd be a good exercise for your team given your team's decision making process thus far. Please post those KPIs somewhere public and trackable (wiki or phab). Thank you, Greg -- Greg Grossmeier Release Team Manager -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle -- EN Wikipedia user page: https://en.wikipedia.org/wiki/User:Brian.gerstle IRC: bgerstle ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] In-app editing / talk pages support
On 22 July 2015 at 10:52, Dmitry Brant dbr...@wikimedia.org wrote: Therefore, providing access to talk pages without providing the other fundamentals that are central to editing (moderation tools, watchlists, diffs, notifications, etc) may be putting the cart before the horse, and may lead to confusion. I think you hit the nail on the head with this comment. Experienced Wikipedians know the value of talk pages. For many of them, talk pages actually comprise the majority of their usage of the site. But, the majority of their navigation to those pages are through their watchlist, so adding a talk page link doesn't serve them; they know the talk page is there, and how to find it if they need it. For newer users, talk pages are their entry point into the inner workings of the wiki, and how they get sucked in. But, there are some pretty fundamental https://i.imgur.com/UOqtyoM.png formatting issues with talk pages in the app right now. If you're going to make it read only, how are you going to explain to users why other users are leaving comments, but they can't edit it? Suddenly, there are a lot of questions that will take a lot of team bandwidth, designs, and discussions to answer. Can you commit to answering all of these questions given the other work you have in the pipeline? For the reasons above, I was opposed (and still am) to adding links to talk pages in the app. For experienced editors, they know where to find them and don't need a button to get there. For readers (the primary user type that the app supports), the talk page experience in the app is not good enough to expose the users to it, and we never had the capacity to get the experience to a place where it was good enough for them without considerable work to build out the entire pipeline. Dan -- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
Re: [WikimediaMobile] In-app editing / talk pages support
+1 Dan's team bandwidth comment. I totally want to implement native interfaces for all of the fundamentals central to editing which Dmitry listed, but we'll just need to plan and stage things very deliberately. If we eventually do commit to this, we may even consider keeping all of these fundamental editing interfaces beta only until all parts are working and working well together - even if this takes a while. On Jul 24, 2015, at 7:38 PM, Dan Garry dga...@wikimedia.org wrote: On 22 July 2015 at 10:52, Dmitry Brant dbr...@wikimedia.org wrote: Therefore, providing access to talk pages without providing the other fundamentals that are central to editing (moderation tools, watchlists, diffs, notifications, etc) may be putting the cart before the horse, and may lead to confusion. I think you hit the nail on the head with this comment. Experienced Wikipedians know the value of talk pages. For many of them, talk pages actually comprise the majority of their usage of the site. But, the majority of their navigation to those pages are through their watchlist, so adding a talk page link doesn't serve them; they know the talk page is there, and how to find it if they need it. For newer users, talk pages are their entry point into the inner workings of the wiki, and how they get sucked in. But, there are some pretty fundamental formatting issues with talk pages in the app right now. If you're going to make it read only, how are you going to explain to users why other users are leaving comments, but they can't edit it? Suddenly, there are a lot of questions that will take a lot of team bandwidth, designs, and discussions to answer. Can you commit to answering all of these questions given the other work you have in the pipeline? For the reasons above, I was opposed (and still am) to adding links to talk pages in the app. For experienced editors, they know where to find them and don't need a button to get there. For readers (the primary user type that the app supports), the talk page experience in the app is not good enough to expose the users to it, and we never had the capacity to get the experience to a place where it was good enough for them without considerable work to build out the entire pipeline. Dan -- Dan Garry Lead Product Manager, Discovery Wikimedia Foundation ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l ___ Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
