Add a more informational README#55
Conversation
| Additionally, a workflow should include: | ||
|
|
||
| * A descriptive title that includes the name of the command. | ||
| * A description for the workflow and each of its argument, if applicable. |
There was a problem hiding this comment.
Maybe include something here about how the name/description are used in search? Also - maybe something about categories as well?
vorporeal
left a comment
vorporeal
left a comment
There was a problem hiding this comment.
So much better! Left some comments on incremental improvements/adjustments to wording.
| Workflows can be accessed within Warp directly within the app, either through the Command Palette or by pressing `ctrl-shift-r`. | ||
| Workflows can be accessed directly within Warp, either through the Command Palette or by pressing `ctrl-shift-r`. | ||
|
|
||
| All public workflows (i.e. workflows within this repo) are also available at [commands.dev](https://www.commands.dev/). |
There was a problem hiding this comment.
You used the term "global" above but "public" here - desired? Should we standardize on one or is the semantic difference meaningful here?
There was a problem hiding this comment.
yeah it's a good question--I think "public" is clearer, will do a pass to make that consistent
| # The name of the workflow. | ||
| name: Uninstall a Homebrew package and all of its dependencies | ||
| # The corresponding command for the workflow. Any arguments should be surrounded with two curly braces. E.g `command {{arg}}`. | ||
| command: "brew tap beeftornado/rmtree\nbrew rmtree {{package_name}}" |
There was a problem hiding this comment.
Thoughts on using YAML's support for multi-line strings here? IMO this field benefits from having easily readable contents (reduced chance of bugs), and this example should highlight the desired style.
Something like:
command: |-
brew tap beeftornado/rmtree
brew rmtree {{package_name}}
# Any tags that workflow should be categorized with.
tags:
...| name: Uninstall a Homebrew package and all of its dependencies | ||
| # The corresponding command for the workflow. Any arguments should be surrounded with two curly braces. E.g `command {{arg}}`. | ||
| command: "brew tap beeftornado/rmtree\nbrew rmtree {{package_name}}" | ||
| # Any tags that workflow should be categorized with. |
There was a problem hiding this comment.
nit: "Any tags that the workflow should be categorized with."
| name: Uninstall a Homebrew package and all of its dependencies | ||
| # The corresponding command for the workflow. Any arguments should be surrounded with two curly braces. E.g `command {{arg}}`. | ||
| command: "brew tap beeftornado/rmtree\nbrew rmtree {{package_name}}" | ||
| # Any tags that workflow should be categorized with. |
There was a problem hiding this comment.
Do we have any restrictions on what tags can/should be added here (for global/public workflows)? I expect we don't want the in-app list to grow too long (it would, in the extreme, make search the only way to reasonably find workflows in-app).
There was a problem hiding this comment.
yeah I'm adding that as a section in the "what makes a good workflow" section--ideally we don't want too many unnecessary tags
| # The URL of original author of the Workflow. For example, if this workflow was generated from StackOverflow, the `author_url` would be the StackOverflow author's profile page. | ||
| author_url: "https://stackoverflow.com/users/207894" | ||
| # The valid shells where this workflow should be active. If valid for all shells, this can be left empty. | ||
| shells: [] |
There was a problem hiding this comment.
Forward-thinking: Is this due to some shells (i.e.: fish) having different syntax? If so, would we want to consider supporting multiple command values so that there could be per-shell overrides?
There was a problem hiding this comment.
yeah that's another fair way of approaching it--I think both are valid fwiw. The reason I prefer writing it like this is that arguments could also differ between the two commands, in which case you end up essentially creating two workflows anyway. It also makes things like author accreditation hard.
| ```bash | ||
| mkdir -p ~/.warp/workflows && cp {{workflow}}.yaml; ~/.warp/workflows/ | ||
| ``` | ||
| 2) Open Warp and open workflows by pressing `ctrl-shift-r` or using the command palette. |
There was a problem hiding this comment.
Should "workflows" be capitalized when we're talking about the UI component (e.g.: "Open Warp and open Workflows" or "Open Warp and open the Workflows panel")?
There was a problem hiding this comment.
from chatting with Zach I think we want to keep it lowercase
| Additionally, a workflow should include: | ||
|
|
||
| * A descriptive title that includes the name of the command. | ||
| * A description for the workflow and each of its argument, if applicable. |
| ### What Makes a Useful Workflow? | ||
| A good workflow is one that includes a command with many flags or arguments or one that is hard to remember. | ||
|
|
||
| Additionally, a workflow should include: |
There was a problem hiding this comment.
Is "should" the right strength or is it more accurately "must" (for the purposes of us accepting a PR into the public workflows repository)?
There was a problem hiding this comment.
sure--originally chose "should" so that it wouldn't come off too harsh, but i think that's fine
|
PTAL |
| name: Uninstall a Homebrew package and all of its dependencies | ||
| # The corresponding command for the workflow. Any arguments should be surrounded with two curly braces. E.g `command {{arg}}`. | ||
| command: |- | ||
| brew tap beeftornado/rmtree |
There was a problem hiding this comment.
nit: two space indent for this line and the one below
3 participants
specs/directory)