Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
216 changes: 216 additions & 0 deletions CONTRIBUTING.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,216 @@
# Contributing to Nextcloud Documentation

Thank you for taking the time to contribute! This guide explains everything you
need to know to submit improvements to the Nextcloud user, administration, and
developer manuals.

---

## Table of Contents

1. [Where to ask questions](#where-to-ask-questions)
2. [Setting up a local build environment](#setting-up-a-local-build-environment)
3. [Making changes](#making-changes)
4. [Opening a pull request](#opening-a-pull-request)
5. [Commit message format](#commit-message-format)
6. [DCO sign-off](#dco-sign-off)
7. [Review process](#review-process)
8. [Style guide](#style-guide)
9. [Issue templates](#issue-templates)

---

## Where to ask questions

- **GitHub Discussions / Issues** – open an issue in this repository for
documentation-specific questions and suggestions.
- **Nextcloud Community Forum** – <https://help.nextcloud.com>
- **Talk room** – join the public documentation chat room at
<https://cloud.nextcloud.com/call/uuz59j6z> for real-time chat with
contributors.

---

## Setting up a local build environment

Documentation is built with [Sphinx](https://www.sphinx-doc.org/). A local
build lets you preview changes accurately before opening a PR.

### Using a Python virtual environment (recommended)

```bash
# 1. Clone the repository
git clone https://github.com/nextcloud/documentation.git
cd documentation

# 2. Create and activate a virtual environment
python3 -m venv venv
source venv/bin/activate # on Windows: venv\Scripts\activate

# 3. Install dependencies
pip install -r requirements.txt

# 4. Build HTML (all manuals)
make html
```

The built HTML files appear under each manual's `_build/html/` directory,
e.g. `user_manual/_build/html/index.html`.

### Using the VSCode DevContainer

The repository ships a ready-to-use
[Dev Container](https://code.visualstudio.com/docs/devcontainers/containers).
Open the repository in VSCode, accept the prompt to reopen in the container,
then run `make html` in the integrated terminal.

### Live-reload while editing

```bash
pip install sphinx-autobuild
cd user_manual # or admin_manual / developer_manual
make SPHINXBUILD=sphinx-autobuild html
# Open http://127.0.0.1:8000 in your browser
```

See [README.rst](README.rst) for additional build targets (PDF, translated
versions, etc.).

---

## Making changes

- Work in the correct branch:
- `master` → latest (unreleased) version
- `stable*` branches → the corresponding released version (e.g. `stable29`)
- If your change applies to multiple versions, open one PR per branch (or
note in the PR description that backporting is needed).
- Keep the scope of a PR focused. Separate unrelated fixes into separate PRs.
- Wrap prose at **120 characters** per line where practical.
- Follow the [Style Guide](style_guide.rst) for formatting conventions.
- Do **not** rename or move existing pages without adding a redirect, because
many external sites link to our documentation.

---

## Opening a pull request

1. Fork the repository on GitHub.
2. Create a new branch from the target branch:
```bash
git checkout -b fix/short-description
```
3. Make your changes and commit them (see [DCO sign-off](#dco-sign-off) below).
4. Push the branch to your fork:
```bash
git push origin fix/short-description
```
5. Open a pull request against the appropriate branch of
`nextcloud/documentation`.
6. Fill in the pull request template — include a screenshot of changed pages
where relevant.

---

## Commit message format

This project follows the [Conventional Commits](https://www.conventionalcommits.org/)
specification. Every commit message must have the form:

```
type(optional scope): short description

Optional longer body.

Signed-off-by: Your Name <your.email@example.com>
```

**Accepted types:**

| Type | When to use |
| ---------- | ------------------------------------------------------------ |
| `docs` | Content changes — new or updated documentation text |
| `fix` | Correcting errors (broken links, wrong commands, typos, …) |
| `feat` | Adding a new page or section |
| `refactor` | Restructuring without changing the meaning of the content |
| `chore` | Build, tooling, or dependency updates |
| `ci` | Changes to GitHub Actions workflows |

**Examples:**

```
docs: add two-factor authentication setup guide
fix: correct occ command in backup section
feat: add new Files app keyboard shortcuts page
chore: bump sphinx to 7.3
ci: add link-checker workflow
```

The **scope** is optional and should name the affected manual or area
(e.g. `user`, `admin`, `developer`, `ci`):

```
fix(admin): correct database tuning example for PostgreSQL
```

---

## DCO sign-off

All commits must be signed off to certify adherence to the
[Developer Certificate of Origin](https://developercertificate.org/).

Add the following line to every commit message (replace with your real name and
email):

```
Signed-off-by: Your Name <your.email@example.com>
```

The easiest way is to pass `-s` to `git commit`:

```bash
git commit -s -m "docs: fix typo in backup section"
```

Make sure the email address matches the one in your GitHub profile. If you have
GitHub's privacy setting enabled, it will be
`github-username@users.noreply.github.com`.

---

## Review process

1. A maintainer will review your PR, usually within a few days.
2. Automated checks (spelling, link validation) run on every PR. Fix any
reported issues before requesting a re-review.
3. The reviewer may request changes. Address feedback and push new commits to
the same branch — do **not** force-push after a review has started.
Comment thread
miaulalala marked this conversation as resolved.
4. Once approved, a maintainer will merge the PR.

---

## Style guide

Please read [style_guide.rst](style_guide.rst) before writing new content. It
covers:

- File and image naming conventions
- Heading hierarchy
- GUI label formatting and inline code
- Admonitions (`.. note::`, `.. warning::`, `.. tip::`, `.. danger::`)
- Voice and tone (active voice, present tense, second person)
- Code block language tags
- Version directives (`.. versionadded::`, `.. versionchanged::`,
`.. deprecated::`)
- Internal cross-references (`:doc:`, `:ref:`, `:guilabel:`, `:kbd:`)
- Shared content with `.. include::`
- Table syntax

---

## Issue templates

When reporting a problem or suggesting an improvement, please use the GitHub
issue templates provided in this repository. They help maintainers triage
requests quickly.
5 changes: 4 additions & 1 deletion README.rst
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,10 @@ This repository hosts three manuals:

Please work in the appropriate branch: ``stable``-branches are for the respective release (e.g. 14.0 or 15.0), ``master`` is the latest version.

Please wrap lines at 80 characters.
Wrap prose lines at **120 characters** where practical. Long URLs, code
examples, and table cells may exceed this limit. See the
`Style Guide <https://github.com/nextcloud/documentation/blob/master/style_guide.rst>`_
for full guidance.

.. note:: ``configuration_server/config_sample_php_parameters.rst`` is auto-generated from the core
config.sample.php file; changes to this file must be made in core `<https://github.com/nextcloud/server/tree/master/config>`_
Expand Down
12 changes: 6 additions & 6 deletions admin_manual/occ_files.rst
Original file line number Diff line number Diff line change
Expand Up @@ -927,15 +927,15 @@ Trashbin
trashbin:size configure or show the target trashbin size

trashbin\:cleanup
^^^^^^^^^^^^^^^^^^
"""""""""""""""""

Remove all deleted files for all users, or for specific users::

sudo -E -u www-data php occ trashbin:cleanup
sudo -E -u www-data php occ trashbin:cleanup layla fred

trashbin\:expire
^^^^^^^^^^^^^^^^^
"""""""""""""""""

Apply the configured trashbin retention policy and remove files that have
exceeded the maximum retention age. Runs for all users by default, or for
Expand All @@ -945,7 +945,7 @@ specific users::
sudo -E -u www-data php occ trashbin:expire layla

trashbin\:restore
^^^^^^^^^^^^^^^^^^
""""""""""""""""""

Restore deleted files according to the given filters. Restore all deleted files
for all users::
Expand Down Expand Up @@ -977,7 +977,7 @@ Use ``--dry-run`` to simulate the restore without making any changes::
some files may be skipped.

trashbin\:size
^^^^^^^^^^^^^^
""""""""""""""

Show or configure the target trashbin size. When called without arguments,
shows the current configured size::
Expand Down Expand Up @@ -1009,7 +1009,7 @@ Versions
versions:expire expire file versions according to the configured retention policy

versions\:cleanup
^^^^^^^^^^^^^^^^^^
""""""""""""""""""

Delete all file versions for all users, or for specific users. Use ``--path``
to limit deletion to a specific path::
Expand All @@ -1019,7 +1019,7 @@ to limit deletion to a specific path::
sudo -E -u www-data php occ versions:cleanup layla --path="/files/Documents"

versions\:expire
^^^^^^^^^^^^^^^^^
"""""""""""""""""

Apply the configured version retention policy and remove versions that have
exceeded the maximum retention age. Runs for all users by default, or for
Expand Down
Loading
Loading