Page MenuHomePhabricator

[PLACEHOLDER] Codex support for Wishathon
Closed, ResolvedPublic3 Estimated Story Points

Description

Summary

We should look at the current list of Wishathon projects, particularly the shortlist that has been identified as being actionable during the Wishathon week, and 1) Identify whether we can provide support in implementing this project using Codex, and 2) Use this task to represent providing support to teams that are interested in using Codex for their projects.

Acceptance Criteria

  • We have reviewed the shortlist for tasks already identified as being actionable during wishathon week to identify which we can help with
  • We have reviewed the top tasks in the longlist of wider tasks and called out those that might benefit from using codex to implement
  • We have set aside dedicated time in our sprint (the remainder of this ticket!) to assist those who will be using Codex in their projects

Event Timeline

NBaca-WMF set the point value for this task to 3.Sep 18 2023, 5:12 PM
NBaca-WMF updated the task description. (Show Details)

Shortlist review:

  • "Avoid editing conflicts": Display a message when a user begins editing a page that another user is already editing
    • Type of project: frontend (for displaying the warning and communicating with the server) + backend (for keeping track of active edit sessions)
    • Possible approaches:
      • Show/hide a banner-like message (which could be a Codex Message component, either Vue-based or CSS-only)
      • Show a toast-like notification using mw.notify (which would not use Codex)
      • Show some sort of popup or absolutely positioned message (which there is no Codex component for at present)
      • If the user is using VisualEditor, the message could be integrated with the VE toolbar or another part of VE's UI (which is all built in OOUI, so using Codex would be impractical)
    • Potential for using Codex: low, maybe medium
  • Enable 180°-360° metadata detection and embed/navigate capabilities in Commons/MediaViewer
    • Type of project: mostly backend, some frontend (launch panellum viewer when an image is clicked)
    • Potential for using Codex: low to none, since the frontend aspect is minimal and there's no real new UI
  • Clickable map for coordinate locations (Wikidata)
    • Type of project: frontend (map-based interface for selecting coordinates)
    • Potential for using Codex: low, since this is in the Wikidata UI, which has not yet been migrated from Wikit to Codex; if this migration had been complete, this project would have had high potential for using Codex
  • "Quickly add favorite and related templates": allow users to favorite/bookmark templates so they can quickly insert them in the template insertion dialog
    • Type of project: mostly frontend (display favorited templates in template dialog, affordance for adding a template as a favorite), some backend (storing favorite templates, probably as a user preference)
    • Potential for using Codex: low to medium. All the template insertion dialogs (both the visual and wikitext ones) are built with OOUI, so additions to those would be done in OOUI. But if this involves adding a button on a template page that allows a user to favorite it, that button (or other UI for adding a favorite template) could be built with Codex.
  • Warn when adding a URL reference that matches the SpamBlacklist
    • Type of project: all frontend (adding an API call and a warning to VE's reference insertion UI)
    • Potential for using Codex: none, this is all about modifying a VE UI, and VE is built with OOUI
CCiufo-WMF subscribed.

I'm going to close this task for now. We do not anticipate having to provide additional support at a greater level than our standard time allocated in a sprint to respond to external requests for help.