Jump to content

Technical Collaboration Guidance/Cases/ORES

From mediawiki.org

Critical review

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]

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

[edit]
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

[edit]

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

[edit]
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

[edit]