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:

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.