Talk:Wikimedia Engineering/2016-17 Q4 Goals

"semper paratus"relevant,submisive,subordinate,presumptious beautiful and bold

It would be good to have this out of beta by the end of Q4. See 2017 wikitext editor.

Thank you for the vote of confidence, but I think it's a little premature to be pushing it to be out of beta so soon.

Right now we're still fixing bugs and considering various feature and design change requests (for example, people want a quicker way to see "show preview", and the current wikitext editor provides in-editor help on how to use wikitext which we should replicate or improve).

I imagine in this coming quarter we'll release a second version of the beta for wider adoption, and get it finished for mobile Web users, at which point we could start identifying what further testing we would need before getting it out of beta.

OK, a Beta 2 would certainly be progress. Do you think that moving it into production on desktop would be realistic by EOQ of Q1 2017-2018?

Probably not. I also think that deadlines like that are unhelpful; they create a rush for action over a push for quality. In general I'm more keen for us to make people happy than to hit some arbitrary point in time, which is why our commitments are of that flavour.

I think that a goal (rather than a deadline) is still helpful. Could something about the 2017 Wikitext editor be added to Wikimedia Engineering/2016-17 Q4 Goals#Editing?

What kind of thing are you expecting, and what do you think will change / who will be better served because of it? Adding more goals adds complexity to reporting but it doesn't magically create resourcing to do them.

From my perspective -- and this is based on my guess about the purpose of having quarterly goals structured as they are on the document that we're discussing, and my guess may be wrong -- highlighting that progress on the 2017 Wikitext editor as one of the quarterly goals would suggest that it is an Important Issue(TM) and not a minor maintenance issue, and that both the community and WMF leadership can expect regular updates about the project's progress. From my perspective the downside to increased reporting is modest and the upside of more visibility is very valuable.

Getting the Newsletter extension into production would be good.

It would be helpful for the LearnWiki project to have all UI color standardization completed by the end of Q4 or mid-Q1 of 2017-2018 so that there aren't color changes after the videos are produced.

It would be good to have any icon changes (if planned) completed as well, by the end of Q4 or mid-Q1 of 2017-2018

For Tech Ops, I'd like to see significant progress on this as a Q4 goal: https://phabricator.wikimedia.org/T156544

For Security, I'd like to see a goal of making CAPTCHAs more user-friendly and bot-hostile.

What does this mean: "For the first time, reviewers will have data about user intent."?

The collaboration team is working on new filters for recent changes that use ORES predictions models. That way, reviewers will be able to help newcomers who do edits in good faith but do mistakes or to focus on edits that are clear vandalism.

Thanks! But would it be better to call that automatic classification of quality than user intent? No matter either way.

Well, you can have a low quality wording with a good source, which is better than a high quality wording with no source or a bad one.

The intent from the first case is better while the quality of the second one is higher, as documented on ORES page (IIRC).

@Dario (WMF): do you want to do data collection for pronunciation instruction internally?