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
Copy file name to clipboardExpand all lines: README.md
+91-55
Original file line number
Diff line number
Diff line change
@@ -1,4 +1,4 @@
1
-
# Qiskit docs
1
+
# Qiskit documentation
2
2
3
3
The documentation content home for https://docs.quantum.ibm.com (excluding API reference).
4
4
@@ -14,7 +14,7 @@ Read on for more information about how to support this project:
14
14
15
15
This is the quickest, easiest, and most helpful way to contribute to this project and improve the quality of Qiskit® and IBM Quantum™ documentation. There are a few different ways to report issues, depending on where it was found:
16
16
17
-
- For problems you've found in the [Qiskit API Reference](https://docs.quantum.ibm.com/api/qiskit) section, open an issue in the Qiskit repo [here](https://github.com/Qiskit/qiskit/issues/new/choose).
17
+
- For problems you've found in the [Qiskit SDK API Reference](https://docs.quantum.ibm.com/api/qiskit) section, open an issue in the Qiskit repo [here](https://github.com/Qiskit/qiskit/issues/new/choose).
18
18
- For problems you've found in the [Qiskit Runtime IBM Client](https://docs.quantum.ibm.com/api/qiskit-ibm-runtime) section, open an issue in the Qiskit IBM Runtime repo [here](https://github.com/Qiskit/qiskit-ibm-runtime/issues/new/choose).
19
19
- For problems you've found in any other section of [docs](https://docs.quantum.ibm.com), open a content bug issue [here](https://github.com/Qiskit/documentation/issues/new/choose).
20
20
@@ -41,7 +41,7 @@ You can look through the open issues we have in this repo and address them with
41
41
42
42
Before getting started on an issue, remember to do the following:
43
43
44
-
1. Read the [Code of Conduct](https://github.com/Qiskit/documentation/blob/main/CODE_OF_CONDUCT.md)
44
+
1. Read the [Code of Conduct](https://docs.quantum.ibm.com/open-source/code-of-conduct)
45
45
2. Check for open, unassigned issues with the "good first issue" label
46
46
3. Select an issue that is not already assigned to someone and leave a comment to request to be assigned
47
47
@@ -50,7 +50,7 @@ Once you have an issue to work on, see the "How to work with this repo" section
50
50
Before opening a PR, remember to do the following:
51
51
52
52
1. Check that you have addressed all the requirements from the original issue
53
-
2. Run the spell checker
53
+
2. Run the quality control checks with `npm run check`
54
54
3. Use the GitHub "fixes" notation to [link your PR to the issue](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue) you are addressing
55
55
56
56
# How to work with this repo
@@ -63,7 +63,7 @@ First, install the below software:
63
63
64
64
1.[Node.js](https://nodejs.org/en). If you expect to use JavaScript in other projects, consider using [NVM](https://github.com/nvm-sh/nvm). Otherwise, consider using [Homebrew](https://formulae.brew.sh/formula/node) or installing [Node.js directly](https://nodejs.org/en).
65
65
2.[Docker](https://www.docker.com). You must also ensure that it is running.
66
-
-You can use [Colima](https://github.com/abiosoft/colima) or [Rancher Desktop](https://rancherdesktop.io). When installing Rancher Desktop, choose Moby/Dockerd as the engine, rather than nerdctl. To ensure it's running, open up the app "Rancher Desktop".
66
+
-If you cannot use Docker from docker.com, consider using use [Colima](https://github.com/abiosoft/colima) or [Rancher Desktop](https://rancherdesktop.io). When installing Rancher Desktop, choose Moby/Dockerd as the engine, rather than nerdctl. To ensure it's running, open up the app "Rancher Desktop".
67
67
68
68
Then, install the dependencies with:
69
69
@@ -80,7 +80,7 @@ You can preview the docs locally by following these two steps:
80
80
81
81
The preview application does not include the top nav bar. Instead, navigate to the folder you want with the links in the home page. You can return to the home page at any time by clicking "IBM Quantum Documentation Preview" in the top-left of the header.
82
82
83
-
Warning: `./start` does not check if there is a new version of the docs application available. Run`docker pull qiskit/documentation` to update to the latest version of the app.
83
+
Warning: `./start` does not check if there is a new version of the docs application available. You can run`docker pull qiskit/documentation` to update to the latest version of the app.
84
84
85
85
### API docs authors: How to preview your changes
86
86
@@ -89,7 +89,33 @@ API docs authors can preview their changes to one of the APIs by using the `-a`
89
89
1. Run `npm run gen-api -- -p <pkg-name> -v <version> -a <path/to/docs/_build/html>`.
90
90
2. Execute `./start` and open up `http://localhost:3000`, as explained in the prior section.
91
91
92
-
## Execute notebooks
92
+
## Jupyter notebooks
93
+
94
+
### Add a new notebook
95
+
96
+
When adding a new notebook, you'll need to tell the testing tools how to handle it.
97
+
To do this, add the file path to `scripts/nb-tester/notebooks.toml`. There are
98
+
four categories:
99
+
100
+
-`notebooks_normal_test`: Notebooks to be run normally in CI. These notebooks
101
+
can't submit jobs as the queue times are too long and it will waste
102
+
resources. You _can_ interact with IBM Quantum to retrieve jobs and backend
103
+
information.
104
+
-`notebooks_that_submit_jobs`: Notebooks that submit jobs, but that are small
105
+
enough to run on a 5-qubit simulator. We will test these notebooks in CI by
106
+
patching `least_busy` to return a 5-qubit fake backend.
107
+
-`notebooks_no_mock`: For notebooks that can't be tested using the 5-qubit
108
+
simulator patch. We skip testing these in CI and instead run them twice per
109
+
month. Any notebooks with cells that take more than five minutes to run are
110
+
also deemed too big for CI. Try to avoid adding notebooks to this category if
111
+
possible.
112
+
-`notebooks_exclude`: Notebooks to be ignored.
113
+
114
+
If your notebook uses the latex circuit drawer (`qc.draw("latex")`), you must
115
+
also add it to the "Check for notebooks that require LaTeX" step in
116
+
`.github/workflows/notebook-test.yml`.
117
+
118
+
### Execute notebooks
93
119
94
120
Before submitting a new notebook or code changes to a notebook, you must run
95
121
the notebook using `tox -- --write <path-to-notebook>` and commit the results.
@@ -130,31 +156,7 @@ job page, click "Summary", then download "Executed notebooks". Otherwise, if
130
156
your notebook does submit jobs, you need to run it locally using the steps
131
157
mentioned earlier.
132
158
133
-
### Adding a new notebook
134
-
135
-
When adding a new notebook, you'll need to tell the testing tools how to handle it.
136
-
To do this, add the file path to `scripts/nb-tester/notebooks.toml`. There are
137
-
four categories:
138
-
139
-
-`notebooks_normal_test`: Notebooks to be run normally in CI. These notebooks
140
-
can't submit jobs as the queue times are too long and it will waste
141
-
resources. You _can_ interact with IBM Quantum to retrieve jobs and backend
142
-
information.
143
-
-`notebooks_that_submit_jobs`: Notebooks that submit jobs, but that are small
144
-
enough to run on a 5-qubit simulator. We will test these notebooks in CI by
145
-
patching `least_busy` to return a 5-qubit fake backend.
146
-
-`notebooks_no_mock`: For notebooks that can't be tested using the 5-qubit
147
-
simulator patch. We skip testing these in CI and instead run them twice per
148
-
month. Any notebooks with cells that take more than five minutes to run are
149
-
also deemed too big for CI. Try to avoid adding notebooks to this category if
150
-
possible.
151
-
-`notebooks_exclude`: Notebooks to be ignored.
152
-
153
-
If your notebook uses the latex circuit drawer (`qc.draw("latex")`), you must
154
-
also add it to the "Check for notebooks that require LaTeX" step in
155
-
`.github/workflows/notebook-test.yml`.
156
-
157
-
### Ignoring warnings
159
+
### Ignore warnings in your notebook
158
160
159
161
We don't want users to see warnings that can be avoided, so it's best to fix
160
162
the code to avoid them. However, if a warning is unavoidable, you can stop it
@@ -164,7 +166,7 @@ right-click the cell, choose "Add cell tag", type `ignore-warnings`, then press
164
166
Sidebar > Show Notebook Tools, then under "Common Tools" add a tag with text
165
167
`ignore-warnings`.
166
168
167
-
### Extra code checks
169
+
### Add extra code checks to your notebook
168
170
169
171
Our CI checks notebooks run from start to finish without errors or warnings.
170
172
You can add extra checks in notebooks to catch other unexpected behavior.
@@ -185,7 +187,7 @@ block is only for testing. Make sure you add the tag `remove-cell`.
185
187
If something ever causes this value to
186
188
change, CI will alert us.
187
189
188
-
## Lint notebooks
190
+
###Lint notebooks
189
191
190
192
We use [`squeaky`](https://github.com/frankharkins/squeaky) to lint our
191
193
notebooks. First install `tox` using [pipx](https://pipx.pypa.io/stable/).
Every file needs to have a `title` and `description`. The `lint` job in CI will fail with instructions for any bad file.
271
+
Every file needs to have a `title` and `description`, as explained in [Page Metadata](#page-metadata) The `lint` job in CI will fail with instructions for any bad file.
270
272
271
273
You can also check for valid metadata locally:
272
274
273
275
```bash
274
276
# Only check file metadata
275
277
npm run check:metadata
276
278
277
-
# By default, only the non-API docs are checked. You can add any of the
278
-
# below arguments to also check API docs and/or translations.
279
-
npm run check:metadata -- --translations --apis
279
+
# By default, only the non-API docs are checked. You can add the
280
+
# below argument to also check API docs.
281
+
npm run check:metadata -- --apis
280
282
281
283
# Or, run all the checks. Although this only checks non-API docs.
282
284
npm run check
@@ -327,7 +329,7 @@ To check that all the non-API docs render:
327
329
1. Start up the local preview with `./start` by following the instructions at [Preview the docs locally](#preview-the-docs-locally)
328
330
2. In a new tab, `npm run check:pages-render -- --non-api`
329
331
330
-
You can also check that API docs and translations render by using any of these arguments: `npm run check:pages-render -- --non-api --qiskit-release-notes --current-apis --dev-apis --historical-apis --translations`. Warning that this is exponentially slower.
332
+
You can also check that API docs render by using any of these arguments: `npm run check:pages-render -- --non-api --qiskit-release-notes --current-apis --dev-apis --historical-apis`. Warning that this is exponentially slower.
331
333
332
334
CI will check on every PR that any changed files render correctly. We also run a weekly cron job to check that every page renders correctly.
333
335
@@ -418,12 +420,8 @@ The add the following to your `.gitconfig` (usually found at `~/.gitconfig`).
418
420
textconv = sh -c 'sphobjinv convert plain "$0" -'
419
421
```
420
422
421
-
# How to deploy docs
422
-
423
423
## Deploy guides & API docs
424
424
425
-
This content lives on https://docs.quantum.ibm.com.
426
-
427
425
See the section "Syncing content with open source repo" in the internal docs repo's README.
428
426
429
427
# How to write the documentation
@@ -442,43 +440,81 @@ Next, choose the file name. The file name will determine the URL. For example, `
442
440
443
441
If your file will have non-trivial code in it, please create a Jupyter notebook ending in `.ipynb`, rather than an MDX file. We prefer Jupyter notebooks when there is code because we have tests to make sure that the code still executes properly, whereas MDX is not tested.
444
442
445
-
Once the file is created, you need to add metadata. Run `npm run check:metadata` for instructions on how to do this. (Refer to [Check file metadata](#check-file-metadata))
443
+
Finally, add the file to the folder's `_toc.json`, such as `guides/_toc.json`. The `title` is what will show up in the left side bar. Note that the `url` leaves off the file extension.
444
+
445
+
## Page metadata
446
+
447
+
Every page must set a `title` and `description`:
448
+
449
+
- The title is used for browser tabs and the top line of search results. It should usually match the title used in the `_toc.json` file.
450
+
- The description should describe the page in at least 50 but no more than 160 characters, ideally using some keywords. The description is what shows up as the text in search results. See https://github.com/Qiskit/documentation/issues/131 for some tips.
451
+
452
+
In MDX files, set the metadata at the top of the file like this:
453
+
454
+
```
455
+
---
456
+
title: Representing quantum computers
457
+
description: Learn about coupling maps, basis gates, and backend errors for transpiling
458
+
---
459
+
```
460
+
461
+
In Jupyter notebooks, set `title` and `description` in the `metadata` section for the file. In VSCode, you can set up the metadata with these instructions:
462
+
463
+
1. Open up the file with the "Open With..." option (one way to do this is to right-click the file name to find the "Open With..." option) and then "Text Editor".
464
+
2. Scroll down to the bottom of the file for the top-level key "metadata". Ensure that this is the metadata for the entire file and not for a single code block. You should see in the "metadata" section other entries like "language_info" and "nbconvert_exporter".
465
+
3. Add new keys in the "metadata" section for "title" and "description".
466
+
467
+
```json
468
+
"metadata": {
469
+
"description": "Get started using Qiskit with IBM Quantum hardware in this Hello World example",
470
+
"title": "Hello world",
471
+
"celltoolbar": "Raw Cell Format",
472
+
"kernelspec": { ...
473
+
}
474
+
```
475
+
476
+
## Links
477
+
478
+
Internal URLs referring to other docs pages should start with `/` and not include the file extension. For example:
479
+
480
+
- `[Qiskit SDK](/api/qiskit)`
481
+
- `[Bit ordering in the Qiskit SDK](/guides/bit-ordering)`
446
482
447
-
Finally, add the file to the folder's `_toc.json`, such as `start/_toc.json`. The `title` is what will show up in the left side bar. Note that the `url` leaves off the file extension.
483
+
External URLs should use the entire URL, such as `[GitHub](https://github.com)`.
448
484
449
485
## Images
450
486
451
-
Images are stored in the `public/images` folder. You should use subfolders to organize the files. For example, images for `start/my-file.mdx` should be stored like `public/images/start/my-file/img1.png`.
487
+
Images are stored in the `public/images` folder. You should use subfolders to organize the files. For example, images for `guides/my-file.mdx` should be stored like `public/images/guides/my-file/img1.png`.

469
505
```
470
506
471
507
You can include a version of the image to be with the dark theme. You only need to create an image with the same name ending in `@dark`. So for example, if you have a `sampler.png` image, the dark version would be `[email protected]`. This is important for images that have a white background.
472
508
473
509
## Videos
474
510
475
-
Videos are stored in the `public/videos` folder. You should use subfolders to organize the files. For example, images for `start/my-file.mdx` should be stored like `public/videos/start/my-file/video1.mp4`.
511
+
Videos are stored in the `public/videos` folder. You should use subfolders to organize the files. For example, images for `guides/my-file.mdx` should be stored like `public/videos/guides/my-file/video1.mp4`.
476
512
477
513
To add a video:
478
514
479
515
```markdown
480
516
<video title="Write a description of the video here as 'alt text' for accessibility." className="max-w-auto h-auto" controls>
0 commit comments