|
| 1 | +# Contributing |
| 2 | + |
| 3 | +This documentation is developed using the [Material for MkDocs](https://squidfunk.github.io/mkdocs-material/) framework, and the source code for the docs is publicly available on [GitHub](https://github.com/eth-cscs/cscs-docs). |
| 4 | +This means that everybody, CSCS staff and the CSCS user community can contribute to the documentation. |
| 5 | + |
| 6 | +## Getting Started |
| 7 | + |
| 8 | +We use the GitHub fork and pull request model for development: |
| 9 | + |
| 10 | +* First create a fork of the [main GitHub repository](https://github.com/eth-cscs/cscs-docs). |
| 11 | +* Make all proposed changes in branches on your fork - don't make branches on the main repository (we reserve the right to block creating branches on the main repository). |
| 12 | + |
| 13 | +Clone your fork repository on your PC/laptop: |
| 14 | +```bash |
| 15 | +# clone your fork of the repository |
| 16 | +> git clone [email protected]: ${githubusername}/cscs-docs.git |
| 17 | +> cd cscs-docs |
| 18 | +> git switch -c 'fix/ssh-alias' |
| 19 | +# ... make your edits ... |
| 20 | +# add and commit your changes |
| 21 | +> git add <files> |
| 22 | +> git commit -m 'update the ssh docs with alisases for all user lab vclusters' |
| 23 | +> git push origin 'fix/ssh-alias' |
| 24 | +``` |
| 25 | +Then navigate to GitHub, and create a pull request. |
| 26 | + |
| 27 | +The `serve` script in the root path of the repository can be used to view the docs locally:` |
| 28 | +``` |
| 29 | +> ./serve |
| 30 | +... |
| 31 | +INFO - [08:33:34] Serving on http://127.0.0.1:8000/ |
| 32 | +``` |
| 33 | +This generates the documentation locally, which can be viewed using a local link, which is `http://127.0.0.1:8000/` by default. |
| 34 | +The documentation will be rebuilt and the webpage reloaded when changed files are saved. |
| 35 | + |
| 36 | +!!! note |
| 37 | + To run the serve script, you need to first install [uv](https://docs.astral.sh/uv/getting-started/installation/). |
| 38 | + |
| 39 | +To build the docs in a `site` sub-directory: |
| 40 | +```bash |
| 41 | +./serve build |
| 42 | +``` |
| 43 | +## Review Process |
| 44 | + |
| 45 | +Documentation is owned by everybody - so don't be afraid to jump in and make changes or fixes where you see that there is something missing or outdated. |
| 46 | + |
| 47 | +If you plan to make large changes or contributions, please discuss them with the documentation owners beforehand, to make sure that the documentation will fit into the larger documentation structure. |
| 48 | + |
| 49 | +If the documentation that you write or update might affect multiple stakeholders, ping them for a review. |
| 50 | +If you don't get a timely reply, ask the documentation owners for a review or for permission to merge. |
| 51 | + |
| 52 | +!!! note |
| 53 | + To minimise the overhead of the contributing to the documentation and speed up "time-to-published-docs" we do not have a formal review process. |
| 54 | + We will start simple, and add more formality as needed. |
| 55 | + |
| 56 | +## Guidelines |
| 57 | + |
| 58 | +### Frequently Asked Questions |
| 59 | + |
| 60 | +The documentation does not have a FAQ section, because questions are best answered by the documentation, not in a separate section. |
| 61 | +Integrating information into the main documentation requires some care to identify where the information needs to go, and edit the documentation around it. |
| 62 | +Adding the information to a FAQ is easier, but the result is information about a topic distributed betwen the docs and FAQ questions, which ultimately makes the documentation harder to search. |
| 63 | + |
| 64 | +FAQ content, such as lists of most frequently encountered error messages, is still very useful in many contexts. |
| 65 | +If you want to add such content, create a section at the bottom of a topic page, for example this section on the [SSH documentation page][ref-ssh-faq]. |
| 66 | + |
| 67 | +### Images |
| 68 | + |
| 69 | +Images are stored in the `docs/images` directory. |
| 70 | + |
| 71 | +* there are sub-directories in the `docs/images` path - create a new sub-directory for your images if appropriate |
| 72 | +* choose image and path names that make sense - `screenshot.png` is not a great file name. Neither is `PX-202502025-imgx.png`. |
| 73 | + |
| 74 | +!!! tip |
| 75 | + When providing a screenshot, do you need to show the whole screen, or just part of one window? |
| 76 | + |
| 77 | + Cropping the image will decrease file size, and might also draw the readers attention to the most relevant information. |
| 78 | + |
| 79 | +!!! tip |
| 80 | + Do you need a screenshot, or can a text description also work? |
| 81 | + |
| 82 | +## Small Contributions |
| 83 | + |
| 84 | +Small changes that only modify the contents of a single file, for example to fix some typos or add some clarifying detail to an example, it is possible to quickly create a pull request directly in the browser. |
| 85 | + |
| 86 | +At the top of each page there is an "edit" icon :material-pencil:, which will open the markdown source for the page in the GitHub text editor. |
| 87 | + |
| 88 | +Once your changes are ready, click on the "Commit changes..." button in the top right hand corner of the editor, and add at least a description commit message. |
| 89 | + |
| 90 | +!!! note |
| 91 | + You will need to keep the default option **Create a new branch for this commit and start a pull request**. |
| 92 | + |
| 93 | + * if the change is small and you are CSCS staff, you can merge the PR immediately |
| 94 | + * all other changes can be |
0 commit comments