Hosting: manual integrations via build contract #10127

humitos · 2023-03-08T12:27:39Z

Integration and design for the future of the Read the Docs features integrations.

Requires generating the readthedocs-client.js from (https://github.com/humitos/readthedocs-client) and copying to this repository and then collecting the statics:

cp ../readthedocs-client/dist/readthedocs-client.js readthedocs/core/static/core/js/readthedocs-client.js
inv docker.manage 'collectstatic --noinput'

Goals

Integrate all the Read the Docs readers' features (e.g. flyout, doc-diff, warning banners, etc) with any doctool.
Remove the requirement to install extra Python packages to integrate with us (e.g. readthedocs-sphinx-ext, readthedocs-sphinx-search)
Generate the exact same output when running the doctool locally than on Read the Docs (except for conditionals using READTHEDOCS environment variables)
Reduce complexity from the current hosting integrations (some happen inside the builder, others inside the Sphinx extension, others in the Sphinx theme, and others in the frontend)
Move all the logic for these integrations to the frontend
Use modern JavaScript patterns to write all these integrations (see https://github.com/readthedocs/meta/discussions/114)

Workflow

User triggers a build with any doctool (common process, build.jobs or custom commands via build.commands) ¹
(Optional) The doctool creates a $READTHEDOCS_OUTPUT/html/readthedocs-build.yaml file at build time with a pretty known structure (the "build contract" that we need to define, but we have an idea of what fields are required already) ²
Before finishing the build process, the builder reads readthedocs-build.yaml and stores its data into the Version object. This will be used to communicate data from the builder to the frontend.
El Proxito injects, at serving time ³, the Read the Docs javascript client (readthedocs-client.js)
The readthedocs-client.js file loads all the extra required JS and CSS files dynamically.
These javascript files use an API call (/_/readthedocs-config.json) to get all the config required to perform the hosting integrations. The data generated at build time via readthedocs-build.yaml is also returned by this endpoint. Note that some of this "hosting integrations" are already implemented in our Sphinx extensions and they have to be re-written into Javascript. I migrated some basic one for now and put them into the client repository as an example.
These integrations are: version warning, pull request warning, search, doc-diff, hoverxref, ethicalads, search/traffic analytics, etc

Integration points from a user's perspective

Nothing.

Optionally, the user could configure the build process to generate the readthedocs-build.yaml at build time with a specific structure (to be defined) to communicate some extra data that's only known at build time.

v2 and future projections

Make each hosting feature to be enabled/disabled at build time
Make each hosting feature to be enabled/disabled by the reader
Allow override the HTML templates injected (e.g. those used to generate the warning banners)
Allow override the logic used to inject those HTML blobs (e.g. use a different function to decide if the warning banner has to be injected or not --useful when not using semver)
Validate readthedocs-build.yaml and enforce a specific structure

External related issues

Read the Docs pass data to the doctool via environment variables. Exactly as we are doing now. However, we may want to add some extra variables (see Build: expose VCS-related environment variables #9423) ↩
This YAML file is the way for the doctool to pass back data to Read the Docs and configure its integrations ↩
It's done at NGINX for now, but it can be feature flagged and done at CloudFlare ↩

dockerfiles/nginx/proxito.conf.template

ericholscher · 2023-03-08T21:37:27Z

This is a really interesting example. I like how it basically just duct tapes the pieces together, and doesn't require any user interaction. There's a bunch of design discussions downstream of this, but just having an example of how this might work is great. It's a lot less hacky if we ship integrations.js to the users and themes, and they optionally integrate it.

Let's chat more about this tomorrow, since I don't know what level of feedback is particularly useful at this stage, but I think we can get pretty close to something we could share with users as a demo at least.

Instead of prepending all the commands with the `PATH=` variable, we pass the environment variable directly to the Docker container. This allow us to run multi-line shell script without failing with weird syntax errors. Besides, the implementation is cleaner since all the environment variables are passed to the commands in the same way. I added some _default paths_ that I found by checking the local Docker container. I'm also passing the users' path, depending if we are working locally as root or in production. This is not 100% complete and there may be some other issues that I'm not seeing yet, but I think it's a first step to behave in a way our users are expecting. Closes #10103

Locally it tries to reverted back 🤷

…s/readthedocs.org into humitos/hosting-integrations

X-RTD-Hosting-Integration: true/false This can be used from CloudFlare to decide whether or not inject a `<script>` into the resulting HTML or not.

humitos · 2023-03-10T21:27:14Z

It's a lot less hacky if we ship integrations.js to the users and themes, and they optionally integrate it.

We touched on this in our call already, but I want to make my position clear about this here. IMO, we have to force the injection of our own JavaScript file. Otherwise, many projects won't include our JavaScript and most of the good features we offer won't be present in their documentation. Even people wanting to integrate with us, will have a bigger barrier to do it. In particular, commercial customers. Besides, on the community side, most projects won't have ads --which is not a minor.

I think if we don't inject the JavaScript automatically, we won't differentiate ourselves from GitHub Pages or any other plain-text hosting, I'd say.

humitos · 2023-03-10T21:27:42Z

I updated the description of this PR with a lot more context and a more polished idea of how all these pieces fit together.

agjohnson · 2023-03-10T22:44:10Z

Overall, this implementation looks great, especially considering the boundaries on goals. I think it's helpful to get some experimentation here on the backend implementation, and have some direction at a high level on how we'll inject JS.

All of my questions, and all the places I want to put a bit more thought on patterns and API design are in your v2 list. The goals seem great, and for that, I'd 100% skip the V2 parts of the JS implementation -- HTML templates, API overrides, etc. This is where I'll have the most technical input, there are features from Webpack we'll use here, and extra libraries we'll rely on.

It's still fuzzy to me why a readthedocs-build.yaml file is required for this. I'm not against this design, it's just not clear to me. I probably haven't moved much here since #9088

Do you have a better idea now of what configuration options we need to be in an contract file?

The features list in the contract file stand out still -- and I'm just talking in context of a contract file, not feature enabling/disabling API design or patterns for the next iteration of this work. A contract file may help with reproducible builds somewhat, but there's also very real cases where configuring features at the request level will be much better UX:

How would an author disable search/docdiff/etc across multiple versions? They update an option in the admin UI and rebuild all of their versions?
If this is controlled in a version controlled file, how does an author disable search/docdiff/etc on tagged versions? They have to alter the tags and rebuild all tag versions?

I see some benefit to controlling features at the request level and configuring them in the admin dashboard. We'd use the same data structure, but included in the documentation via a https://docs.example.com/_/features.json type file that is dynamically generated.

IMO, we have to force the injection of our own JavaScript file

I'd agree, and I think we can very easily keep the footprint of this file very minimal as well.

readthedocs/core/static/core/js/integrations.js

readthedocs/doc_builder/templates/doc_builder/readthedocs-data.html

readthedocs/core/static/core/js/integrations.js

humitos · 2023-03-11T11:54:34Z

@agjohnson

It's still fuzzy to me why a readthedocs-build.yaml file is required for this. I'm not against this design, it's just not clear to me. I probably haven't moved much here since #9088
Do you have a better idea now of what configuration options we need to be in an contract file?

This space is reserved for all the configuration that only the doctool knows at build time (or that needs to be generated dynamically). I understand why you are not finding it required and that's probably because all the data that I put as example there is not mandatory.

We need more feedback from other doctools (and users!) here to find out if there are things we strictly require from them. I don't have that information yet and we should keep trying out other doctools as I was doing previously and keeping this in mind.

For now, I refactored a little the readthedocs-build.yaml proposed to have only two main keys:

telemetry: contains all the data the doctool can share with us for telemetry purposes ¹
features: communicate us what are the features the author wants to integrate with us ²

I see some benefit to controlling features at the request level and configuring them in the admin dashboard. We'd use the same data structure, but included in the documentation via a https://docs.example.com/_/features.json type file that is dynamically generated.

@ericholscher and I briefly touched on this idea on Thursday. I thought it could be a good idea to have the ability to decide things dynamically at request time. However, I didn't come up with good arguments while talking about this. Also, Eric mentioned it was simpler to just serve a .json file directly from S3, which was a good argument and we just moved on 😄 .

I think the questions you are rising here are important and may make us to use an endpoint as you are suggesting. If that's the case tho, all the feature key to decide the integrations don't make sense to be in the YAML file anymore and they would become db fields (at Project or Version level). That would be another long conversation to have that I'm not sure if it makes a lot of sense at this immediate time. I'm happy to have it, tho, but I don't want to detour too much from the other bigger concepts and be able to start moving forward making the first step of the plan.

That said, I understand that you agree with 80% of this proposal --without considering the specific JavaScript technical aspects. That missing 20% would be:

reduce complexity by skipping the readthedocs-build.yaml for now until we find it's strictly required
make the data coming dynamically from an endpoint under /_/ at docs domain instead of just a file in S3
decide how we will inject the JS (at build time on each HTML, NGINX, CloudFlare, etc)

I know you said "we'd have to consider if we want community provided telemetry even" in https://github.com/readthedocs/readthedocs.org/issues/9088#issuecomment-1331246443. We can skip it for now if we want to, but probably worth to start having that conversation at least. ↩
you said this could be moved directly into the .readthedocs.yaml; which I see it totally doable ↩

ericholscher

This is a really simple, beautiful implementation. I think we can trim down the amount in this PR already, and get something shipped.

dockerfiles/nginx/proxito.conf.template

ericholscher · 2023-03-15T22:03:56Z

readthedocs/core/static/core/js/readthedocs-client.js

Do we want to ship this with the app, or version it directly on S3, like we do with the ad client? I think keeping it deployable outside of the application seems right to me.

https://github.com/readthedocs/ethical-ad-client/tags

https://media.ethicalads.io/media/client/v1.4.0/ethicalads.min.js

I haven't thought too much about this and I don't have experience deploying the script with a different process than the normal one. I'm not sure about the pros/cons here.

I put this file here because we need it for development as well. We could just put this file in the local MinIO S3, tho, as well.

Note this file is generated by running npm run build from another repository.

We need to also think about what version are we going to serve by default. The latest one? Would people be able to pin to a particular version? Are we going to support multiple versions at the same time? How do we deploy new features to those that are pinned to an older version? Do we care? Too many questions 🤷🏼

I think we always deploy the latest, but if the goal is for other people to integrate the library, then it can be versioned based on their needs. The versioning is primarily valuable for strict SRI protection, like PyPI does, to validate the hash of the library hasn't changed for security reasons.

I think we should definitely deploy the client outside of our application. We don't need to decide on a proper deployment pattern yet though, but I think we should keep it out of the application from the start.

For now, we can just manually upload it to S3, and use that everywhere?

readthedocs/doc_builder/director.py

ericholscher · 2023-03-15T22:06:01Z

readthedocs/doc_builder/director.py

+        # Copy the YAML data into `Version.build_data`.
+        # It will be saved when the API is hit.
+        # This data will be used by the `/_/readthedocs-config.json` API endpoint.
+        self.data.version.build_data = data


Do we want to actually parse the data into memory, or just store the file contents directly as a string? I think we just want to store a string to start? I'd like to avoid as much YAML parsing as possible...

I also wonder if we should make this file JSON, instead of YAML? If the goal is for it to be aligned with the JSON data returned via the API, I think that makes more sense. But if it's closer to our .readthedocs.yaml config, then YAML makes sense 🤔

Do we want to actually parse the data into memory, or just store the file contents directly as a string? I think we just want to store a string to start? I'd like to avoid as much YAML parsing as possible...

I think we will need to parse it so we can validate it at some point, anyways.

This also allows us to use a JSON field in the database that we can query in the future, looking for answers.

I also wonder if we should make this file JSON, instead of YAML? If the goal is for it to be aligned with the JSON data returned via the API, I think that makes more sense. But if it's closer to our .readthedocs.yaml config, then YAML makes sense thinking

I decide to use YAML here on purpose. It's a lot easier to write than JSON, a lot less nit picking (e.g. requires no trailing comma in the last element of a list), supports comments, works better with more data types, and others. The structure is going to be just a dictionary, YAML is going to be just the representation/serialization of it

In particular, being able to put comments in .readthedocs.yaml is important for ourselves and our users as well. That was one of the reasons why I picked YAML for this file as well. Otherwise, you end up with things like this in JSON:

readthedocs.org/readthedocs/proxito/views/hosting.py

Lines 36 to 39 in 48de597

"comment": (

"THIS RESPONSE IS IN ALPHA FOR TEST PURPOSES ONLY"

" AND IT'S GOING TO CHANGE COMPLETELY -- DO NOT USE IT!"

),

Yea.. let's use YAML for anything human-writable, and JSON for machine-writable 👍

readthedocs/proxito/middleware.py

ericholscher · 2023-03-15T22:07:37Z

readthedocs/proxito/views/hosting.py

+        # TODO: why the UnresolvedURL object is not injected in the `request` by the middleware.
+        # Is is fine to calculate it here?
+        unresolved_url = unresolver.unresolve_url(request.headers.get("Referer"))
+        version = unresolved_url.version


@stsewd seems like one for you.

@humitos I see we're using the referer here. Is this because we don't want to pass in the domain explicitly as a GET arg? I think we likely want to actually use the request.host here, instead of a header that the browser is setting.

@humitos I see we're using the referer here. Is this because we don't want to pass in the domain explicitly as a GET arg? I think we likely want to actually use the request.host here, instead of a header that the browser is setting.

Not strong preference. We can use something different here. I used the Referer because it was what I had at hand and easy to get.

A url= GET attribute probably seems fine as well, since it's what we are using in other API endpoints (analytics and embed api, for example). Referer also makes testing harder since "copying and pasting a URL doesn't work" --I've ended up hardcoding the URL in the code because of this 😅

I think we should combine both, url= GET attribute with a validation with request.host on that URL.

ericholscher · 2023-03-15T22:10:48Z

readthedocs/proxito/views/hosting.py

+        # TODO: define how it will be the exact JSON object returned here
+        # NOTE: we could use the APIv3 serializers for some of these objects if we want to keep consistency.
+        # However, those may require some extra db calls that we probably want to avoid.
+        data = {


It seems like we're re-creating the footer API, but with JSON instead of HTML. That seems reasonable, but I do think we'll want to think more about what this API is returning.

It seems like we actually want the client to be able to tell us exactly what data points they want? Something similar to what we're doing with apiv3 with the expand and fields parameters? That way we give the caller control over how much data they want...

That might be an over-optimization at this stage, but I think we want to design this with expandability and performance in mind.

I do think we'll want to think more about what this API is returning.

Yes. This is one part of the design decisions I mentioned we have to sit down, talk together, think about and decide what's the best structure.

It seems like we actually want the client to be able to tell us exactly what data points they want? Something similar to what we're doing with apiv3 with the expand and fields parameters? That way we give the caller control over how much data they want...

This is a good point to start considering and thinking about, yeah. However, I don't think we will require that complexity because:

the API endpoint will be cached

most of the values are static

there are a few db queries only (Project and Project.versions(active=True))

we could decide whether or not return some specific data based on the feature being enabled. If non_latest_version_warning is disabled, we don't calculate/query nor return the list of active versions this feature consumes in the client.

In any case, I think we will arrive at the best answer by exploration, experimentation and brainstorming. Also, once we deploy this, we will have some data in NR to know how much time this endpoint takes on a real production db.

Yea, I don't think the performance of this approach is inherently bad, but more that we might want to make this look more like an API for additional UX options in the future. No user will expect passing GET args to a .json file. However, if the file doesn't grow too large, always returning all of it too bad. But I do expect we'll feel constrained by the design in the future, as we want to make this endpoint smarter, so starting with an API instead of a JSON file seems like the proper design to me.

To be clear, I'm fine shipping this as a test for now.

But I do think over time if this is the "one endpoint to get all the data you need in the page", there will be demands on this functionality that are resource intensive, vary by user, etc. That is where we'll start to get value from the API approach.

Good point about the .json name in the URL endpoint. We should definitely change that as first step.

I will think a little more about the expand argument. I don't have a strong opinion on that yet 😅

When we get to discussing the API structure in the next phase, this would be a good conversation. This API could help us avoid APIv3 complexity.

Also on the difference between this and our API, would it make sense to use DRF APIv3 resources directly in the response here, or make this an APIv3 endpoint? This way weren't not making a 4th API version of sorts. The response for versions could be identical to the APIv3 response for versions as well.

We'll come back to the data security question around private projects/versions pretty quick here, but we need to already for this API endpoint and private projects.

…mitos/hosting-integrations

ericholscher

I'm good to ship this initial experimentation next week so we can play with it in production.

Alternatively, we could just use defaults in the readthedocs-client, and not require a server response for initial testing? We could also just return some JSON data via a CF Worker to make it faster to iterate with this, instead of requiring a full Django deploy.

readthedocs/doc_builder/director.py

readthedocs/proxito/views/hosting.py

humitos · 2023-03-17T15:43:26Z

Alternatively, we could just use defaults in the readthedocs-client, and not require a server response for initial testing?

I'd prefer if we can get this from the server itself. This will also help me to understand how much time this endpoint takes to return via NR and also confirm that everything is on it's place.

We could also just return some JSON data via a CF Worker to make it faster to iterate with this, instead of requiring a full Django deploy.

This is a good option in case we need it, yeah. I'm not sure how many times we will be changing this response. It's definitely gonna change, and big, probably. But maybe it changes once, it's done. The main changes are gonna happen in the js client, without requiring too much changes in the API response, I'd guess.

In any case, we can keep doing all the test of these stuffs locally while developing. We can also deploy more often if required 😉

ericholscher · 2023-03-17T16:25:24Z

In any case, we can keep doing all the test of these stuffs locally while developing. We can also deploy more often if required 😉

But then I can't play with it :) I guess there's always ngrok, or I just get it running locally :)

humitos · 2023-03-17T18:23:45Z

He he. Note that you can add/update data from the build process itself, by creating a YAML file 😉. That will give us some extra control to perform changes in the API response without deploying 😏

humitos · 2023-03-17T18:25:02Z

So, we can change the js client by just uploading a new js file to S3.

We can change the API response by generating a YAML file in the build process

This file will be deployed directly into S3.

…mitos/hosting-integrations

humitos · 2023-03-20T10:41:15Z

Latest updates:

rename the endpoint to remove .json from it
fix the serializer to save Version.build_data
remove readthedocs-client.js from this repository
use development URL for js client to work locally

I'm going to merge this PR once all tests pass.

humitos · 2023-03-20T13:04:12Z

I don't understand why I'm receiving eslint issues now 🤷🏼 . I'm merging this PR for now because those errors look pretty unrelated to my work here. We can solve the issue in another PR.

stsewd

There is one call to open that we should replace with safe_open before deploying this change

stsewd · 2023-03-20T15:32:38Z

readthedocs/doc_builder/director.py

+            return
+
+        try:
+            with open(yaml_path, "r") as f:


We should use readthedocs.core.utils.filesystem.safe_open here

stsewd · 2023-03-20T15:36:56Z

readthedocs/proxito/views/hosting.py

+        # TODO: why the UnresolvedURL object is not injected in the `request` by the middleware.
+        # Is is fine to calculate it here?


Only the unresolved domain is injected for all proxito views, the unresolved URL is needed only when serving docs, so you need to call it manually only when you need it. And you are parsing the URL from a query param, so you need to call it manually anyway.

humitos added 2 commits March 8, 2023 11:59

Hosting: manual integrations via build contract

5b28071

Use a single script to load everything

e18b40f

humitos self-assigned this Mar 8, 2023

humitos added 7 commits March 8, 2023 14:06

Include Read the Docs analytics to integrations

7754d5f

Initial work for hosting features

2925ed9

External version banner and doc-diff integration

3385649

Old version warning

1e391b8

Do not inject doc-diff on search page

6afca0b

Inject old version warning only for non-external versions

7ce98a4

Comments!

3ca96ec

humitos commented Mar 8, 2023

View reviewed changes

dockerfiles/nginx/proxito.conf.template Outdated Show resolved Hide resolved

More comments

f4f1268

humitos added 8 commits March 9, 2023 11:40

Lint: for some reason fails at CircleCI otherwise

33fdb2b

Locally it tries to reverted back 🤷

Merge branch 'humitos/build-cmd-environment' of github.com:readthedoc…

4ced5c3

…s/readthedocs.org into humitos/hosting-integrations

Feature flag for new hosting integrations

ea2af4c

X-RTD-Hosting-Integration: true/false This can be used from CloudFlare to decide whether or not inject a `<script>` into the resulting HTML or not.

Load readthedocs-build.yaml and generate readthedocs-data.html

79b7393

Load READTHEDOCS_DATA async

17effaf

Absolute proxied API path

2b9cdbf

Remove duplicated code

0116f41

humitos changed the base branch from main to humitos/build-cmd-environment March 10, 2023 22:03

agjohnson reviewed Mar 10, 2023

View reviewed changes

readthedocs/core/static/core/js/integrations.js Outdated Show resolved Hide resolved

agjohnson reviewed Mar 10, 2023

View reviewed changes

readthedocs/doc_builder/templates/doc_builder/readthedocs-data.html Outdated Show resolved Hide resolved

agjohnson reviewed Mar 10, 2023

View reviewed changes

readthedocs/core/static/core/js/integrations.js Outdated Show resolved Hide resolved

humitos mentioned this pull request Mar 11, 2023

Build: implement build output contract #9088

Closed

ericholscher reviewed Mar 15, 2023

View reviewed changes

doc-diff object returned

0f89186

Base automatically changed from humitos/build-cmd-environment to main March 16, 2023 11:44

humitos added 4 commits March 16, 2023 12:56

Build: check if the YAML file exists before trying to open it

48de597

Proxito: don't inject the header if the feature is turned off

4b05e77

Merge branch 'main' of github.com:readthedocs/readthedocs.org into hu…

e90af75

…mitos/hosting-integrations

Test: add hosting integrations tests

364de9c

ericholscher approved these changes Mar 17, 2023

View reviewed changes

readthedocs/doc_builder/director.py Show resolved Hide resolved

readthedocs/proxito/views/hosting.py Outdated Show resolved Hide resolved

humitos added 7 commits March 20, 2023 10:09

Remove JS

c1cf8cb

This file will be deployed directly into S3.

Load the javascript from a local server for now

3930915

Update URL to remove .json from it

2d7b6fe

Remove non-required f-string

ab43635

Allow saving build_data via API endpoint

85ab2e7

Merge branch 'main' of github.com:readthedocs/readthedocs.org into hu…

3439e24

…mitos/hosting-integrations

Lint

6154c7f

humitos enabled auto-merge (squash) March 20, 2023 10:41

humitos added 2 commits March 20, 2023 12:12

Migrate nodejs installation to asdf

0e8f245

Change port to match npm run dev from readthedocs-client

a6c5977

humitos disabled auto-merge March 20, 2023 13:04

humitos merged commit ed732c2 into main Mar 20, 2023

humitos deleted the humitos/hosting-integrations branch March 20, 2023 13:04

stsewd reviewed Mar 20, 2023

View reviewed changes

This was referenced Mar 20, 2023

Build: use safe_open for security reasons #10165

Merged

Javascript client: search-as-you-type API response #10196

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Hosting: manual integrations via build contract #10127

Hosting: manual integrations via build contract #10127

humitos commented Mar 8, 2023 •

edited

Loading

ericholscher commented Mar 8, 2023

humitos commented Mar 10, 2023

humitos commented Mar 10, 2023

agjohnson commented Mar 10, 2023 •

edited

Loading

humitos commented Mar 11, 2023 •

edited

Loading

ericholscher left a comment

ericholscher Mar 15, 2023

humitos Mar 16, 2023

humitos Mar 16, 2023

ericholscher Mar 16, 2023 •

edited

Loading

ericholscher Mar 15, 2023 •

edited

Loading

humitos Mar 16, 2023

ericholscher Mar 16, 2023

ericholscher Mar 15, 2023

humitos Mar 16, 2023

ericholscher Mar 15, 2023

humitos Mar 16, 2023

ericholscher Mar 16, 2023

ericholscher Mar 16, 2023

humitos Mar 17, 2023

agjohnson Mar 17, 2023

ericholscher left a comment

humitos commented Mar 17, 2023

ericholscher commented Mar 17, 2023

humitos commented Mar 17, 2023

humitos commented Mar 17, 2023

humitos commented Mar 20, 2023

humitos commented Mar 20, 2023

stsewd left a comment

stsewd Mar 20, 2023

stsewd Mar 20, 2023

	"comment": (
	"THIS RESPONSE IS IN ALPHA FOR TEST PURPOSES ONLY"
	" AND IT'S GOING TO CHANGE COMPLETELY -- DO NOT USE IT!"
	),

		# TODO: why the UnresolvedURL object is not injected in the `request` by the middleware.
		# Is is fine to calculate it here?

Hosting: manual integrations via build contract #10127

Hosting: manual integrations via build contract #10127

Conversation

humitos commented Mar 8, 2023 • edited Loading

Goals

Workflow

Integration points from a user's perspective

v2 and future projections

Related

External related issues

Footnotes

ericholscher commented Mar 8, 2023

humitos commented Mar 10, 2023

humitos commented Mar 10, 2023

agjohnson commented Mar 10, 2023 • edited Loading

humitos commented Mar 11, 2023 • edited Loading

Footnotes

ericholscher left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericholscher Mar 16, 2023 • edited Loading

Choose a reason for hiding this comment

ericholscher Mar 15, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ericholscher left a comment

Choose a reason for hiding this comment

humitos commented Mar 17, 2023

ericholscher commented Mar 17, 2023

humitos commented Mar 17, 2023

humitos commented Mar 17, 2023

humitos commented Mar 20, 2023

humitos commented Mar 20, 2023

stsewd left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

humitos commented Mar 8, 2023 •

edited

Loading

agjohnson commented Mar 10, 2023 •

edited

Loading

humitos commented Mar 11, 2023 •

edited

Loading

ericholscher Mar 16, 2023 •

edited

Loading

ericholscher Mar 15, 2023 •

edited

Loading