Technical Collaboration Guidance/Cases/ORES

Critical review
The goal is to identify points within the TCG that may need clarification, expansion, removal, or some other effect, based on the experience of ORES. Not all feedback will or can be actionable; repeated observations may be necessary to lead to change as more cases are documented.

Principles
Overall, the ORES experience was in-line with the points of the principles.

Points 4 & 5 had feedback:

''4. Collaborative and adaptive - Be developed together. Staff and volunteers should be receptive to feedback, feature requests, and bug reports throughout the lifecycle of a product.'' ''5. Accessible and secure - Provide a consistent, usable experience for all populations, regardless of technical limitations or physical disability. Software and its development should maintain user privacy and site security.''
 * Based on ORES experience, needs some clarity around being informed in order to participate. Product teams can do their due diligence and research, but can then be torpedoed by someone who lacks information on the subject but holds a strong opinion. There was a feeling from the ORES team about a lack of empowerment to call out the under-and-misinformed as being such, that there must be a reciprocity in respect and understanding of the subject at hand in order to collaborate.
 * Lack of clarity around "for whom?" Non-English languages - should only software be accessible, or the communications around it too?
 * The answer is that "accessible" is broadly construed: bandwidth restrictions, visual impairments, language barriers, etc.. These are all things ideally to be taken into consideration.

Private planning
The ORES experience was in-line with the words and philosophy behind planning in public, using the wiki technology for documentation and transparency in doing so. The ORES project started life as a public grant request, and Aaron said he made it a point to move conversations that began in private into public spaces.

There was an emphasis from the ORES experience that documenting and working on public wikis does not mean required advertising for the work being done. There is not a necessity to promote every thing/page/conversation, the point is that it is there in public in the first place. It is also helpful for the ORES team to build pages from the ground-up on wiki, it allows for visualizing the growth of an idea or plan over time as input is received, the page history offers references to past forms of thinking, and building project content this way also mirrors how Wikimedia communities build their content.

The only question from the ORES team in regards to the text on the private planning page was the definition of "infancy," in the sentence "Privacy is often important when an idea is at its infancy, so that the thought can be developed...". This will be addressed.

Translations
The translations page fit overall with the experience of ORES. A few points for discussion: Two related points, also dealing with explicit statements of expectations:
 * More explicit baseline expectations in translations: translations have to occur, and software translations have to occur on translatewiki.net. Other baselines like RTL support could be taken into consideration for explicit requirement.
 * TODO - follow up with Language Engineering the near future for recommendations.
 * Responsibility for translations is not on the translators, it is on the technical producer. Ensuring proper accessibility with regards to language must be owned as any other part of the software development process would be. Which leads to...
 * Engage with the translation process. Proactive outreach to the translation community should be encouraged.
 * This does require absolutely clear channels for translation for it to be truly effective. The translation mailing list is one such absolutely clear channel, but the only other one - translatewiki.net - isn't even a WMF wiki.

Milestone communication
When and How Where What (to say) What (to expect)
 * "Software is being considered and research and discussion is needed" could use as much emphasis as possible. Writing in public helps avoid the silo of team opinions. Develop a prototyping pattern that solicits feedback early and often, prior to the beta stage.
 * "Timelines" could use some clarification or explanation (timelines could be optional with context)
 * Messages written in English should be cognizant if the wiki's primary language is not English. Make sure you are posting in the appropriate place.
 * TODO tidy this up, it's clearer in other places in the TCG. Perhaps more specific than where to post is where *not* to post?
 * Clarity about replies being written for individuals - that this can be considered a form of or part of documentation, the basis for creating an FAQ or related information document.
 * Timelines need clarity around resourcing work
 * What is meant by benchmarks - purpose of this point
 * TODO remember why that is in there
 * Optional point of calling out helpful volunteers for thanks during messaging
 * If all else fails, try again