Applying recommended PR changes

Author: dcinzona

cumulusci/tasks/release_notes/task.py

@@ -141,7 +141,7 @@ class ParentPullRequestNotes(BaseGithubTask):
 
     If you have a pull request on branch feature/myFeature that you would like to rebuild notes
     for use the branch_name and force options:
-    - cci task run github_parent_pr_notes --branch-name feature/myFeature --force True
+        cci task run github_parent_pr_notes --branch-name feature/myFeature --force True
     """
     UNAGGREGATED_PR_HEADER = "\r\n\r\n# Unaggregated Pull Requests"
 

docs/conf.py

@@ -250,11 +250,16 @@
         "index",
         "cumulusci.tex",
         "CumulusCI Documentation",
-        r'Cumulus Suite Development Team\\\texttt{sfdo-mrbelvedere@salesforce.com}',
+        r"""
+        \parbox{\textwidth}{\raggedleft
+        {\fontsize{15}{12} Kamalnath Devarakonda}\\
+        {\fontsize{14}{12}\selectfont Sr. Director, Software Engineering}\\
+        {\fontsize{13}{12}\selectfont kdevarakonda@salesforce.com}
+        }
+        """,
         "manual",
     )
 ]
-
 # The name of an image file (relative to this directory) to place at
 # the top of the title page.
 # latex_logo = None

docs/connected-orgs.md

@@ -65,25 +65,21 @@ CumulusCI with the name `devhub`.
 
 ```console
 $ cci org list
+                         Scratch Orgs
 
-                                  Scratch Orgs 
-│ Name                     │ Default │ Days │ Expired │ Config       │ Domain │
-├──────────────────────────|─────────|──────|─────────|──────────────|────────-|
-│ dev                      │         │ 7    │ X       | dev          │        │
-├──────────────────────────|─────────|──────|─────────|──────────────|────────-|
-│ feature                  │         │ 1    │ X       | feature      │        │
-├──────────────────────────|─────────|──────|─────────|──────────────|────────-|
-│ prerelease               │         │ 1    │ X       | prerelease   │        │
-├──────────────────────────|─────────|──────|─────────|──────────────|────────-|
-│ qa                       │         │ 7    │ X       | qa           │        │
-├──────────────────────────|─────────|──────|─────────|──────────────|────────-|
-│ release                  │         │ 1    │ X       | release      │        │
-
-
-                         Connected Orgs
-│ Name   │ Default │ Username                     │ Expires    │
-├────────|─────────|──────────────────────────────|────────────-|
-│ devhub │         │ j.holt@mydomain.devhub       │ Persistent │
+  Default   Name         Days   Expired   Config       Domain
+ ─────────────────────────────────────────────────────────────
+            beta         1                beta
+            dev          7      ✔         dev
+            feature      1                feature
+            qa           7      ✔         qa
+            release      1                release
+
+                                     Connected Orgs
+
+  Default   Name                 Username                                    Expires
+ ───────────────────────────────────────────────────────────────────────────────────────
+            devhub       j.holt@mydomain.devhub                    Persistent
 
 ```
 

docs/continuous-integration.md

@@ -50,7 +50,7 @@ variables to provide access to orgs and services [in a headless context](headles
 
 CumulusCI makes it easy to harness the power of second-generation
 managed packages to implement an advanced, comprehensive testing process
-for both first and second-generation managed package products. This is
+for both first-generation and second-generation managed package products. This is
 described in [](2gp-testing).
 
 ## Further Reading

docs/data.md

@@ -44,7 +44,7 @@ about Snowfakery is in the section [Generate Fake Data](#generate-fake-data).
 In the simplest case, you can extract all data from an org
 using the task `capture_sample_data` like this:
 
-```s
+```console
 $ cci task run capture_sample_data --org orgname
 ```
 
@@ -54,7 +54,7 @@ org named `orgname` into the dataset named `default`.
 You can then load it into any target org (e.g.
 `org2`) like this:
 
-```s
+```console
 $ cci task run load_sample_data --org org2
 ```
 
@@ -88,11 +88,11 @@ If you want different datasets for different scratch org types
 loaded by those types by making datasets specific to each one.
 This data will load instead of the default dataset.
 
-```s
+```console
 $ cci task run capture_sample_data --dataset dev --org org1
 ```
 
-```s
+```console
 $ cci task run capture_sample_data --dataset qa --org org2
 ```
 
@@ -818,7 +818,7 @@ Extract the data for a dataset from an org and persist it to disk.
 
 Example: 
 ```console
-    cci task run extract_dataset -o mapping datasets/qa/mapping.yml -o sql_path datasets/qa/data.sql --org qa
+cci task run extract_dataset -o mapping datasets/qa/mapping.yml -o sql_path datasets/qa/data.sql --org qa
 ```
 
 (data-load-dataset)=
@@ -845,7 +845,7 @@ persist new Salesforce Ids to storage.
 Example: 
 
 ```console
-    cci task run load_dataset -o mapping datasets/qa/mapping.yml -o sql_path datasets/qa/data.sql --org qa
+cci task run load_dataset -o mapping datasets/qa/mapping.yml -o sql_path datasets/qa/data.sql --org qa
 ```
 
 ### `generate_dataset_mapping`
@@ -915,7 +915,7 @@ after their target records become available.
 Example: 
 
 ```console
-    cci task run generate_dataset_mapping --org qa -o namespace_prefix my_ns
+cci task run generate_dataset_mapping --org qa -o namespace_prefix my_ns
 ```
 
 ### `load_custom_settings`