Adam,
I'm happy to hear that VE is coming to mobile web.
I'd like to know more about what the plans are for user testing of VE on mobile. Would that happen in late Q2 at the earliest, and how much emphasis will there be on user testing mobile VE while it's in beta? My prime interest is in making sure that the transition out of beta is smooth and that end users have a good experience with mobile VE from the moment that it leaves beta.
Thanks, Pine On Jul 27, 2015 10:12 AM, "Adam Baso" abaso@wikimedia.org wrote:
Cross posting to mobile-l.
---------- Forwarded message ---------- From: Adam Baso abaso@wikimedia.org Date: Mon, Jul 27, 2015 at 10:11 AM Subject: Editing + Reading Meeting Notes To: Wikimedia developers wikitech-l@lists.wikimedia.org
Hi all,
James Forrester, Florian, and I met Wednesday, 22-July-2015 to discuss the Editing roadmap, with the backdrop of editing modes available in mobile web and apps but both the mobile web and apps teams now being in the Reading department. Notes:
FY 2015-2016: active Editing development for apps not planned
General plan is to replace the current mobile web editing experiences
with new (replacement) VE and wikitext editor maintained by the VE team for mobile web
Q1: VE mobile prototyping (doesn't require Reading involvement)
Q2: Editing for mobile web replacement *coding* starting, but rollout on
mobile web would begin in some future quarter _after_ Q2
- Feature submission practices for volunteers submitting editing related
stuff for the mobile web for the time being (feature submissions discouraged for now as it will end up being replaced; mainline VisualEditor / next gen wikitext editing in collaboration with VE team would probably make more sense) -
** Create task in reading-web Phabricator board and indicate the details of what you were thinking to work on and roughly when. Add James Forrester and Joaquin Hernandez to card.
** Reach out to James_F (Senior Product Manager, VisualEditor) and joakino (Reading Web engineering product owner and tech lead) on #wikimedia-mobile on Freenode to discuss the idea and to determine who would need to code review and test
- Code review for bugfixes for the existing mobile editing code should be
done by Reading Web, and code review plus testing should be done by Editing as well. Ping joakino and James_F on IRC to figure out who to add to bugfixes.
- As the Editing team gets into the practice of submitting patches for
MobileFrontend to swap out the editor, as usual, tasks should be filed well ahead of time in the reading-web Phabricator board so there's a heads up about potential code review. Also, Editing and Reading should be tracking Q2 and subsequent quarter planning together to ensure dependencies are clearly defined and agreed upon.
I also spoke to Roan from Collaboration after the Scrum of Scrums the same day. Roan indicated that there isn't an emphasis on rolling out Flow to mobile Wikipedias en masse for FY 2015-2016. And generally, when Flow does become slated for rollout on the mobile Wikipedias and sister projects in a broader sense it shouldn't require work - or anything substantial, anyway - from the Reading team.
-Adam
Mobile-l mailing list Mobile-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mobile-l
[Un-duplicate posting. Unless it's an announcement or critically-urgent, please don't ever do that.]
On 27 July 2015 at 11:27, Pine W wiki.pine@gmail.com wrote:
I'm happy to hear that VE is coming to mobile web.
It's not "coming" (it's been available for tablet users for 18 months); it's being improved . Once it's credible for phone users as opposed to just tablets, we'll remove the block that prevents them from using it .
I'd like to know more about what the plans are for user testing of VE on mobile.
Specifics are for the User Research team, but in general we're doing broad testing of all editing features on desktop and mobile, not looking at silos. The things that matter are meeting users' expectations simply and consistently, and solving issues as we identify them.
Would that happen in late Q2 at the earliest, and how much emphasis will
there be on user testing mobile VE while it's in beta?
It's ready when it's ready. There's no point (and a great deal of potential harm) in releasing things before they have a positive effect. Putting arbitrary dates (even as vague as "Q2") on improving things for our users means prioritising a deadline over making things better for them.
Yours,
James,
Thanks. I have a follow up question regarding project management in general. When the length of time for development and testing are unbounded so that product quality is the principal goal, how do you forecast needs for human resources and financial resources?
Thanks,
Pine On Jul 27, 2015 12:07 PM, "James Forrester" jforrester@wikimedia.org wrote:
[Un-duplicate posting. Unless it's an announcement or critically-urgent, please don't ever do that.]
On 27 July 2015 at 11:27, Pine W wiki.pine@gmail.com wrote:
I'm happy to hear that VE is coming to mobile web.
It's not "coming" (it's been available for tablet users for 18 months); it's being improved . Once it's credible for phone users as opposed to just tablets, we'll remove the block that prevents them from using it .
I'd like to know more about what the plans are for user testing of VE on mobile.
Specifics are for the User Research team, but in general we're doing broad testing of all editing features on desktop and mobile, not looking at silos. The things that matter are meeting users' expectations simply and consistently, and solving issues as we identify them.
Would that happen in late Q2 at the earliest, and how much emphasis will
there be on user testing mobile VE while it's in beta?
It's ready when it's ready. There's no point (and a great deal of potential harm) in releasing things before they have a positive effect. Putting arbitrary dates (even as vague as "Q2") on improving things for our users means prioritising a deadline over making things better for them.
Yours, -- James D. Forrester Lead Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
On 27 July 2015 at 14:44, Pine W wiki.pine@gmail.com wrote:
James,
Thanks. I have a follow up question regarding project management in
general. When the length of time for development and testing are unbounded
so that product quality is the principal goal, how do you forecast needs for human resources and financial resources?
The trite answer is "guesstimation based on professional experience", but in general the honest answer is that no-one has solved this issue in Computer Science (the snake oil salespeople who claim otherwise would protest).
Instead, the industry focusses on a variety of techniques around concepts like scoping the issue (iterations), treating the symptoms (Waterfall) or recognising failure quickly (agile). It's a fascinating field, and there are many people far more qualified to opine on it than me (I never even did my PhD). My vague gut feeling is that in a century or two the world will have settled down and we'll have solved this problem, but before then we'll have outsourced such work to semi-strong AI and it'll be their issue. :-)
J.
James,
Thanks, that's an interesting answer.
Lots of fields other than software struggle with similar issues. For example, I can't remember the last time a major aerospace manufacturer managed to design and build one of their flagship products on schedule, and major public transportation projects in the U.S. seem to fall behind schedule and over budget on a regular basis
If it wouldn't be a distraction from other priorities, I'm wondering if project management could be the subject of a Tech Talk sometime. (Cc'ing Rachel who I believe coordinates Tech Talks.)
Thanks,
Pine
On Mon, Jul 27, 2015 at 3:16 PM, James Forrester jforrester@wikimedia.org wrote:
On 27 July 2015 at 14:44, Pine W wiki.pine@gmail.com wrote:
James,
Thanks. I have a follow up question regarding project management in
general. When the length of time for development and testing are unbounded
so that product quality is the principal goal, how do you forecast needs for human resources and financial resources?
The trite answer is "guesstimation based on professional experience", but in general the honest answer is that no-one has solved this issue in Computer Science (the snake oil salespeople who claim otherwise would protest).
Instead, the industry focusses on a variety of techniques around concepts like scoping the issue (iterations), treating the symptoms (Waterfall) or recognising failure quickly (agile). It's a fascinating field, and there are many people far more qualified to opine on it than me (I never even did my PhD). My vague gut feeling is that in a century or two the world will have settled down and we'll have solved this problem, but before then we'll have outsourced such work to semi-strong AI and it'll be their issue. :-)
J.
James D. Forrester Lead Product Manager, Editing Wikimedia Foundation, Inc.
jforrester@wikimedia.org | @jdforrester _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
If it wouldn't be a distraction from other priorities, I'm wondering if project management could be the subject of a Tech Talk sometime. (Cc'ing Rachel who I believe coordinates Tech Talks.)
Thanks,
Pine
You mean like "Kanban: An alternative to Scrum?" https://www.youtube.com/watch?v=zT8cUtMTGPI
-- bawolff
That Kanban talk assumes some familiarity with Scrum or other agile software development models, so might not be helpful for everyone. For those who are new to that space, agile development[1] takes a radically different approach than traditional (non-software) project management, or from traditional software project management (often referred to as "waterfall"). Agile encompasses both Scrum and Kanban, as well as a dozen more methodologies. Agile is a way of thinking, being, and doing, rather than a specific set of practices[2].
Note that agile is not fully adopted within the foundation, but I believe many/most teams are either agile or "agile-adjacent". Most open source projects are agile (or agile-ish) even if they don't realize it. Within our Wikimedia context, I might describe "agile" development like this:
We probably can't know how long it will take to develop X, because as we work, we will learn. So even if we did deliver exactly X, by then we would realize that X is no longer exactly what is desired. That's in addition to the normal uncertainty around programming, which is inherently a creative process[3]. However, we will have some X in mind as a long-term destination, realizing that we're unlikely to end up exactly there. It's kind of like planning a road trip "up the coast", without knowing exactly what campsite you'll end up in.
To get started, we will figure out some small portion of X, and code and deliver it. That will give us feedback to figure out the next part of X, which we will code and deliver. We'll repeat this over and over, constantly refining our direction based on feedback. At some point, we will have delivered "enough" and will stop. That could be at 30% of X, or perhaps 80% of X but also with 40% of Y and 10% of Z. Throughout the process, the Product Manager, developers, and users will be having conversations to refine everyone's understanding of the goal(s).
At any point in time, the Product Manager will decide what the team should work on, using heuristics like: - Stuff that allows users to actually start using the product for real work - Stuff that has a very high benefit-to-cost ratio - Stuff we are absolutely certain we need over stuff we think we probably want - (Sometimes) Risky stuff first, to get it out of the way
Compared to other industries, software development has a couple huge advantages: First, once we design and build something, it can be replicated infinitely at almost zero cost. Second, our medium is highly malleable. That is, we can build the equivalent of a 30-story tower, and then replace the first floor with something completely different. Or we can start off thinking we're building an airplane, but halfway through decide that we actually want a cruise ship. For those reasons (and others), it can be difficult to translate project management practices directly between software and non-software fields.
[1] https://en.wikipedia.org/wiki/Agile_software_development [2] http://agilemanifesto.org/ [3] https://en.wikipedia.org/wiki/Software_craftsmanship
Kevin Smith Agile Coach Wikimedia Foundation
*Imagine a world in which every single human being can freely share in the sum of all knowledge. That's our commitment. Help us make it a reality.*
On Mon, Jul 27, 2015 at 5:48 PM, Brian Wolff bawolff@gmail.com wrote:
If it wouldn't be a distraction from other priorities, I'm wondering if project management could be the subject of a Tech Talk sometime. (Cc'ing Rachel who I believe coordinates Tech Talks.)
Thanks,
Pine
You mean like "Kanban: An alternative to Scrum?" https://www.youtube.com/watch?v=zT8cUtMTGPI
-- bawolff
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
wikitech-l@lists.wikimedia.org