I'd like to propose that we narrow down the list of requirements for the Codex "Alpha" release in the hopes of reaching this milestone sooner. I think that by using the name "Alpha", we can discourage wider usage (beyond one or two designated pilot projects), and getting a packaged version of our code into MW and NPM soon will allow us to test and validate a lot of things more easily.

I'm taking the label "Alpha release" to be synonymous with making Codex (as the library currently stands) available in NPM and in MediaWiki via ResourceLoader. I think that the current Codex codebase, while limited, contains enough components and other features to be ready for testing outside of the project repository now.

Here's what I see as the requirements for a basic Alpha release of this sort:

• T299138 Alpha Release of Codex
  • T294993 NPM Packaging Strategy
  • T299148 Add Codex to ResourceLoader
  • T300280 Identify one or more pilot projects to use the Alpha release and provide feedback (other usage should be discouraged for now)

The sub-epic T299136 could maybe just be merged as a duplicate with T299138.

Once this work is complete, and we have a packaged version of Codex (0.1 / Alpha) available for consumers to work with, I think many of the other tasks listed above could be worked on (some in parallel). I'd recommend organizing those sub-tasks under a new epic for Codex 0.5 or "Beta" release (which would also include all the Typeahead work):

• Beta Release of Codex (aka 0.5; do we have a ticket for this already?)
  • T300081 Typeahead epic
  • T295185 Bi-directionality epic
  • T299143 Test/Staging environment (maybe this should also be an epic)
  • Documentation and process tasks (maybe this should also have an epic)
    • T300053 RTL Design Documentation
    • T300566 Formalize partnership process
    • T300567 Formalize component process
    • T300280 Evaluate Alpha explorations

Finally (some months from now), we could plan out what it would take to get from "Beta release" (which would allow decommissioning of WVUI, Wikit, and the Vue 3 compat build) to a full "1.0" release intended for wider usage. In order to get to that point we will probably also need to address some general questions about when/where teams should use Vue (T289208 and T279421 for instance); hopefully by then we'll also have a clearer idea of how to proceed in terms of SSR or progressive enhancement solutions, whether we want/need a front-end build step, etc.

@egardner thank you so much for this feedback! I'm also in favor of narrowing things down, and it makes sense to move the documentation out. Better testing capabilities would be nice to have before we get too far down the road but it depends on the pilot project, and I can see us having a separate bucket for SDLC improvements that we address in parallel.

RE: naming... I've been conflating "Beta" with "0.5" and the TypeaheadSearch/deprecation work. I created an epic for the WVUI deprecation in [T300081] to tackle first, which will be followed by one for WiKit (decided last week when meeting with Readers Web). I moved all of this into a roadmap sketch and will share that with the internal team today - hopefully that will make things less confusing and we don't have to hold on to this information in our heads. I'm reviewing notes from the Abstract Wiki exploration this week too, and we can lock in the Alpha requirements with the team on Monday.

I've updated the version number to align with the consensus of DST engineers on how we want to handle numbering.

After rethinking how our epics for releases are structured, I'm going to update this task to reflect our initial Codex release rather than a catch-all for all Alpha releases.