mirror of
https://github.com/deepset-ai/haystack.git
synced 2026-02-06 23:12:43 +00:00
214 lines
7.4 KiB
Markdown
214 lines
7.4 KiB
Markdown
|
|
# Contributing to Haystack Docs
|
|||
|
|
|
|||
|
|
This guide explains how to contribute to the Haystack documentation in this repository. It complements the main Haystack contribution guide in `deepset-ai/haystack` and focuses on authoring, reviewing, and maintaining docs.
|
|||
|
|
|
|||
|
|
If you plan to contribute code, tests, or integration changes, see the [main contribution guide](https://github.com/deepset-ai/haystack/blob/main/CONTRIBUTING.md) in the Haystack repository instead. For docs-related PRs that touch both code and docs, please follow both guides.
|
|||
|
|
|
|||
|
|
## What you’ll need
|
|||
|
|
|
|||
|
|
- Node.js 18+ and npm (recommended)
|
|||
|
|
- Optional: [Vale](https://github.com/errata-ai/vale) for prose/style linting. See [Prose/style linting with Vale](#prose-style-linting-with-vale) section for more details.
|
|||
|
|
|
|||
|
|
Install Node.js and npm (macOS examples):
|
|||
|
|
|
|||
|
|
- Recommended (using nvm): see [nvm docs](https://github.com/nvm-sh/nvm#installing-and-updating)
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
brew install nvm
|
|||
|
|
mkdir -p ~/.nvm
|
|||
|
|
echo 'export NVM_DIR="$HOME/.nvm"' >> ~/.zshrc
|
|||
|
|
echo '[ -s "/opt/homebrew/opt/nvm/nvm.sh" ] && . "/opt/homebrew/opt/nvm/nvm.sh"' >> ~/.zshrc
|
|||
|
|
exec $SHELL -l
|
|||
|
|
nvm install 18
|
|||
|
|
nvm use 18
|
|||
|
|
node -v && npm -v
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
- Alternative (Homebrew or official installer):
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
brew install node
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Or download an installer from the Node.js website: [nodejs.org/download](https://nodejs.org/en/download)
|
|||
|
|
|
|||
|
|
Start a local dev server:
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
npm ci
|
|||
|
|
npm run start
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Build and preview the production site locally:
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
npm run build
|
|||
|
|
npm run serve
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## Repository structure (docs highlights)
|
|||
|
|
|
|||
|
|
- `docs/`: Narrative documentation (guides, concepts, how-tos)
|
|||
|
|
- `docs/_templates/`: Authoring templates you can copy when creating new pages
|
|||
|
|
- `reference/`: API reference docs (organized by a separate docs plugin)
|
|||
|
|
- `sidebars.js`: Sidebar for `docs/`
|
|||
|
|
- `reference-sidebars.js`: Sidebar for `reference/`
|
|||
|
|
- `versions.json`, `versioned_docs/`, `versioned_sidebars/`: Docusaurus versioning
|
|||
|
|
- `.vale/` and `.vale.ini`: Prose linting configuration (Vale)
|
|||
|
|
|
|||
|
|
## Writing and style
|
|||
|
|
|
|||
|
|
Adhere to our internal Writing Guidelines (American English; Google developer style; concise, active voice; accessible; inclusive). Key expectations:
|
|||
|
|
|
|||
|
|
- Use second person (you) and present tense.
|
|||
|
|
- Prefer simple words; avoid intensifiers and slang.
|
|||
|
|
- Capitalization:
|
|||
|
|
- Use title case for page titles and headings.
|
|||
|
|
- Capitalize Haystack component class names exactly as in code (for example, `OpenAIAnswerGenerator`).
|
|||
|
|
- Do not capitalize generic terms like pipeline or component when used generically.
|
|||
|
|
- Code and API names:
|
|||
|
|
- Use backticks for parameters, classes, and methods in running text; include parentheses for methods (for example, `PreProcessor.process()`).
|
|||
|
|
- Ensure code samples are runnable and tested.
|
|||
|
|
- Lists and headings:
|
|||
|
|
- Make list items parallel; prefer short sentences.
|
|||
|
|
- Avoid overly deep heading hierarchies (limit to three levels where possible).
|
|||
|
|
- GUI text:
|
|||
|
|
- Use Click in bold for buttons and tabs (for example, Click **Save**). Use Select in italics for lists/options (for example, Select *Workspace*).
|
|||
|
|
- Links:
|
|||
|
|
- Use descriptive link text, not bare URLs. Add related links at the end when appropriate.
|
|||
|
|
- Images:
|
|||
|
|
- Use alt text; place images after the instruction they illustrate; keep file sizes small.
|
|||
|
|
|
|||
|
|
## Authoring new or updated pages
|
|||
|
|
|
|||
|
|
1. Decide where the content belongs in the navigation structure.
|
|||
|
|
2. Create or update the file in the appropriate folder.
|
|||
|
|
3. Add required frontmatter:
|
|||
|
|
|
|||
|
|
```md
|
|||
|
|
---
|
|||
|
|
title: "Page Title"
|
|||
|
|
id: "page-title"
|
|||
|
|
description: "1–2 sentences, used for SEO and previews"
|
|||
|
|
slug: "/target-url"
|
|||
|
|
---
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
4. Update navigation:
|
|||
|
|
- For `docs/`, edit `sidebars.js` to add the new page in the right category.
|
|||
|
|
- For `reference/`, update `reference-sidebars.js` if needed (some sections may be autogenerated).
|
|||
|
|
5. Use templates when applicable:
|
|||
|
|
- Copy from `docs/_templates/` and move the copy to the final location under `docs/`.
|
|||
|
|
|
|||
|
|
### Linking and anchors
|
|||
|
|
|
|||
|
|
- Prefer relative links to other docs files; avoid absolute URLs where a relative link is possible.
|
|||
|
|
- Use explicit anchors for headings if you need stable cross-links.
|
|||
|
|
|
|||
|
|
### Admonitions (callouts)
|
|||
|
|
|
|||
|
|
Use Docusaurus admonitions sparingly and only for supporting information:
|
|||
|
|
|
|||
|
|
```mdx
|
|||
|
|
:::tip
|
|||
|
|
Short tip that helps the reader succeed.
|
|||
|
|
:::
|
|||
|
|
|
|||
|
|
:::info
|
|||
|
|
Useful but non-blocking background.
|
|||
|
|
:::
|
|||
|
|
|
|||
|
|
:::warning
|
|||
|
|
Risky settings or potential pitfalls.
|
|||
|
|
:::
|
|||
|
|
|
|||
|
|
:::danger
|
|||
|
|
Data loss or security-impacting issues.
|
|||
|
|
:::
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
## Prose/style linting with Vale
|
|||
|
|
|
|||
|
|
Vale runs in CI on pull requests and pushes to `main`. PRs fail on error-level alerts; warnings and suggestions are annotated but don't fail. Run it locally to catch issues early.
|
|||
|
|
|
|||
|
|
Our Vale configuration aims to align with our internal writing rules (Google style + Haystack-specific checks).
|
|||
|
|
|
|||
|
|
If you encounter a StylesPath error, ensure the styles folder path in `.vale.ini` matches the repository layout.
|
|||
|
|
|
|||
|
|
Install Vale (macOS example):
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
brew install vale
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
For better MDX linting locally, also install `mdx2vast`:
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
npm install -g mdx2vast
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Run Vale at the repo root:
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
vale --config .vale.ini "**/*.{md,mdx}"
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
CI behavior:
|
|||
|
|
|
|||
|
|
- Runs on PRs and pushes as a GitHub Check with annotations.
|
|||
|
|
- The job fails on error-level alerts (`fail_on_error: true`); suggestions and warnings annotate but don't fail.
|
|||
|
|
- Maintainers can switch to PR review comments by using the `github-pr-review` reporter.
|
|||
|
|
|
|||
|
|
## Local build checks
|
|||
|
|
|
|||
|
|
Before you open a PR, ensure the site builds cleanly:
|
|||
|
|
|
|||
|
|
```bash
|
|||
|
|
npm run build
|
|||
|
|
```
|
|||
|
|
|
|||
|
|
Address warnings about broken links, anchors, and duplicate routes before submitting.
|
|||
|
|
|
|||
|
|
## Moving or removing pages
|
|||
|
|
|
|||
|
|
- Keep existing URLs stable whenever possible. If you move a page, retain its `slug` so the path does not change.
|
|||
|
|
- Update `sidebars.js` or `reference-sidebars.js` accordingly.
|
|||
|
|
- If a URL must change, coordinate with maintainers to set up a redirect strategy and avoid broken inbound links.
|
|||
|
|
|
|||
|
|
## Images and assets
|
|||
|
|
|
|||
|
|
- Place shared images in `static/img/` or per-section assets in `docs/assets/`.
|
|||
|
|
- Use descriptive filenames and alt text.
|
|||
|
|
- Prefer optimized images; the site uses responsive image tooling to reduce payload size.
|
|||
|
|
|
|||
|
|
## API Reference contributions
|
|||
|
|
|
|||
|
|
- The API documentation is automatically generated from Python docstrings in the Haystack codebase. To change API docs, edit the relevant docstrings in the [Haystack repository](https://github.com/deepset-ai/haystack) and open a PR there.
|
|||
|
|
- Do not edit files under `reference/` in this repository. They are regenerated and any manual changes will be overwritten.
|
|||
|
|
|
|||
|
|
## Accessibility and inclusivity checklist
|
|||
|
|
|
|||
|
|
- Alt text for images
|
|||
|
|
- Descriptive link text
|
|||
|
|
- Clear, concise sentences; avoid jargon when possible
|
|||
|
|
- Inclusive language and examples
|
|||
|
|
|
|||
|
|
## Pull request checklist
|
|||
|
|
|
|||
|
|
Before submitting your PR:
|
|||
|
|
|
|||
|
|
- Content follows our writing and style rules.
|
|||
|
|
- Navigation updated (`sidebars.js` / `reference-sidebars.js`).
|
|||
|
|
- Internal links verified (no broken anchors).
|
|||
|
|
- Code samples tested and language tags set on code blocks.
|
|||
|
|
- Images optimized and include alt text.
|
|||
|
|
- Local build passes (`npm run build`).
|
|||
|
|
- Vale checks pass (CI) or are locally resolved.
|
|||
|
|
- Conventional commit message used in the PR title (for example, `docs: add X`, `docs: fix Y`).
|
|||
|
|
|
|||
|
|
## Review process
|
|||
|
|
|
|||
|
|
- Open a PR from your branch. Include context, screenshots (if UI changes are shown), and link to related issues.
|
|||
|
|
- Maintainers may request changes for clarity, accuracy, scope, or style.
|
|||
|
|
- Once approved and checks pass, a maintainer will merge. Preview deployments may be available on the PR.
|