Talk:Technical Collaboration Guidance/Cases/ORES

I think the review section mixes 2 things - ORES reviewing TCG, and TCG reviewing ORES, so to speak - but all in all, it should work. The tables instead... not entirely sure what I am looking at there. Let's say that getting here from Phab, Q review slides etc. doesn't help me find a recap of findings, and I actually know what I am looking for. Not sure what a PM could get out of this :)

Yes, it is a mutual review. I'm glad that came across as its intent.

The table is a work-in-progress. Hopefully it will make more sense in the future as I work some other things out in the use-case process.

I think that there might be some limits around "translations have to occur". What if the product is only intended for users of a particular language? The TCG is meant to work for volunteer devs, too, including devs that are building something for use only at their home wiki.

Also: What are the devs supposed to do, if no translator chooses to provide translations, despite a reasonable effort to find translators? Some stuff is difficult to translate or just not interesting, and there are times when our volunteer translators are busy with more important work. The WMF could throw extra resources at translation for its own work (there are dozens of multi-lingual staff members, or they could find a few thousand dollars to hire professional translators), but volunteer devs are much more constrained.

I believe the point is using plain language and caring about i18n (point 2 of Principles).

Sure, everyone wants translations.

But what should happen to the product if you can't get translations for an announcement, despite making a reasonable effort?

Nothing? I mean, there are wikis out there whose interface isn't entirely translated. Devs/product teams will do their part, the rest is usually up to others. We are going to work more and more with translators this year though, and maybe we can also discuss this topic with them. I believe there are ways to flag certain stuff as priority, in case it's necessary, although I don't think we ever really used it as a team.

If "nothing" happens when you can't get translations, then "translations have to occur" is a false statement. "Have to" or "must" means "bad things happen if you don't get translations".

It appears that the intended statement is "Product teams must make a reasonable effort to request appropriate translations" – and that it is acceptable if the result of that reasonable effort is zero translations.

/And/ they have to make the same effort to provide content that can actually be translated. I'm pretty sure we never intended to ask anyone for miracles, just their due diligence :) It's a good point that can be addressed - in the same way in which "Responsibility for translations is not on the translators, it is on the technical producer" sounds ominous when you don't also see the rest of the sentence.

Can't we just change that sentence from "translations have to occur" to "translations have to be possible - use plain language and follow the Localisation best practices" ?

(This seems like a mountain/molehill discussion that could have been avoided by just fixing the language in question...) Ping @Keegan (WMF) just in case the others were waiting for your input.

In re Technical Collaboration Guidance/Cases/ORES#Principles, about Point #4:

Could there be some value in providing a simple overview of how to evaluate a product?  It could include things like:

• deliberately considering other use cases (I'm an experienced editor at the English Wikipedia, but this feature will mostly be used by casual readers at small wikis)

• figuring out how you compare to other users (If you've made thousands of edits, you are the "top 1%" rather than a typical user; admins, wikignomes, bot operators, article writers and image uploaders all have different needs; etc.)

• information about how people adapt to changes on websites (Question: How many daily users of Facebook can really picture what the site looked like before its last big redesign?  [Answer:  Almost none.])

• an acknowledgement that it can be difficult to figure out a plan in the early days (especially before screenshots and prototypes exist), that plans do and should change over time, and the value of asking questions
• remembering that – no matter who I am – I'm the expert on my personal experience, but I'm not the expert on your personal experience. Part of the product manager's job is to become an expert on the typical user experience for relevant groups, but my personal experience may be unusual even among people who are demographically similar to me. Also, my personal experience may change over time.

I don't think that a page like this needs to be aimed specifically at the editor–WMF dev situation; it could be equally relevant and helpful for someone who is trying to redesign the Main Page or create a gadget.