You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 30, 2024. It is now read-only.
All credits to @LawnGnome, @eseliger and @mrnugget for coming up with this, crafting presentations and suggesting paths forward.
Context
Today, Batch Changes spreads relatively slowly inside a company and remains used by a limited audience of platform engineers.
Thesis: If we get more users into batch changes through easy-to-use entry points, they will keep using it and some will move to more complicated use cases.
Feature
Use LSIF data to allow users to rename a symbol from a wizard in the code intel popover.
A limitation of this is it requires auto-indexing (or rather it requires LSIF data to be available). But the way we see this is we should not block on auto-indexing adoption to build useful features, rather we should try and make the value of having auto-indexing setup higher.
Delivery plan
Step 1: First, let's prototype this quickly and feature flag it.
There's a “rename this symbol” in the hover tooltips. All it can do then is renaming all occurrences of that one symbol, potentially across repos for which we have LSIF data.
When the user clicks on it, the batch changes page opens, with a preloaded spec that contains the position of the symbol to rename, and a placeholder for users to rename
The spec relies on a pre-bundled container that takes in the reference of the symbol to change, a scope (search query), and the new name of the symbol. See this GraphQL query
Step 2: Will likely be about improving the UI a bit (eg. the symbol new name could be directly input from the popover instead of being changed in the spec).
Later steps will probably be about creating a path that avoids having to see / edit the spec at all (even though users can still tweak it if they want).
Success criteria:
Overall, if this feature is successful, we should see a significant increase of MAUs in the first 3 months of a relevant customer turning it on (at GA).
We can measure more granular success with the # of symbol reaming batch changes created per month.
Analytics
Before we move this to beta, we'll want:
number of clicks on the "rename symbol"
number of batch changes previewed as a result
number of batch changes applied as a result
The text was updated successfully, but these errors were encountered:
All credits to @LawnGnome, @eseliger and @mrnugget for coming up with this, crafting presentations and suggesting paths forward.
Context
Today, Batch Changes spreads relatively slowly inside a company and remains used by a limited audience of platform engineers.
Thesis: If we get more users into batch changes through easy-to-use entry points, they will keep using it and some will move to more complicated use cases.
Feature
Use LSIF data to allow users to rename a symbol from a wizard in the code intel popover.
A limitation of this is it requires auto-indexing (or rather it requires LSIF data to be available). But the way we see this is we should not block on auto-indexing adoption to build useful features, rather we should try and make the value of having auto-indexing setup higher.
Delivery plan
Step 1: First, let's prototype this quickly and feature flag it.
Step 2: Will likely be about improving the UI a bit (eg. the symbol new name could be directly input from the popover instead of being changed in the spec).
Later steps will probably be about creating a path that avoids having to see / edit the spec at all (even though users can still tweak it if they want).
Success criteria:
Overall, if this feature is successful, we should see a significant increase of MAUs in the first 3 months of a relevant customer turning it on (at GA).
We can measure more granular success with the # of symbol reaming batch changes created per month.
Analytics
Before we move this to beta, we'll want:
The text was updated successfully, but these errors were encountered: