Page MenuHomePhabricator

Create a workflow about creating/conducting an instrument
Closed, ResolvedPublic2 Estimated Story Points

Description

Description

Regarding experiments we already have a great Workflow called Conduct an experiment that can be used as a tutorial for product developers to know all necessary steps to set up an experiment from the Measurement plan to the launch when the experiment is already running and collecting data.

It seems that we need something similar to the above but for instruments. So far we have a Workflow called Mesaure product health that is the most recent effort to create something similar but it's pretty incomplete. We also have a Guide called Create an instrument that is a guide that describes how to create an instrument following the old way (before xLab and the new JS and PHP xLab SDK existed) and it's also a quite incomplete.

Acceptance criteria

  • Experiment Lab documentation includes a Workflow that describes all the necessary steps to conduct an instrument according to the current way, using xLab and the JS and PHP xLab SDKs

Related Objects

Event Timeline

JVanderhoop-WMF set the point value for this task to 2.

Here is a draft for review.

A few things that I am fuzzy about:

  • Are we renaming xLab or Metrics Platform to Test Kitchen?
  • Code section
    • I made a note in the Client-side instrumentation section that we are moving away from EventLogging to using the mw.xLab module. Is this also applicable to PHP? i.e. are we going to try to move the metrics client out of EventLogging and into the Metrics Platform extension?
  • Test section
    • I err'd on including something about Beta stream but I'm not sure if it's all that helpful in this context. I think in order to actually test the feature code in the Beta Cluster, both the feature code has to be deployed to production and the instrument has to be turned on in xLab/Test Kitchen in order for expected events to show up in the beta stream. Triggering in the console is maybe not all that confidence-building?
    • I thought about adding something about testing in a production wiki i.e. testwiki but I'm not sure if we want to encourage this until we have phased rollouts available.
  • Is there more we want instrument owners to do once their instrument is launched? Should it be documented elsewhere?

Once we're happy with the draft, I can port it to Wikitech and decommission some of the related pages that are redundant.

Are we renaming xLab or Metrics Platform to Test Kitchen?

Not sure about this but I would say that everything will be Test Kitchen somehow. In this case I guess that we will say Test Kitchen UI (as you have said in the draft somewhere). Should we say tkUI?

I made a note in the Client-side instrumentation section that we are moving away from EventLogging to using the mw.xLab module. Is this also applicable to PHP? i.e. are we going to try to move the metrics client out of EventLogging and into the Metrics Platform extension?

I would say that work is still the future so (near future maybe), for now, and we should mention what we have right now. That's what they can use today. Once we migrate to Metrics Platform the only change will be moving from mw.xLab to mw.tk for instrument developers. It won't be a big deal.

I err'd on including something about Beta stream but I'm not sure if it's all that helpful in this context. I think in order to actually test the feature code in the Beta Cluster, both the feature code has to be deployed to production and the instrument has to be turned on in xLab/Test Kitchen in order for expected events to show up in the beta stream. Triggering in the console is maybe not all that confidence-building?
I thought about adding something about testing in a production wiki i.e. testwiki but I'm not sure if we want to encourage this until we have phased rollouts available.

I have added a couple of comments about this in the draft. Not sure if we want instrument developers to use xLab on staging to be able to test via Beta cluster. Also wondering if beta is not needed here. Testing instrument is simpler than testing experiments. I would say local testing could be enough before moving to production. Instrument code, stream configuration and a local eventgate is all you need to test an instrument properly and the local testing environment gives you all that.

Is there more we want instrument owners to do once their instrument is launched? Should it be documented elsewhere?

I have added something to the draft about registering the instrument in the specific section we have in our documentation: https://wikitech.wikimedia.org/wiki/Experimentation_Lab/Instrument_list

I forgot to mention that I have also reviewed the draft. It's looking good! and it's cool to having something like that for instruments.
I left there just several comments/questions/suggestions and things I wonder

Will review!

@cjming could you also check to ensure that we update the related pages about instruments (e.g. https://wikitech.wikimedia.org/wiki/Experimentation_Lab/Stream_configuration)

Ok, reviewed the draft!

As for your questions:

Are we renaming xLab or Metrics Platform to Test Kitchen?

Both! Lots of renaming to do, and I think your draft positions the new name while giving context about the old.

Is there more we want instrument owners to do once their instrument is launched? Should it be documented elsewhere?

The other situation I thought of was "use it in an experiment"?

I have added a few more comments/suggestions according to the renaming we are doing via T407804: Rename Docs to Test Kitchen, specifically according to https://phabricator.wikimedia.org/T407804#11410619