Updated Bot commands (markdown)

Bot-commands.md

@@ -1,6 +1,6 @@
 Page Maintainers: @seemethere, @janeyx99, @zengk95
 
-Updated on: Thu, May 26, 2022
+Updated on: Wed, Jun 1, 2022
 
 Please report any buggy instances to @pytorch/pytorch-dev-infra asynchronously or join our [Office Hours](https://github.com/pytorch/pytorch/wiki/Dev-Infra-Office-Hours) to give in-person feedback or get in-person help!
 
@@ -13,30 +13,42 @@ By default, the Lint and pull workflows should run on every push to your pull re
 We are in the process of prototyping our GitHub First initiative, which will allow certain pull requests based on the upstream repo (not a fork) to be merged through GitHub first, then imported internally into Meta. The requirements for such PRs are described in [our merge rules](https://github.com/pytorch/pytorch/blob/master/.github/merge_rules.json) where files fitting the specified patterns approved by the specified maintainers are allowed to merge directly with the following comment:
 
 ```
-@pytorchbot merge
+usage: @pytorchbot merge [-g] [-a] [-f]
+
+optional arguments:
+  -g, --green      Merge when required status checks pass. Currently, we only
+                   require lint and builds to pass.
+  -a, --all-green  Merge when all status checks pass
+  -f, --force      Merge without checking anything. ONLY USE THIS FOR CRITICAL
+                   FAILURES.
 ```
 
-We also have the following flags:
-
--f, -force: force merge the PR, bypassing all the required status checks. ONLY USE THIS AT YOUR DISCRETION FOR CRITICAL FAILURES. 
-
--g, -green, -onGreen: merge the PR only when all the required status checks have passed (BETA). DISCLAIMER: currently, our required status checks only include Lint and builds, not tests.
-
 Examples:
 ```
-@pytorchbot merge -f
+@pytorchbot merge
 @pytorchbot merge -g
 ```
 ## Reverting 
 Similar to merging, we have a command to revert a PR, though it requires you be a Meta employee at the moment. You can always submit a PR to back out a change and merge with the commands above. Revert requires you to provide both a message and classification for record keeping purposes.
 
+```
+usage: @pytorchbot revert -m MESSAGE
+                          [-c {nosignal,ignoredsignal,landrace,weird,ghfirst}]
+
+optional arguments:
+  -m MESSAGE, --message MESSAGE
+                        The reason you are reverting, will be put in the
+                        commit message.
+  -c {nosignal,ignoredsignal,landrace,weird,ghfirst}, --classification {nosignal,ignoredsignal,landrace,weird,ghfirst}
+                        A machine-friendly classification of the revert
+                        reason.
+```
+
+Examples:
+
 ```
 @pytorchbot revert -m="This is breaking tests on trunk. hud.pytorch.org/" -c=nosignal
 ```
--m, -message: The reason why you are reverting this PR. Must be at least 3 words.
-
--c, -classification: What type of revert this is. Potential classifications are: nosignal, ignoredsignal, landrace, weird, ghfirst. 
-
 ## Labeling
 You can also add multiple labels using comments with pytorchbot.
 
@@ -48,13 +60,12 @@ You can also add multiple labels using comments with pytorchbot.
 Rebasing is useful you're reviewing an older PR and want to get new signal: you might want to rebase to get the most up to date tests and re run the CI. Rebasing defaults to the default branch of pytorch/pytorch, which currently is master. You, along with any member of the pytorch organization, can rebase your PR.
 
 ```
-@pytorchbot rebase
+usage: @pytorchbot rebase [-s]
+
+optional arguments:
+  -s, --stable  Rebase to viable/strict
 ```
 
-We also have the following flags:
-
--s, -stable, -viableStrict: rebase the PR to the viable/strict branch instead of master. The viable/strict branch contains all commits on pytorch/pytorch that are green and stable (i.e. it passes all of the CI checks). (disclaimer: if you are based off a commit that is newer that viable/strict, like master, then rebasing to viable/strict will not do anything)
-
 Examples:
 ```
 @pytorchbot rebase -s