# Ror Dev Process

> ROR team development process and review culture — PR preparation conventions, changelog format, review etiquette, task lifecycle. Use when preparing/reviewing PRs or managing Jira tasks for ReadonlyREST.

- Skill: `sscarduzio/ror-dev-process` (Agent Skill)
- Install (CLI): `npx skillmds@latest add sscarduzio/ror-dev-process`
- Raw SKILL.md: https://api.skillmd.com/api/skills/sscarduzio/ror-dev-process/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: sscarduzio (https://skillmd.com/u/sscarduzio)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/sscarduzio/ror-dev-process

---


# ROR Development Process & Review Culture

Source of truth: `beshu-tech/readonlyrest-internal/development_guide.md`. This skill distills the parts that govern PRs and reviews.

## Preparing a PR (binding conventions)

- Branch name carries the Jira number: `bugfix/RORDEV-302`, `feature/RORDEV-xxx`
- PR title: `[RORDEV-NNN] short description`
- PR description starts with a **changelog phrase in the release convention** — emoji style, client perspective, copy-paste ready (leave blank for purely internal changes):
  - `🚨**Security Fix** (ES) search template handling fix`
  - `🚀**New** (ES) 7.9.0 support`
  - `🧐**Enhancement** (ES) full support for ES Snapshots and Restore APIs`
  - `🐞**Fix** (KBN) fix crash in error handling`
- PR text, review comments and commit messages use the repo writing style: Simplified Technical English (ASD-STE100) plus Zinsser — `docs/dev/writing-style.md`
- Pipelines must pass. Set the next pre-version before opening the PR.
- PRs are squash-and-merged. Which branch a PR targets, and what to do after a merge to `master`: `docs/dev/branching.md` (version mechanics: `ror-release` skill; internal architecture: `ror-internals`).
- New ES version support: mirror missing ES artifacts with the main repo's **Mirror ES Libs** workflow, which has the required S3 credentials. The step that gates CI build/test is `supportedEsVersions` in the module's `gradle.properties`, not `ci/upload-es-artifacts.sh`. Full checklist: `ror-release` skill, "Supporting a new ES version".

**CI checks the first two conventions** (`PR Conventions` workflow): the Jira key in the title, and a changelog entry when the PR changes production sources or dependencies. Both changelog forms above are accepted. Run it yourself before opening the PR:

```bash
ci/pr-conventions/run.sh <pr-number>
```

Each convention is one file in `ci/pr-conventions/checks/`, run in name order by `run.sh`; adding a convention means adding a file.

Escape hatches, for the cases a script cannot judge: the `no-jira` label, and the `no-changelog` label for a change a client cannot see (a refactor, a build change, a test). A reviewer should never have to ask for either of these — that is what the check is for.

## Review culture (the core rule)

**No comment goes unanswered** before the next review round or merge. A thumbs-up suffices; an elaborate disagreement is fine — anything that proves the submitter saw it. Once answered, **the comment's author resolves the thread** if happy with the outcome. Click GitHub's `request review` for each review iteration.

## Code placement & testing

- ES-independent shared code → `core` module
- ROR core change → unit test; ES-coupled change → integration test
- Test suites are organized **per ES API, not per ROR feature** (`IndicesAPISuite` ✅, `AuthRuleSuite` ❌)

## Task lifecycle (Jira: RORDEV board)

**Workflow:**

1. **Analysis** (always first): reproduce BUGs — flag in Jira if >8h; design-check FEATUREs.
2. **Estimate** in hours in `Story point estimate` (skip if <16h; INVESTIGATIONs report progress every 24h instead).
3. **Implementation** → **testing** → **PR** → **review**.
4. **Customer notification**.
5. **Close**: PR link in Jira, move to DONE.

**Rules:**

- One task in `IN PROGRESS` at a time.
- Blocked → `ON HOLD` **with a comment written for someone not involved in the ticket**.
- Tag every task `R&D` or `Support` (Support = reactive to a user/customer initiative).
- Track time in Clockify: `[Action] [What] – [Why/Context]`.

## Kibana feature-enablement principles

1. Never accidentally enable paid features. 2. Users must not lose free features by installing ROR. 3. Customers with both ROR + Elastic licenses keep what they paid for. 4. ROR-incompatible features get disabled or hidden.

## Customer notification

After merge to develop, CI uploads binaries to S3 — the developer notifies the reporting user with the build link and asks for a test. Jira tasks begin with `REPORT TO: ...`; if absent, contact the issue reporter.