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.

• 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.

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.

• 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:

• 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.

Two related points, also dealing with explicit statements of expectations:

• 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

• "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)

Where

• 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?

What (to say)

• 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

What (to expect)

• If all else fails, try again

Structure

		Essence of the initiative			Enabling Platform
		Logic models	Stakeholder engagement	Authority	Functions	Standards
Timeframe	Big picture	Machine classification for edit/article quality Measured social change towards newcomers	Subject-matter experts consulted for framing Collaboration in building	Benevolent dictator but Right and easy to fork	Restricted grant Annual plan	FOSS Ethical algorithmic practice
	Strategy	Linear sequential stages (per track)	Identify local contact Checklists for communities Facilitate documentation	Simple, off-the-shelf technologies Expertise and instruction	Stakeholder discussion Off-wiki forums Researchers	Transparency Accountability and auditing (track provenance) Respect boundaries Dedicated space for communication
	Project	Linear sequential tasks (per stage)	Tag local contact(s) Broadcast open tasks	Consensus model - do the thing, discuss if needed	Project manager	Two sets of eyes Pull request pattern from Github Don't deploy low fits
	Event	Completion of task	Captured in task	Core project team	Gerrit Phabricator Movement broadcasting	Tasks are not closed until reported back on

ORES auditing tool

Draft stages

1. Public planning - Aaron to post a proposal for the project on Meta, mid-May 2017. The proposal will help scope the features.
2. Wireframes - before prototyping and alpha, wireframes will be posted in July for UI/UX and feature discussion
3. tbd

Structure

		Essence of the initiative			Enabling Platform
		Logic models	Stakeholder engagement	Authority	Functions	Standards
Timeframe	Big picture	Aspirational goal(s)	Collaborative philosophy	Executive governance	Funding authority	Operating vaules
	Strategy	Stages and milestones	Stakeholder analysis and design	Strategic governance	Identify key operations functions and designing operations management	Institutional commitments
	Project	Work breakdown	Project teams	Operations management	Performance of operation functions	Policies, procedures, charters
	Event	Agenda	Group dynamics	Event management	Event logistics	Ground rules and norms

See also

• Meta-ORES