On 9 March 2015 at 21:11, Pine W wiki.pine@gmail.com wrote:

Why are (7 FTEs * 40 hours * 13 weeks = 3,640 labor hours) required to achieve what appears to be a simple goal?

It seems simple to us because we're Wikimedians and we know what it means to edit Wikidata. Although the goal is simple, the solution will not be.

For example, we'll be making cross-domain requests (which adds potential for complications and performance problems), will probably have to interface with CentralAuth to check that the user has a global account (which we've never tried before and might not even be possible for the app), will have to work with Legal to ensure we're getting attribution correct (legally *and* ethically), will have to coordinate with Community Engagement to make sure that our editors are aware of the feature, and so on. If you want more details on all of this (because I could keep going if you're interested!), then let me know. :-)

Dan

On 13 March 2015 at 16:46, Pine W wiki.pine@gmail.com wrote:

Let me try asking about this from a different angle. What was the methodology used to come to the conclusion that this project would require the kinds and numbers of investments that you mentioned?

I mapped out the required work, broke it down into sub tasks, and then based on my experience of how long similar things have taken in the past, estimated the required number of people that would be required to do so. I also am always *extremely* reluctant to assign any fewer than two engineers to a project; code review is incredibly important and without making sure that it is accounted for in resourcing requests, projects can go and do go absolutely nowhere.

Bear in mind there is an element of "undercommit and overdeliver" in my proposal; I expect that we would also be able to achieve something else in the allocated time, but I'd rather make a commitment to something I'm really sure we can achieve, than make a commitment to something we might be able to achieve then not achieve it. I should note that "undercommit and overdeliver" is a strategy endorsed by Lila!

I should also note that I have since adjusted https://www.mediawiki.org/w/index.php?title=Talk:Wikimedia_Engineering/2014-15_Goals/Q4&diff=1440825&oldid=1440079 the magnitude of my ask; 1 FTE UX designer (down from 1.5) and 0.5 FTE QA tester (down from 1).

I'm not sure how else to answer this question without literally brain dumping everything I wrote down into an email. Did I adequately answer you?

Dan

On 13 March 2015 at 18:59, Pine W wiki.pine@gmail.com wrote:

Yes, thank you. I trust you to adjust accordingly if the project finishes early or encounters surprise roadblocks. At some point I would be interested in seeing the task breakdown (are those on Phabricator somewhere?).

Not yet, because we're still not decided on that yet. We avoid putting cards that are not actionable in our backlog as a point of process. Once we've done our quarterly planning process, we'll put those cards in the backlog in Phab.

By the way, lest this email chain come across as micromanagement of Mobile Apps, I do appreciate that you and your team have a good track record of producing software that people like, and I really appreciate your transparency via the email updates that you write frequently.

Thank you. :-)

What was giving me sticker shock was the cost of producing this particular functionality, hence my questions.

A good part of this is because we were (very rightly) encouraged to keep our proposals short.

Actually there's a lot of cool stuff I'd like to do as part of this, like building out and scaling up Magnus's AutoDesc API to give users an automatically generated starting point, which will definitely take substantial engineering time to get it to a stage where it can be deployed to a production server. That substantially increases the engineering resources required. And that also needs to be designed, thus the design resources required.

I don't just want to make it an editable text box. We can do better than that! :-)

What I'm going to do, in order to help with our quarterly planning process, is put together a slide deck that gives an overview of how I think this is going to play out. Then it'll become clearer why I made the resource asks that I did, I think. I'll share that deck on here when I have it.

Thanks!

Dan