From 8c6c26a6a1539cdedc8f1bb40c0cc0811f7bcdbe Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 13:31:41 +0800 Subject: [PATCH 01/18] docs: avoid duplicate notifications in Goal issues --- .claude/settings.local.json | 9 +++++++++ docs/CONTRIBUTING.md | 15 ++++++++++++--- 2 files changed, 21 insertions(+), 3 deletions(-) create mode 100644 .claude/settings.local.json diff --git a/.claude/settings.local.json b/.claude/settings.local.json new file mode 100644 index 0000000..6509471 --- /dev/null +++ b/.claude/settings.local.json @@ -0,0 +1,9 @@ +{ + "permissions": { + "allow": [ + "mcp__mcp-server-github__issue_read", + "Bash(gh issue:*)", + "Bash(gh pr:*)" + ] + } +} diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 9ed671b..282de43 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -80,6 +80,9 @@ It's essential to maintain clear links between Goals and related Problem issues. This helps everyone stay informed and team members can easily track progress and understand the context. +> [!IMPORTANT] +> Do not post Problem status updates or notifications back into the Goal issue. The link between them is sufficient — keep all updates within the Problem issue itself. + ### Solution The third pillar of successful contribution is the Solution. @@ -91,6 +94,9 @@ solution from the contributor. > [!NOTE] > Solution is presented in GitHub as a [Pull Request (PR)](https://docs.github.com/en/pull-requests) in compliance with [PR Requirements](#pr-requirements). +> [!IMPORTANT] +> Do not repost PR notifications or progress updates in the Goal issue. The PR is linked to the Problem, which is linked to the Goal — that chain is sufficient. Duplicate comments add noise. + ### Referencing When referencing issues or pull requests in any GitHub discussion, use a list @@ -139,8 +145,10 @@ sign their commits. For detailed instructions on why and how to sign your commits refer to [GitHub's documentation on commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). -> [!Note] -> We recommend signing commits using an [SSH key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). Ensure your Git version supports SSH signature verification (Git 2.34 or later). +> [!Note] We recommend signing commits using an +> [SSH key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). +> Ensure your Git version supports SSH signature verification (Git 2.34 or +> later). ## Scoping @@ -182,7 +190,8 @@ When starting to work on a Problem, you must: [draft PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests) right away. Do not mark PR as "ready to review" unless you are confident it is ready. -1. [Link opened PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) to the corresponding Problem (issue). +1. [Link opened PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) + to the corresponding Problem (issue). 1. Before marking your PR as ready for review, assign **at least one reviewer** (team or individual). Do not merge without approved review. From 8c7e2499912677dab038824e7362c6a17f989797 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 13:44:13 +0800 Subject: [PATCH 02/18] fix(lint): run CI check --- docs/ADVOCACY.md | 30 ++++++++++---------- docs/APPLICATION_SUCCESS.md | 3 +- docs/COMPENSATION.md | 24 ++++++++-------- docs/CONTRIBUTING.md | 56 ++++++++++++++++++++++++++----------- docs/LEAVE_POLICY.md | 20 ++++++------- docs/PRINCIPLES.md | 12 ++++---- docs/TRIAL.md | 2 +- 7 files changed, 86 insertions(+), 61 deletions(-) diff --git a/docs/ADVOCACY.md b/docs/ADVOCACY.md index 100bb9e..c86fcba 100644 --- a/docs/ADVOCACY.md +++ b/docs/ADVOCACY.md @@ -18,26 +18,28 @@ immediately update your GitHub, LinkedIn, and X profiles to reflect your role. Exclusively promote Holdex in your bio while employed—no other brands or links. Checklist: -| Attribute | Requirement | -|-----------|-------------| -| Name | First name only. | -| Bio | Role at Holdex (e.g., "Full-stack Engineer at @holdex"). | -| Company | @holdex | -| Location | localhost | -| Time | Uncheck; hide current time. | -| Email | Empty. | -| Social Link: X | | -| Social Link: website | | -| Social Link: LinkedIn | | -| Pinned Repositories | Holdex-related only. | -| Overview | In a public self-repo, create README.md stating your role, contributions, enthusiasm for Holdex, and links to Holdex website and GitHub org. | +| Attribute | Requirement | +| --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------- | +| Name | First name only. | +| Bio | Role at Holdex (e.g., "Full-stack Engineer at @holdex"). | +| Company | @holdex | +| Location | localhost | +| Time | Uncheck; hide current time. | +| Email | Empty. | +| Social Link: X | | +| Social Link: website | | +| Social Link: LinkedIn | | +| Pinned Repositories | Holdex-related only. | +| Overview | In a public self-repo, create README.md stating your role, contributions, enthusiasm for Holdex, and links to Holdex website and GitHub org. | ### LinkedIn Profile Add Holdex as your current experience in the "Experience" section. Use this mandatory description: -> Holdex is the premier partner for institutions pioneering DeFi & RWAs. Hong Kong-based since 2016, we turn bold visions into secure, scalable blockchain solutions—driving adoption with unmatched expertise. +> Holdex is the premier partner for institutions pioneering DeFi & RWAs. Hong +> Kong-based since 2016, we turn bold visions into secure, scalable blockchain +> solutions—driving adoption with unmatched expertise. ### X (Twitter) Profile diff --git a/docs/APPLICATION_SUCCESS.md b/docs/APPLICATION_SUCCESS.md index df952c8..8988ceb 100644 --- a/docs/APPLICATION_SUCCESS.md +++ b/docs/APPLICATION_SUCCESS.md @@ -3,7 +3,8 @@ We have received your application and will begin reviewing it soon. > [!NOTE] -> As much as we love to be fast, we are taking our time to reply to each one of you and it's not always immediate. Thank you for understanding. +> As much as we love to be fast, we are taking our time to reply to each one of +> you and it's not always immediate. Thank you for understanding. ## What's next for me? diff --git a/docs/COMPENSATION.md b/docs/COMPENSATION.md index 24aafc8..6b99fa7 100644 --- a/docs/COMPENSATION.md +++ b/docs/COMPENSATION.md @@ -13,18 +13,18 @@ deliver independently. ## Levels & Core Skills -| Level | Key Traits & Expectations | Team Culture | Goals | Problems & Solutions | -|-------|---------------------------|--------------|-------|----------------------| -| **Entry** | Student mindset: Bug-free. Execute tasks. Research. Learn fast. Communicate clearly. Take feedback. | Follow [principles](https://holdex.io/c/learn/principles) & [GitHub rules](https://holdex.io/c/learn/github-strategy). | Understand goals. | Solve, estimate, research, present. Help juniors. | -| **Intermediate** | Confident executor: Solve complex problems. Lead small parts. Help Entry. Strong opinions. | Follow principles. Remind team. | Break into problems. Research solutions. | Identify real problems. Break down. Prioritize. Review juniors. | -| **Lead** | Project owner: Run full projects. Delegate. Coach team. Align with business. Inspire. | Coach others. Lead in projects. | Set timelines. Ensure delivery. | Delegate. Distribute to best fit. | -| **Partner** | Big-picture leader: Own multiple projects. Shape strategy. Say no when needed. Grow culture. | Improve rules/values. | Define business goals & priorities. | (All above + strategic input) | +| Level | Key Traits & Expectations | Team Culture | Goals | Problems & Solutions | +| ---------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------- | ---------------------------------------- | --------------------------------------------------------------- | +| **Entry** | Student mindset: Bug-free. Execute tasks. Research. Learn fast. Communicate clearly. Take feedback. | Follow [principles](https://holdex.io/c/learn/principles) & [GitHub rules](https://holdex.io/c/learn/github-strategy). | Understand goals. | Solve, estimate, research, present. Help juniors. | +| **Intermediate** | Confident executor: Solve complex problems. Lead small parts. Help Entry. Strong opinions. | Follow principles. Remind team. | Break into problems. Research solutions. | Identify real problems. Break down. Prioritize. Review juniors. | +| **Lead** | Project owner: Run full projects. Delegate. Coach team. Align with business. Inspire. | Coach others. Lead in projects. | Set timelines. Ensure delivery. | Delegate. Distribute to best fit. | +| **Partner** | Big-picture leader: Own multiple projects. Shape strategy. Say no when needed. Grow culture. | Improve rules/values. | Define business goals & priorities. | (All above + strategic input) | ## Growth Path -| Level | Focus | -|-------|-------| -| **Entry** | Learn → Execute → Ask | -| **Intermediate** | Solve → Teach → Lead small | -| **Lead** | Own → Delegate → Coach | -| **Partner** | Strategize → Scale → Say No | +| Level | Focus | +| ---------------- | --------------------------- | +| **Entry** | Learn → Execute → Ask | +| **Intermediate** | Solve → Teach → Lead small | +| **Lead** | Own → Delegate → Coach | +| **Partner** | Strategize → Scale → Say No | diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 282de43..ac1aa20 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -8,7 +8,8 @@ approachable and respectful. If you are a permanent contributor, read our [Principles](./PRINCIPLES.md). > [!TIP] -> You can use [Wizard Browser Extension](https://chromewebstore.google.com/detail/wizard-browser-extension/gibcadmedmabfnfbolimcndljcopbhep) to simplify some of the workflows described in these Guidelines. +> You can use [Wizard Browser Extension][1] to simplify some of the workflows +> described in these Guidelines. ## Getting started @@ -19,7 +20,9 @@ There are three core contribution pillars: 1. **Solution** – the actual deliverable which resolves the problem > [!NOTE] -> In this guide you will get an overview of the contribution workflow: from finding a Goal, identifying a Problem, and the process of delivering your solutions. +> In this guide you will get an overview of the contribution workflow: from +> finding a Goal, identifying a Problem, and the process of delivering your +> solutions. ### Goal @@ -36,7 +39,8 @@ Each Goal description must include Specs (a Google Document with commenting permissions) and an ETA. > [!NOTE] -> A Goal is represented as a GitHub issue in the relevant repository and has the following naming pattern: `Goal: [statement]`. +> A Goal is represented as a GitHub issue in the relevant repository and has the +> following naming pattern: `Goal: [statement]`. > Goals are created and managed by Partner level contributors. #### Communication within Goal issues @@ -68,8 +72,11 @@ Anything that is stopping you - is a “Problem”. A typical question to ask is Sometimes, a Goal already has a few identified problems, but not always. > [!NOTE] -> Once a Problem is identified, we report it as a [GitHub Issue](https://docs.github.com/en/issues) with the following naming pattern: `Problem: [statement]`. -> We’re counting on our contributors to identify problems. Keep a Problem name short (under 65 chars) and crystal clear. +> Once a Problem is identified, we report it as a +> [GitHub Issue](https://docs.github.com/en/issues) with the following naming +> pattern: `Problem: [statement]`. We’re counting on our contributors to +> identify problems. Keep a Problem name short (under 65 chars) and crystal +> clear. Make sure each Problem issue is interlinked with it's Goal issue: @@ -81,7 +88,9 @@ This helps everyone stay informed and team members can easily track progress and understand the context. > [!IMPORTANT] -> Do not post Problem status updates or notifications back into the Goal issue. The link between them is sufficient — keep all updates within the Problem issue itself. +> Do not post Problem status updates or notifications back into the Goal issue. +> The link between them is sufficient — keep all updates within the Problem +> issue itself. ### Solution @@ -92,10 +101,14 @@ Whether it’s code, design, or marketing material, we expect a lean and clean solution from the contributor. > [!NOTE] -> Solution is presented in GitHub as a [Pull Request (PR)](https://docs.github.com/en/pull-requests) in compliance with [PR Requirements](#pr-requirements). +> Solution is presented in GitHub as a +> [Pull Request (PR)](https://docs.github.com/en/pull-requests) in compliance +> with [PR Requirements](#pr-requirements). > [!IMPORTANT] -> Do not repost PR notifications or progress updates in the Goal issue. The PR is linked to the Problem, which is linked to the Goal — that chain is sufficient. Duplicate comments add noise. +> Do not repost PR notifications or progress updates in the Goal issue. The PR +> is linked to the Problem, which is linked to the Goal — that chain is +> sufficient. Duplicate comments add noise. ### Referencing @@ -122,13 +135,13 @@ See these related items: Avoid simply pasting the URL inline. ```md -Check this out: -Related: -See for details +Check this out: Related: See + for details ``` > [!NOTE] -> The list format improves readability and helps contributors quickly understand the context by showing the referenced issue/PR titles automatically. +> The list format improves readability and helps contributors quickly understand +> the context by showing the referenced issue/PR titles automatically. ## PR Requirements @@ -180,7 +193,9 @@ The required checks are as follows: ``` > [!NOTE] -> Contributors need to resolve all CI issues before assigning reviewers or requesting a review. Any PR with unresolved CI checks should remain in "draft" status until all issues are fixed. +> Contributors need to resolve all CI issues before assigning reviewers or +> requesting a review. Any PR with unresolved CI checks should remain in "draft" +> status until all issues are fixed. ## Drafting @@ -218,7 +233,6 @@ Structure the design file with the following markup: - **`(...)`** - Used for grouping related features or components. - **`[...]`** - Indicates a specific state of the page or component, such as a popup or modal state. - - Indentation in the list represents the tree structure or hierarchy, showing how components or features are nested or related. @@ -241,7 +255,8 @@ If there isn't an existing DESIGN.md file: ## Naming > [!NOTE] -> We use PR titles to communicate changes to all stakeholders, including non-technical users. +> We use PR titles to communicate changes to all stakeholders, including +> non-technical users. PR names must be: @@ -281,7 +296,6 @@ A feature isn’t a button, toggle, or handler—it’s Correct:"Filter search results by category" 1. **Describe outcomes, not components**: Wrong: "Fix API error handling" → Correct:"Gracefully recover from connection errors" - 1. **Use user action verbs**: _View, Play, Customize, Save_, etc. ### Before Submitting, Ask @@ -297,7 +311,11 @@ Once your PR is ready, assign reviewers and mark it as "ready to review." But before that, report the time you have spent on it. > [!NOTE] -> When contributing, it's essential to report time accurately, including all stages of development (planning, implementation, QA). We encourage opening a PR at the start of your work, even during the planning or investigation phase. Programming and designing isn't just about writing code or creating designs; it also involves planning (40%) and QA (20-30%). +> When contributing, it's essential to report time accurately, including all +> stages of development (planning, implementation, QA). We encourage opening a +> PR at the start of your work, even during the planning or investigation phase. +> Programming and designing isn't just about writing code or creating designs; +> it also involves planning (40%) and QA (20-30%). ### Reviewing PRs @@ -323,3 +341,7 @@ thorough in your QA - reviewers are not QA team members but are there for a final safety check. We expect contributors to deliver bug-free software, understanding that perfection is an ideal. Stand firm in your solutions and avoid unnecessary revisions based on subjective feedback. + +--- + +[1]: https://chromewebstore.google.com/detail/wizard-browser-extension/gibcadmedmabfnfbolimcndljcopbhep diff --git a/docs/LEAVE_POLICY.md b/docs/LEAVE_POLICY.md index f7c5232..15f3758 100644 --- a/docs/LEAVE_POLICY.md +++ b/docs/LEAVE_POLICY.md @@ -5,14 +5,14 @@ described below or directly in the signed agreement. > [!IMPORTANT] > In case of conflict between the signed agreement and scheduler, the signed -agreement terms prevail. +> agreement terms prevail. ## How Many Days Do You Get? -| Your Service Time | Paid Days per Year | Can Carry Over | Can Get Paid When Leaving | -|-------------------------|--------------------|----------------|---------------------------| -| 0 – 6 months | 0 days | – | – | -| 6 months and more | 14 days | Max 3 days | Max 5 days | +| Your Service Time | Paid Days per Year | Can Carry Over | Can Get Paid When Leaving | +| ----------------- | ------------------ | -------------- | ------------------------- | +| 0 – 6 months | 0 days | – | – | +| 6 months and more | 14 days | Max 3 days | Max 5 days | These 14 days cover **everything**: vacation, personal days, sick days, and public holidays. @@ -27,8 +27,8 @@ See the [Leave Request guide](https://wizard.holdex.io/docs/leave-request). ## Money Rules – Super Simple -| Situation | What You Get / Lose | -|-----------------------------------|--------------------------------------------------------------------------------------| -| You leave the company | Up to 5 unused paid days are paid out → `monthly rate ÷ 30 × days` | -| You have leftover days at year end| Max 3 paid days move to next year. The rest disappear. | -| You take unpaid leave | Money is deducted → `monthly rate ÷ 30 × unpaid days` | +| Situation | What You Get / Lose | +| ---------------------------------- | ------------------------------------------------------------------ | +| You leave the company | Up to 5 unused paid days are paid out → `monthly rate ÷ 30 × days` | +| You have leftover days at year end | Max 3 paid days move to next year. The rest disappear. | +| You take unpaid leave | Money is deducted → `monthly rate ÷ 30 × unpaid days` | diff --git a/docs/PRINCIPLES.md b/docs/PRINCIPLES.md index 941a2f9..9d3a067 100644 --- a/docs/PRINCIPLES.md +++ b/docs/PRINCIPLES.md @@ -26,16 +26,16 @@ ## Do This | Not That -| ✅ **Do** | ❌ **Don’t** | -|----------|-------------| +| ✅ **Do** | ❌ **Don’t** | +| ------------------------- | ----------------------- | | Solve what moves the goal | Work on low-value tasks | -| Own it end-to-end | Pass the buck | -| Test your work | Expect others to QA | -| Leave clear updates | Vanish without trace | +| Own it end-to-end | Pass the buck | +| Test your work | Expect others to QA | +| Leave clear updates | Vanish without trace | --- -## ⏰ Core Hours +## ⏰ Core Hours **2–6 PM HKT** — Be online. Rest is flexible. diff --git a/docs/TRIAL.md b/docs/TRIAL.md index 6249013..7168bad 100644 --- a/docs/TRIAL.md +++ b/docs/TRIAL.md @@ -5,7 +5,7 @@ can only be observed during the trial period. Skills such as the ability to figure things out on your own, judgemental skills, decision-making, and async collaboration are part of our internal culture and what we aim for. -Across the whole engineering, our team operates the following way: +Across the whole engineering, our team operates the following way: 1. lead engineers contribute to defining business Goals along with the Partners and Stakeholders From 6a5912f1b55b5250e924d3d6434e91348a75dfde Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 13:48:29 +0800 Subject: [PATCH 03/18] fix(lint): run CI check --- .github/workflows/markdown_lint.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/markdown_lint.yml b/.github/workflows/markdown_lint.yml index 93caa32..2a60ed8 100644 --- a/.github/workflows/markdown_lint.yml +++ b/.github/workflows/markdown_lint.yml @@ -17,7 +17,7 @@ jobs: - name: Install rumdl pre-compiled binary run: | # Define the URL for the latest Linux binary - DOWNLOAD_URL="https://github.com/rvben/rumdl/releases/download/v0.0.185/rumdl-v0.0.185-x86_64-unknown-linux-gnu.tar.gz" + DOWNLOAD_URL="https://github.com/rvben/rumdl/releases/download/v0.0.185/rumdl-v0.1.167-x86_64-unknown-linux-gnu.tar.gz" # Use curl to download the archive and tar to extract it curl -sL $DOWNLOAD_URL | tar -xz -C /usr/local/bin/ From b0d8c8a5ab35ee5267fcd08b0a42bcd1bbada198 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 13:50:44 +0800 Subject: [PATCH 04/18] fix(lint): run CI check --- .github/workflows/markdown_lint.yml | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/.github/workflows/markdown_lint.yml b/.github/workflows/markdown_lint.yml index 2a60ed8..0c65660 100644 --- a/.github/workflows/markdown_lint.yml +++ b/.github/workflows/markdown_lint.yml @@ -17,7 +17,7 @@ jobs: - name: Install rumdl pre-compiled binary run: | # Define the URL for the latest Linux binary - DOWNLOAD_URL="https://github.com/rvben/rumdl/releases/download/v0.0.185/rumdl-v0.1.167-x86_64-unknown-linux-gnu.tar.gz" + DOWNLOAD_URL="https://github.com/rvben/rumdl/releases/download/v0.1.67/rumdl-v0.1.67-x86_64-unknown-linux-gnu.tar.gz" # Use curl to download the archive and tar to extract it curl -sL $DOWNLOAD_URL | tar -xz -C /usr/local/bin/ From ff3d3e7d43548a02ed426d2f9669ad5b83012fec Mon Sep 17 00:00:00 2001 From: Vadim Date: Wed, 8 Apr 2026 13:51:46 +0800 Subject: [PATCH 05/18] Update .claude/settings.local.json Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Vadim --- .claude/settings.local.json | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/.claude/settings.local.json b/.claude/settings.local.json index 6509471..df5f290 100644 --- a/.claude/settings.local.json +++ b/.claude/settings.local.json @@ -2,8 +2,10 @@ "permissions": { "allow": [ "mcp__mcp-server-github__issue_read", - "Bash(gh issue:*)", - "Bash(gh pr:*)" + "Bash(gh issue view:*)", + "Bash(gh issue list:*)", + "Bash(gh pr view:*)", + "Bash(gh pr list:*)" ] } } From a53b74568b3f092d34149a40c73302c9892d0240 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 13:56:05 +0800 Subject: [PATCH 06/18] chore: ignore files --- .claude/settings.local.json | 9 --------- .gitignore | 1 + 2 files changed, 1 insertion(+), 9 deletions(-) delete mode 100644 .claude/settings.local.json create mode 100644 .gitignore diff --git a/.claude/settings.local.json b/.claude/settings.local.json deleted file mode 100644 index 6509471..0000000 --- a/.claude/settings.local.json +++ /dev/null @@ -1,9 +0,0 @@ -{ - "permissions": { - "allow": [ - "mcp__mcp-server-github__issue_read", - "Bash(gh issue:*)", - "Bash(gh pr:*)" - ] - } -} diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..d6b130c --- /dev/null +++ b/.gitignore @@ -0,0 +1 @@ +.claude/settings.local.json From 403bcb426347cafb494abddd380f79dd4425fb53 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 14:06:25 +0800 Subject: [PATCH 07/18] ci: use reusable Actions --- .github/workflows/markdown_lint.yml | 41 +++++++++++++++++------------ settings.json | 20 ++++++++++++++ 2 files changed, 44 insertions(+), 17 deletions(-) create mode 100644 settings.json diff --git a/.github/workflows/markdown_lint.yml b/.github/workflows/markdown_lint.yml index 0c65660..3f43cdf 100644 --- a/.github/workflows/markdown_lint.yml +++ b/.github/workflows/markdown_lint.yml @@ -1,28 +1,35 @@ -name: Markdown Lint +name: Validate Markdown and PR naming on: - push: + pull_request: branches: - main - pull_request: - # Also trigger on ready_for_review to run when a PR changes from draft to ready - types: [opened, reopened, synchronize, ready_for_review] + paths: + - "**.md" + types: + - opened + - synchronize + - reopened + - ready_for_review jobs: - lint: + checks: + if: github.event.pull_request.draft == false runs-on: ubuntu-latest - if: ${{ github.event_name != 'pull_request' || !github.event.pull_request.draft }} steps: - uses: actions/checkout@v4 - - name: Install rumdl pre-compiled binary - run: | - # Define the URL for the latest Linux binary - DOWNLOAD_URL="https://github.com/rvben/rumdl/releases/download/v0.1.67/rumdl-v0.1.67-x86_64-unknown-linux-gnu.tar.gz" - # Use curl to download the archive and tar to extract it - curl -sL $DOWNLOAD_URL | tar -xz -C /usr/local/bin/ + - uses: holdex/github-actions/.github/actions/base/checkout@main + with: + ref: 05eefbf2dfd772dbb2c12b9985d21ac24c5da0e5 + + - uses: ./.holdex-actions/.github/actions/base/setup-runtime + with: + package-manager: bun - # Ensure the binary is executable and in the PATH - chmod +x /usr/local/bin/rumdl - - name: Lint Markdown - run: rumdl check --output-format github . + - uses: ./.holdex-actions/.github/actions/composed/pr-checks + with: + run-prettier: false + run-markdown: true + run-commits: true + package-manager: bun diff --git a/settings.json b/settings.json new file mode 100644 index 0000000..9a6a529 --- /dev/null +++ b/settings.json @@ -0,0 +1,20 @@ +{ + "lsp": { + "rumdl": { + "binary": { + "path": "rumdl", + "arguments": ["server"] + } + } + }, + "languages": { + "Markdown": { + "language_servers": ["rumdl", "!markdown-language-server"], + "format_on_save": { + "language_server": { + "name": "rumdl" + } + } + } + } +} From 03f40b95b238abd897b154a7ce892693530c4dd8 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 14:27:17 +0800 Subject: [PATCH 08/18] docs: view better Code Of Conduct structure --- README.md | 1 - docs/CODE_OF_CONDUCT.md | 59 ++++++++++++++++++++++++++--------------- docs/CONTRIBUTING.md | 8 ++++-- docs/PRINCIPLES.md | 45 ------------------------------- 4 files changed, 44 insertions(+), 69 deletions(-) delete mode 100644 docs/PRINCIPLES.md diff --git a/README.md b/README.md index 5009fc1..d66dbe4 100644 --- a/README.md +++ b/README.md @@ -12,7 +12,6 @@ envision. Align with: -- [Principles](./docs/PRINCIPLES.md) - [Contributing Guidelines](./docs/CONTRIBUTING.md) - [Advocacy Guidelines](./docs/ADVOCACY.md) - [Code of Conduct](./docs/CODE_OF_CONDUCT.md) diff --git a/docs/CODE_OF_CONDUCT.md b/docs/CODE_OF_CONDUCT.md index 1422477..3ed00cc 100644 --- a/docs/CODE_OF_CONDUCT.md +++ b/docs/CODE_OF_CONDUCT.md @@ -1,39 +1,56 @@ # Code of Conduct -1. Make sure you are aligned with our Core Values. -1. Ensure the quality of your work. It is a sign of poor ownership and lack of - confidence when you expect someone to deal with your incomplete work. -1. Assign yourself to the Problem you are solving so others are aware of it. -1. Use `@mention` only when the person truly needs to be notified or take action - — otherwise, use reactions (likes, thumbs up, etc.) for acknowledgment. -1. Leave daily updates on relevant tasks/problems to maintain visibility and - simplicity for the team. -1. Keep all communication task-focused: work topics, deliverables, questions, - status, decisions, outcomes only. No personal compliments/flattery, unrelated - hesitation/fear, or extra personal remarks. - ## Core Values -- **“Dream Big”** — it's important to set ambitious goals to challenge the +- **"Dream Big"** — it's important to set ambitious goals to challenge the status quo. Otherwise, it's not worth it. -- **“Do the Right Thing”** — if you do something “right” but it is the wrong +- **"Do the Right Thing"** — if you do something "right" but it is the wrong thing to do, your efforts will be in vain. -- **“Keep it Simple”** — simplicity is a significant key to success. The most +- **"Keep it Simple"** — simplicity is a significant key to success. The most complicated skill is to be simple. _In communication, this means keeping messages concise, clear, and work-centered. We value straightforward updates, feedback, and reactions over unnecessary elaboration or personal asides that can complicate understanding or slow progress._ -- **“Own it with Passion”** — we believe in taking ownership and responsibility - for our work. We encourage a mindset of accelerated learning as you “figure it - out yourself” and the drive to go beyond expectations. We are passionate about +- **"Own it with Passion"** — we believe in taking ownership and responsibility + for our work. We encourage a mindset of accelerated learning as you "figure it + out yourself" and the drive to go beyond expectations. We are passionate about what we do and understand that our team success is dependent on us. -- **“Be Open”** — expand your horizons by challenging your beliefs and embracing +- **"Be Open"** — expand your horizons by challenging your beliefs and embracing new knowledge, ideas, and opportunities. See things from the perspective of others, and you may uncover potential missteps and grow in your understanding. Open your mind to learn and grow, strengthening your self-belief. It's not failure that matters, but the ability to get back up after falling. -- **“Keep the Focus”** — to achieve our team goals, ask, “What is our biggest - obstacle?” and focus on the next actionable step. Continuously review our +- **"Keep the Focus"** — to achieve our team goals, ask, "What is our biggest + obstacle?" and focus on the next actionable step. Continuously review our goals to ensure that your actions are aligned. Identify areas of improvement constantly to streamline resources and enhance business efficacy. + +## Rules + +Make sure you are aligned with our Core Values and follow the rules below. + +### Ownership + +1. Ensure the quality of your work. It is a sign of poor ownership and lack of + confidence when you expect someone to deal with your incomplete work. +1. Assign yourself to the Goal or Problem you are working on so others are + aware of it. + +### Communication + +1. Use `@mention` only when the person truly needs to be notified or take + action — otherwise, use reactions (likes, thumbs up, etc.) for + acknowledgment. +1. Leave daily updates on relevant tasks/problems to maintain visibility and + simplicity for the team. +1. Keep all communication task-focused: work topics, deliverables, questions, + status, decisions, outcomes only. No personal compliments/flattery, unrelated + hesitation/fear, or extra personal remarks. +1. Work async. Keep meetings to a minimum — one team sync per week is the norm. + Do not schedule meetings unless truly necessary. + +### Availability + +1. Be online during core hours: **2–6 PM HKT**. The rest of your schedule is + flexible. diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index ac1aa20..7321c94 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -4,8 +4,7 @@ Thank you for your interest in contributing to our project! Your accepted contributions will be reflected in our repositories and related websites. Please read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community -approachable and respectful. -If you are a permanent contributor, read our [Principles](./PRINCIPLES.md). +approachable and respectful. > [!TIP] > You can use [Wizard Browser Extension][1] to simplify some of the workflows @@ -31,6 +30,7 @@ contribution. As soon as you get involved, you must: +1. assign yourself to the Goal issue. 1. analyze specifications (the Specs), 1. assess progress and outstanding Problems and 1. provide an estimated time of achieving (ETA) the Goal. @@ -63,6 +63,9 @@ If you identify a potential new problem but are unsure whether it is planned: Avoid extended discussions in Goal issues. Instead, move conversations to the relevant Spec document or Problem issue. +If someone's action is required to unblock progress, assign them to the Goal +issue so the dependency is visible. + ### Problem Once the Goal is clear, you must identify what stops you from achieving it. @@ -207,6 +210,7 @@ When starting to work on a Problem, you must: is ready. 1. [Link opened PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) to the corresponding Problem (issue). +1. Assign yourself to the PR so it is clear who is working on it. 1. Before marking your PR as ready for review, assign **at least one reviewer** (team or individual). Do not merge without approved review. diff --git a/docs/PRINCIPLES.md b/docs/PRINCIPLES.md deleted file mode 100644 index 9d3a067..0000000 --- a/docs/PRINCIPLES.md +++ /dev/null @@ -1,45 +0,0 @@ -# Our Principles - -**We build great things together—fast, smart, and with full ownership.** - -## The 6 Rules We Live By - -1. **Start with the Goal** - Keep the big picture. Break it into clear problems. Solve one at a time. - -1. **Own It Like a Founder** - No one assigns tasks. You spot problems, claim them, and deliver results. - -1. **Ship Daily, Small & Often** - No task >4 hours. Finish, push, move on. Momentum beats perfection. - -1. **Respect Time—Yours & Others** - One team sync/week. Work async. No meetings unless needed. - -1. **Wear Many Hats** - Code, design, test, write, explore. We grow by doing. - -1. **Figure It Out** - Research. Read. Ask. Learn fast. No waiting for instructions. - ---- - -## Do This | Not That - -| ✅ **Do** | ❌ **Don’t** | -| ------------------------- | ----------------------- | -| Solve what moves the goal | Work on low-value tasks | -| Own it end-to-end | Pass the buck | -| Test your work | Expect others to QA | -| Leave clear updates | Vanish without trace | - ---- - -## ⏰ Core Hours - -**2–6 PM HKT** — Be online. Rest is flexible. - ---- - -**Be bold. Be fast. Be kind.** -That’s how we win. From d14bc60af74cd3d08a595df59a4a40d228f670a9 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 14:52:36 +0800 Subject: [PATCH 09/18] docs: view better structure --- docs/CONTRIBUTING.md | 92 ++++++++++++++++++++++++++++++-------------- 1 file changed, 64 insertions(+), 28 deletions(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 7321c94..ce03433 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -10,6 +10,22 @@ approachable and respectful. > You can use [Wizard Browser Extension][1] to simplify some of the workflows > described in these Guidelines. +## Table of Contents + +- [Getting started](#getting-started) + - [Goal](#goal) + - [Problem](#problem) + - [Solution](#solution) +- [Communication Guidelines](#communication-guidelines) +- [PR Requirements](#pr-requirements) + - [Commit Signature Verification](#commit-signature-verification) + - [Scoping](#scoping) + - [CI Checks](#ci-checks) + - [Drafting](#drafting) + - [Naming](#naming) + - [Requesting Review](#requesting-review) + - [Review Process](#review-process) + ## Getting started There are three core contribution pillars: @@ -69,7 +85,7 @@ issue so the dependency is visible. ### Problem Once the Goal is clear, you must identify what stops you from achieving it. -Anything that is stopping you - is a “Problem”. A typical question to ask is: +Anything that is stopping you - is a "Problem". A typical question to ask is: "Why is this Goal not achieved and what is the Problem?". Sometimes, a Goal already has a few identified problems, but not always. @@ -77,9 +93,19 @@ Sometimes, a Goal already has a few identified problems, but not always. > [!NOTE] > Once a Problem is identified, we report it as a > [GitHub Issue](https://docs.github.com/en/issues) with the following naming -> pattern: `Problem: [statement]`. We’re counting on our contributors to +> pattern: `Problem: [statement]`. We're counting on our contributors to > identify problems. Keep a Problem name short (under 65 chars) and crystal > clear. +> +> The statement must read as a **job story**: describe what the specific user +> **can't do** or what is broken for them. Ask: _"What can [user] not do +> because of this problem?"_ + +| **Good** ✅ | **Bad** ❌ | **Why?** | +| ------------------------------------------------ | ---------------------------------------------- | ------------------------------ | +| `operators can't view their account balance` | `operators don't have their account balance` | Describes inability, not state | +| `users can't submit a form without refreshing` | `form submission issue` | Vague, no actor or action | +| `admins can't export reports as CSV` | `CSV export missing` | No subject, not a job story | Make sure each Problem issue is interlinked with it's Goal issue: @@ -100,7 +126,7 @@ understand the context. The third pillar of successful contribution is the Solution. Different problems may require different sets of skills. -Whether it’s code, design, or marketing material, we expect a lean and clean +Whether it's code, design, or marketing material, we expect a lean and clean solution from the contributor. > [!NOTE] @@ -113,14 +139,14 @@ solution from the contributor. > is linked to the Problem, which is linked to the Goal — that chain is > sufficient. Duplicate comments add noise. -### Referencing +## Communication Guidelines When referencing issues or pull requests in any GitHub discussion, use a list item format to enable automatic title rendering and improve readability. This ensures that GitHub automatically expands the reference to show the issue/PR title. -#### Correct Format +### Correct Format Use a list item to reference issues or PRs: @@ -133,7 +159,7 @@ See these related items: - #12 ``` -#### Incorrect Formats +### Incorrect Formats Avoid simply pasting the URL inline. @@ -148,13 +174,23 @@ Check this out: Related: See ## PR Requirements -All PRs, whether for source code, design, or copy changes, must comply with our -PR Requirements. +All PRs, whether for source code, design, or copy changes, must comply with the +following requirements. > [!WARNING] > PRs that do not correspond to the following criteria are usually rejected. -## Commit Signature Verification +Before marking your PR as ready for review, confirm: + +- [ ] Commits are signed +- [ ] PR scope fits within 3–4 hours of work +- [ ] All CI checks pass +- [ ] PR is linked to a Problem issue +- [ ] At least one reviewer is assigned +- [ ] Time is reported +- [ ] PR title follows `type(scope): action` naming convention + +### Commit Signature Verification For the security and integrity of our project, we require all contributors to sign their commits. @@ -166,7 +202,7 @@ For detailed instructions on why and how to sign your commits refer to > Ensure your Git version supports SSH signature verification (Git 2.34 or > later). -## Scoping +### Scoping > [!NOTE] > Here's a [good resource](https://youtu.be/bmSAYlu0NcY?si=2lLQeY1PGCY9tcvX) on software design philosophy. @@ -181,7 +217,7 @@ We usually reject and close PRs which do not have activity for the last 24 hours, unless there is a clear comment explaining the reason why that PR is stalled. -## CI Checks +### CI Checks To maintain the quality and integrity of our project, all PRs must successfully pass the required Continuous Integration (CI) checks before being marked as @@ -200,7 +236,7 @@ The required checks are as follows: > requesting a review. Any PR with unresolved CI checks should remain in "draft" > status until all issues are fixed. -## Drafting +### Drafting When starting to work on a Problem, you must: @@ -214,7 +250,7 @@ When starting to work on a Problem, you must: 1. Before marking your PR as ready for review, assign **at least one reviewer** (team or individual). Do not merge without approved review. -### Design PRs +#### Design PRs Initiate a PR with a note in the DESIGN.md file detailing the addressed design aspects. Design PRs use `docs(ui)` as the "type" and "scope" of its name. i.e.: @@ -230,7 +266,7 @@ Structure the design file with the following markup: - [[state]](https://figma.com/your-design-file-url) ``` -#### Key +##### Key - **`/...`** - Represents a page. - **`{...}`** - Represents a dynamic parameter within a URL. @@ -256,7 +292,7 @@ If there isn't an existing DESIGN.md file: 1. Create a new file named DESIGN.md. 1. Link it from README.md. -## Naming +### Naming > [!NOTE] > We use PR titles to communicate changes to all stakeholders, including @@ -268,7 +304,7 @@ PR names must be: 1. **Follow [Conventional Commits](https://www.conventionalcommits.org)** 1. **Clear & simple** (present tense, action-oriented) -### Example Comparison +#### Example Comparison | **Good Examples** ✅ | **Bad Examples** ❌ | **Why?** | | ---------------------- | ------------------------------ | ------------------ | @@ -276,25 +312,23 @@ PR names must be: | `fix(sdk): mute sound` | `Fix: add file to mute sound` | Technical details | | `test(api): open door` | `Feat: modified door function` | Vague, past tense | ---- - -### Key Principles +#### Key Principles -#### What to Focus On +##### What to Focus On -A feature isn’t a button, toggle, or handler—it’s +A feature isn't a button, toggle, or handler—it's **what the user gains from it**. Ask: - ❌ _"What am I building?"_ → Leads to technical labels. - ✅ _"What will users be able to do?"_ → Leads to clear value. -#### Why It Matters +##### Why It Matters - **Clarity**: Engineers, PMs, and stakeholders instantly understand the impact. - **Consistency**: Aligns with product-facing language (release notes, docs). - **User-Centricity**: Work is driven by user needs, not just code changes. -#### How to Apply It +##### How to Apply It 1. **Replace UI labels with actions**: Wrong: "Add dropdown for filters" → Correct:"Filter search results by category" @@ -302,14 +336,14 @@ A feature isn’t a button, toggle, or handler—it’s Correct:"Gracefully recover from connection errors" 1. **Use user action verbs**: _View, Play, Customize, Save_, etc. -### Before Submitting, Ask +#### Before Submitting, Ask 1. Does it use `type(scope [Optional]): action` format? 1. Could a non-technical user understand the benefit? 1. Is it in the present tense? 1. Does it focus on user capability (not code)? -## Requesting Review +### Requesting Review Once your PR is ready, assign reviewers and mark it as "ready to review." But before that, report the time you have spent on it. @@ -321,7 +355,9 @@ before that, report the time you have spent on it. > Programming and designing isn't just about writing code or creating designs; > it also involves planning (40%) and QA (20-30%). -### Reviewing PRs +### Review Process + +#### Giving a Review Use **Request Changes** (reject) only for objective problems: @@ -332,13 +368,13 @@ Use **Request Changes** (reject) only for objective problems: Use **Comment** for optional improvements or suggestions. -### Scout approach +#### Scout Approach If you ever have free time, be proactive and apply the scout approach: own the job, look for PRs that still need reviewers, and offer timely feedback so work keeps moving. -### Code Quality and Reviews +#### Code Quality Aim for solutions that work correctly 99.9% of the time. Be independent and thorough in your QA - reviewers are not QA team members but are there for a From c03a7f0a3c3f2ef745595a25d9eb1eebb81692d7 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 15:04:23 +0800 Subject: [PATCH 10/18] docs: view better structure --- docs/CONTRIBUTING.md | 240 +++++++++++++++---------------------------- 1 file changed, 84 insertions(+), 156 deletions(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index ce03433..92ed3d9 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -20,10 +20,8 @@ approachable and respectful. - [PR Requirements](#pr-requirements) - [Commit Signature Verification](#commit-signature-verification) - [Scoping](#scoping) - - [CI Checks](#ci-checks) - - [Drafting](#drafting) - [Naming](#naming) - - [Requesting Review](#requesting-review) + - [PR Lifecycle](#pr-lifecycle) - [Review Process](#review-process) ## Getting started @@ -59,29 +57,6 @@ permissions) and an ETA. > following naming pattern: `Goal: [statement]`. > Goals are created and managed by Partner level contributors. -#### Communication within Goal issues - -To maintain clarity and efficiency, discussions should be directed to the -appropriate channels: - -- **Use the Spec document** for clarifications about the Goal, its scope, or - business context. -- **Use Problem issues** for tracking obstacles that prevent achieving the Goal. -- **Goal issues should remain clean**, primarily linking Specs, tracking - Problems, and monitoring progress. - -If you identify a potential new problem but are unsure whether it is planned: - -1. First, check if there is an existing Problem issue related to your concern. -1. If there isn't, ask for clarification in the Spec document. -1. If necessary, create a new Problem issue and discuss it there. - -Avoid extended discussions in Goal issues. Instead, move conversations to the -relevant Spec document or Problem issue. - -If someone's action is required to unblock progress, assign them to the Goal -issue so the dependency is visible. - ### Problem Once the Goal is clear, you must identify what stops you from achieving it. @@ -101,26 +76,17 @@ Sometimes, a Goal already has a few identified problems, but not always. > **can't do** or what is broken for them. Ask: _"What can [user] not do > because of this problem?"_ -| **Good** ✅ | **Bad** ❌ | **Why?** | -| ------------------------------------------------ | ---------------------------------------------- | ------------------------------ | -| `operators can't view their account balance` | `operators don't have their account balance` | Describes inability, not state | -| `users can't submit a form without refreshing` | `form submission issue` | Vague, no actor or action | -| `admins can't export reports as CSV` | `CSV export missing` | No subject, not a job story | +| **Good** ✅ | **Bad** ❌ | **Why?** | +| ---------------------------------------------- | -------------------------------------------- | ------------------------------ | +| `operators can't view their account balance` | `operators don't have their account balance` | Describes inability, not state | +| `users can't submit a form without refreshing` | `form submission issue` | Vague, no actor or action | +| `admins can't export reports as CSV` | `CSV export missing` | No subject, not a job story | -Make sure each Problem issue is interlinked with it's Goal issue: +Make sure each Problem issue is interlinked with its Goal issue: - add a Problem issue link into the Goal description - add a Goal issue link to the Problem description -It's essential to maintain clear links between Goals and related Problem issues. -This helps everyone stay informed and team members can easily track progress and -understand the context. - -> [!IMPORTANT] -> Do not post Problem status updates or notifications back into the Goal issue. -> The link between them is sufficient — keep all updates within the Problem -> issue itself. - ### Solution The third pillar of successful contribution is the Solution. @@ -134,21 +100,38 @@ solution from the contributor. > [Pull Request (PR)](https://docs.github.com/en/pull-requests) in compliance > with [PR Requirements](#pr-requirements). +## Communication Guidelines + +### Discussion channels + +Direct discussions to the appropriate channel at all times: + +- **Spec document** — clarifications about Goal scope or business context +- **Problem issues** — tracking obstacles that prevent achieving the Goal +- **Goal issues** — linking Specs, tracking Problems, and monitoring progress only + > [!IMPORTANT] -> Do not repost PR notifications or progress updates in the Goal issue. The PR -> is linked to the Problem, which is linked to the Goal — that chain is -> sufficient. Duplicate comments add noise. +> Do not post Problem status updates, PR notifications, or progress updates in +> Goal issues. The Goal → Problem → PR chain makes these redundant and adds +> noise. -## Communication Guidelines +If you identify a potential new problem but are unsure whether it is planned: + +1. Check if there is an existing Problem issue related to your concern. +1. If not, ask for clarification in the Spec document. +1. If necessary, create a new Problem issue and discuss it there. + +If someone's action is required to unblock progress, assign them to the Goal +issue so the dependency is visible. + +### Referencing issues and PRs -When referencing issues or pull requests in any GitHub discussion, use a list +When referencing issues or pull requests, use a list item format to enable automatic title rendering and improve readability. This ensures that GitHub automatically expands the reference to show the issue/PR title. -### Correct Format - -Use a list item to reference issues or PRs: +**Correct** — use a list item: ```md See these related items: @@ -159,19 +142,13 @@ See these related items: - #12 ``` -### Incorrect Formats - -Avoid simply pasting the URL inline. +**Incorrect** — avoid inline pasting: ```md Check this out: Related: See for details ``` -> [!NOTE] -> The list format improves readability and helps contributors quickly understand -> the context by showing the referenced issue/PR titles automatically. - ## PR Requirements All PRs, whether for source code, design, or copy changes, must comply with the @@ -217,46 +194,46 @@ We usually reject and close PRs which do not have activity for the last 24 hours, unless there is a clear comment explaining the reason why that PR is stalled. -### CI Checks +### Naming -To maintain the quality and integrity of our project, all PRs must successfully -pass the required Continuous Integration (CI) checks before being marked as -"ready to review." PRs with failing CI checks will be rejected. +> [!NOTE] +> We use PR titles to communicate changes to all stakeholders, including +> non-technical users. -The required checks are as follows: +PR names must be: -```text -- The pr-time-tracker verifies that the time spent on the PR has been properly logged. -- The pr-time-tracker for bugs ensures that bug-related time tracking is correctly linked to the corresponding commit and bug author. -- The code-rabbit validates that the code meets quality standards and passes all automated checks. -``` +1. **User-focused**: Describe what users gain, not technical implementation +1. **Follow [Conventional Commits](https://www.conventionalcommits.org)** +1. **Clear & simple** (present tense, action-oriented) -> [!NOTE] -> Contributors need to resolve all CI issues before assigning reviewers or -> requesting a review. Any PR with unresolved CI checks should remain in "draft" -> status until all issues are fixed. +| **Good Examples** ✅ | **Bad Examples** ❌ | **Why?** | +| ---------------------- | ------------------------------ | ------------------ | +| `feat(ui): play music` | `Create player` | Missing scope/type | +| `fix(sdk): mute sound` | `Fix: add file to mute sound` | Technical details | +| `test(api): open door` | `Feat: modified door function` | Vague, past tense | -### Drafting +A feature isn't a button, toggle, or handler — it's **what the user gains from +it**. Ask _"What will users be able to do?"_ not _"What am I building?"_ -When starting to work on a Problem, you must: +1. **Replace UI labels with actions**: Wrong: "Add dropdown for filters" → + Correct: "Filter search results by category" +1. **Describe outcomes, not components**: Wrong: "Fix API error handling" → + Correct: "Gracefully recover from connection errors" +1. **Use user action verbs**: _View, Play, Customize, Save_, etc. + +#### Before Submitting, Ask -1. Open a - [draft PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests) - right away. Do not mark PR as "ready to review" unless you are confident it - is ready. -1. [Link opened PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword) - to the corresponding Problem (issue). -1. Assign yourself to the PR so it is clear who is working on it. -1. Before marking your PR as ready for review, assign **at least one reviewer** - (team or individual). Do not merge without approved review. +1. Does it use `type(scope [Optional]): action` format? +1. Could a non-technical user understand the benefit? +1. Is it in the present tense? +1. Does it focus on user capability (not code)? #### Design PRs -Initiate a PR with a note in the DESIGN.md file detailing the addressed design -aspects. Design PRs use `docs(ui)` as the "type" and "scope" of its name. i.e.: -`docs(ui): design table component` +Design PRs use `docs(ui)` as the type and scope. e.g.: `docs(ui): design table component` -Structure the design file with the following markup: +Initiate a PR with a note in the DESIGN.md file detailing the addressed design +aspects. Structure the design file with the following markup: ```text ## Feature @@ -266,15 +243,13 @@ Structure the design file with the following markup: - [[state]](https://figma.com/your-design-file-url) ``` -##### Key +**Key:** -- **`/...`** - Represents a page. -- **`{...}`** - Represents a dynamic parameter within a URL. -- **`(...)`** - Used for grouping related features or components. -- **`[...]`** - Indicates a specific state of the page or component, such as a - popup or modal state. -- Indentation in the list represents the tree structure or hierarchy, showing - how components or features are nested or related. +- **`/...`** — a page +- **`{...}`** — a dynamic URL parameter +- **`(...)`** — a grouping of related features or components +- **`[...]`** — a specific state (e.g. popup or modal) +- Indentation represents nesting hierarchy Example: @@ -287,73 +262,26 @@ Example: - [[Bid Popup]](https://figma.com/your-design-file-url) ``` -If there isn't an existing DESIGN.md file: - -1. Create a new file named DESIGN.md. -1. Link it from README.md. - -### Naming - -> [!NOTE] -> We use PR titles to communicate changes to all stakeholders, including -> non-technical users. - -PR names must be: - -1. **User-focused**: Describe what users gain, not technical implementation -1. **Follow [Conventional Commits](https://www.conventionalcommits.org)** -1. **Clear & simple** (present tense, action-oriented) - -#### Example Comparison +If there isn't an existing DESIGN.md file, create one and link it from README.md. -| **Good Examples** ✅ | **Bad Examples** ❌ | **Why?** | -| ---------------------- | ------------------------------ | ------------------ | -| `feat(ui): play music` | `Create player` | Missing scope/type | -| `fix(sdk): mute sound` | `Fix: add file to mute sound` | Technical details | -| `test(api): open door` | `Feat: modified door function` | Vague, past tense | - -#### Key Principles - -##### What to Focus On - -A feature isn't a button, toggle, or handler—it's -**what the user gains from it**. Ask: - -- ❌ _"What am I building?"_ → Leads to technical labels. -- ✅ _"What will users be able to do?"_ → Leads to clear value. - -##### Why It Matters - -- **Clarity**: Engineers, PMs, and stakeholders instantly understand the impact. -- **Consistency**: Aligns with product-facing language (release notes, docs). -- **User-Centricity**: Work is driven by user needs, not just code changes. - -##### How to Apply It - -1. **Replace UI labels with actions**: Wrong: "Add dropdown for filters" → - Correct:"Filter search results by category" -1. **Describe outcomes, not components**: Wrong: "Fix API error handling" → - Correct:"Gracefully recover from connection errors" -1. **Use user action verbs**: _View, Play, Customize, Save_, etc. - -#### Before Submitting, Ask - -1. Does it use `type(scope [Optional]): action` format? -1. Could a non-technical user understand the benefit? -1. Is it in the present tense? -1. Does it focus on user capability (not code)? +### PR Lifecycle -### Requesting Review +Follow these steps in order from start to submission: -Once your PR is ready, assign reviewers and mark it as "ready to review." But -before that, report the time you have spent on it. +1. **Open a [draft PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests)** + right away when you start working on a Problem. +1. **[Link the PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)** + to the corresponding Problem issue using a closing keyword. +1. **Assign yourself** so it is clear who is working on it. +1. **Resolve all CI checks** — PRs with failing checks will be rejected. +1. **Report your time** spent across all stages: planning (40%), implementation, + and QA (20–30%). Open the PR early so time tracking starts from the + beginning, including investigation. +1. **Assign at least one reviewer** (team or individual). +1. **Mark as ready for review** only once all steps above are complete. > [!NOTE] -> When contributing, it's essential to report time accurately, including all -> stages of development (planning, implementation, QA). We encourage opening a -> PR at the start of your work, even during the planning or investigation phase. -> Programming and designing isn't just about writing code or creating designs; -> it also involves planning (40%) and QA (20-30%). +> Do not merge without an approved review. ### Review Process @@ -377,7 +305,7 @@ keeps moving. #### Code Quality Aim for solutions that work correctly 99.9% of the time. Be independent and -thorough in your QA - reviewers are not QA team members but are there for a +thorough in your QA — reviewers are not QA team members but are there for a final safety check. We expect contributors to deliver bug-free software, understanding that perfection is an ideal. Stand firm in your solutions and avoid unnecessary revisions based on subjective feedback. From db7dbde0f805537d79f7320c626a1f7ec67a2e80 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 15:16:07 +0800 Subject: [PATCH 11/18] docs: view better structure --- docs/CONTRIBUTING.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 92ed3d9..9b9e8e0 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -7,7 +7,7 @@ Please read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community approachable and respectful. > [!TIP] -> You can use [Wizard Browser Extension][1] to simplify some of the workflows +> You can use [Wizard Github App][2] and [Wizard Browser Extension][1] to simplify some of the workflows > described in these Guidelines. ## Table of Contents @@ -313,3 +313,4 @@ avoid unnecessary revisions based on subjective feedback. --- [1]: https://chromewebstore.google.com/detail/wizard-browser-extension/gibcadmedmabfnfbolimcndljcopbhep +[2]: https://github.com/apps/holdex From b2b263eb01b0d51384341e822c691ea9e71ac7b6 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 15:21:12 +0800 Subject: [PATCH 12/18] docs: view better structure --- docs/PRINCIPLES.md | 45 --------------------------------------------- 1 file changed, 45 deletions(-) delete mode 100644 docs/PRINCIPLES.md diff --git a/docs/PRINCIPLES.md b/docs/PRINCIPLES.md deleted file mode 100644 index 9d3a067..0000000 --- a/docs/PRINCIPLES.md +++ /dev/null @@ -1,45 +0,0 @@ -# Our Principles - -**We build great things together—fast, smart, and with full ownership.** - -## The 6 Rules We Live By - -1. **Start with the Goal** - Keep the big picture. Break it into clear problems. Solve one at a time. - -1. **Own It Like a Founder** - No one assigns tasks. You spot problems, claim them, and deliver results. - -1. **Ship Daily, Small & Often** - No task >4 hours. Finish, push, move on. Momentum beats perfection. - -1. **Respect Time—Yours & Others** - One team sync/week. Work async. No meetings unless needed. - -1. **Wear Many Hats** - Code, design, test, write, explore. We grow by doing. - -1. **Figure It Out** - Research. Read. Ask. Learn fast. No waiting for instructions. - ---- - -## Do This | Not That - -| ✅ **Do** | ❌ **Don’t** | -| ------------------------- | ----------------------- | -| Solve what moves the goal | Work on low-value tasks | -| Own it end-to-end | Pass the buck | -| Test your work | Expect others to QA | -| Leave clear updates | Vanish without trace | - ---- - -## ⏰ Core Hours - -**2–6 PM HKT** — Be online. Rest is flexible. - ---- - -**Be bold. Be fast. Be kind.** -That’s how we win. From 77a4742269171974ee5919c0376a5e894e7f27a4 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 15:22:39 +0800 Subject: [PATCH 13/18] docs: view better structure --- docs/CONTRIBUTING.md | 29 ++++++++++++++++------------- 1 file changed, 16 insertions(+), 13 deletions(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 9b9e8e0..9aba1f2 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -7,8 +7,8 @@ Please read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community approachable and respectful. > [!TIP] -> You can use [Wizard Github App][2] and [Wizard Browser Extension][1] to simplify some of the workflows -> described in these Guidelines. +> You can use [Wizard Github App][2] and [Wizard Browser Extension][1] to +> simplify some of the workflows described in these Guidelines. ## Table of Contents @@ -73,8 +73,8 @@ Sometimes, a Goal already has a few identified problems, but not always. > clear. > > The statement must read as a **job story**: describe what the specific user -> **can't do** or what is broken for them. Ask: _"What can [user] not do -> because of this problem?"_ +> **can't do** or what is broken for them. Ask: +> _"What can [user] not do because of this problem?"_ | **Good** ✅ | **Bad** ❌ | **Why?** | | ---------------------------------------------- | -------------------------------------------- | ------------------------------ | @@ -108,7 +108,8 @@ Direct discussions to the appropriate channel at all times: - **Spec document** — clarifications about Goal scope or business context - **Problem issues** — tracking obstacles that prevent achieving the Goal -- **Goal issues** — linking Specs, tracking Problems, and monitoring progress only +- **Goal issues** — linking Specs, tracking Problems, and monitoring progress + only > [!IMPORTANT] > Do not post Problem status updates, PR notifications, or progress updates in @@ -126,10 +127,9 @@ issue so the dependency is visible. ### Referencing issues and PRs -When referencing issues or pull requests, use a list -item format to enable automatic title rendering and improve readability. This -ensures that GitHub automatically expands the reference to show the issue/PR -title. +When referencing issues or pull requests, use a list item format to enable +automatic title rendering and improve readability. This ensures that GitHub +automatically expands the reference to show the issue/PR title. **Correct** — use a list item: @@ -212,8 +212,9 @@ PR names must be: | `fix(sdk): mute sound` | `Fix: add file to mute sound` | Technical details | | `test(api): open door` | `Feat: modified door function` | Vague, past tense | -A feature isn't a button, toggle, or handler — it's **what the user gains from -it**. Ask _"What will users be able to do?"_ not _"What am I building?"_ +A feature isn't a button, toggle, or handler — it's +**what the user gains from it**. Ask _"What will users be able to do?"_ not +_"What am I building?"_ 1. **Replace UI labels with actions**: Wrong: "Add dropdown for filters" → Correct: "Filter search results by category" @@ -268,9 +269,11 @@ If there isn't an existing DESIGN.md file, create one and link it from README.md Follow these steps in order from start to submission: -1. **Open a [draft PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests)** +1. **Open a [draft + PR](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#draft-pull-requests)** right away when you start working on a Problem. -1. **[Link the PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)** +1. **[Link the + PR](https://docs.github.com/en/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword)** to the corresponding Problem issue using a closing keyword. 1. **Assign yourself** so it is clear who is working on it. 1. **Resolve all CI checks** — PRs with failing checks will be rejected. From 024123dc0ca121a4b0f672deb351d9285204dc52 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 16:05:50 +0800 Subject: [PATCH 14/18] docs: refer contributor or business --- .claude/worktrees/practical-babbage | 1 + docs/CONTRIBUTING.md | 45 +++++++++++++++++++++++++++-- 2 files changed, 44 insertions(+), 2 deletions(-) create mode 160000 .claude/worktrees/practical-babbage diff --git a/.claude/worktrees/practical-babbage b/.claude/worktrees/practical-babbage new file mode 160000 index 0000000..77a4742 --- /dev/null +++ b/.claude/worktrees/practical-babbage @@ -0,0 +1 @@ +Subproject commit 77a4742269171974ee5919c0376a5e894e7f27a4 diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 9aba1f2..85833c6 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -23,6 +23,7 @@ approachable and respectful. - [Naming](#naming) - [PR Lifecycle](#pr-lifecycle) - [Review Process](#review-process) +- [Referral Program](#referral-program) ## Getting started @@ -42,6 +43,11 @@ There are three core contribution pillars: Understanding the Goal and its business context is crucial for successful contribution. +To find a Goal to work on, browse GitHub Issues in the relevant repository and +filter for issues with the `Goal:` prefix. Prioritize issues based on their +impact and urgency. If you are unsure which Goal to choose, please consult +your lead. Pick one that matches your skills, then proceed with the steps below. + As soon as you get involved, you must: 1. assign yourself to the Goal issue. @@ -166,6 +172,8 @@ Before marking your PR as ready for review, confirm: - [ ] At least one reviewer is assigned - [ ] Time is reported - [ ] PR title follows `type(scope): action` naming convention +- [ ] Preview link is included (if applicable) +- [ ] README is updated to reflect any functional changes ### Commit Signature Verification @@ -194,6 +202,10 @@ We usually reject and close PRs which do not have activity for the last 24 hours, unless there is a clear comment explaining the reason why that PR is stalled. +When introducing functional changes, cross-check the README and update it in +the same PR. If your change affects anything documented there — setup steps, +environment requirements, file references — the README must stay in sync. + ### Naming > [!NOTE] @@ -281,6 +293,9 @@ Follow these steps in order from start to submission: and QA (20–30%). Open the PR early so time tracking starts from the beginning, including investigation. 1. **Assign at least one reviewer** (team or individual). +1. **Include a preview link** — if your changes are visually verifiable (UI, + design, or any deployable artifact), add a link to the deployed preview or + prototype in the PR description. 1. **Mark as ready for review** only once all steps above are complete. > [!NOTE] @@ -290,14 +305,20 @@ Follow these steps in order from start to submission: #### Giving a Review -Use **Request Changes** (reject) only for objective problems: +If a PR is not ready to merge, you **must** use **Request Changes** (reject). +Do not leave a plain comment when rejection is warranted — comments do not +block merging, are not recorded as rejections, and prevent the author from +re-requesting a review. + +Use **Request Changes** (reject) for objective problems: - PR doesn't solve the stated problem. - A bug is introduced. - Code style is inconsistent. - Required guidelines are violated. -Use **Comment** for optional improvements or suggestions. +Use **Comment** for optional improvements or suggestions that should not block +the PR. #### Scout Approach @@ -313,6 +334,26 @@ final safety check. We expect contributors to deliver bug-free software, understanding that perfection is an ideal. Stand firm in your solutions and avoid unnecessary revisions based on subjective feedback. +## Referral Program + +Referrals are accepted for two types: + +- **Contributors** — someone you refer who joins and stays active for more than + 3 months. +- **Business** — a client or partner you refer who engages with us. + +In both cases, for a referral to be registered, the applicant or prospect must +name you as the referral at the time of their application or first contact. +Referrals claimed after the fact will not be counted. + +Once the eligibility conditions are met, reach out to your lead to claim the +reward. + +> [!NOTE] +> This referral program applies unless there is a separate commercial +> engagement between Holdex and the contributor, in which case referral terms +> are governed by that agreement instead. + --- [1]: https://chromewebstore.google.com/detail/wizard-browser-extension/gibcadmedmabfnfbolimcndljcopbhep From ecd5391fd97d20838208d02b2e6ebedd9d541ecf Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 16:19:43 +0800 Subject: [PATCH 15/18] docs: view better structure --- docs/CONTRIBUTING.md | 39 ++++++++++++++++++--------------------- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 85833c6..628be94 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -65,22 +65,18 @@ permissions) and an ETA. ### Problem -Once the Goal is clear, you must identify what stops you from achieving it. -Anything that is stopping you - is a "Problem". A typical question to ask is: -"Why is this Goal not achieved and what is the Problem?". - -Sometimes, a Goal already has a few identified problems, but not always. +Once a Goal is clear, you must identify what prevents its achievement. +Anything that acts as a barrier is considered a "Problem." Ask yourself: +"Why is this Goal not achieved, and what specifically is the problem?" > [!NOTE] -> Once a Problem is identified, we report it as a -> [GitHub Issue](https://docs.github.com/en/issues) with the following naming -> pattern: `Problem: [statement]`. We're counting on our contributors to -> identify problems. Keep a Problem name short (under 65 chars) and crystal -> clear. -> -> The statement must read as a **job story**: describe what the specific user -> **can't do** or what is broken for them. Ask: -> _"What can [user] not do because of this problem?"_ +> Report each Problem as a [GitHub Issue](https://docs.github.com/en/issues) +> using the naming pattern: `Problem: [statement]`. Keep the name short +> (under 65 characters) and crystal clear. + +The statement must be a **job story** — describe what a specific user **cannot +do** or what is broken for them. Ask: _"What can [user] not do because of this +problem?"_ | **Good** ✅ | **Bad** ❌ | **Why?** | | ---------------------------------------------- | -------------------------------------------- | ------------------------------ | @@ -88,10 +84,10 @@ Sometimes, a Goal already has a few identified problems, but not always. | `users can't submit a form without refreshing` | `form submission issue` | Vague, no actor or action | | `admins can't export reports as CSV` | `CSV export missing` | No subject, not a job story | -Make sure each Problem issue is interlinked with its Goal issue: +Ensure each Problem issue is properly interlinked with its parent Goal issue: -- add a Problem issue link into the Goal description -- add a Goal issue link to the Problem description +- Add the Problem issue link to the Goal description. +- Add the Goal issue link to the Problem description. ### Solution @@ -182,19 +178,20 @@ sign their commits. For detailed instructions on why and how to sign your commits refer to [GitHub's documentation on commit signature verification](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification). -> [!Note] We recommend signing commits using an +> [!NOTE] +> We recommend signing commits using an > [SSH key](https://docs.github.com/en/authentication/managing-commit-signature-verification/about-commit-signature-verification#ssh-commit-signature-verification). > Ensure your Git version supports SSH signature verification (Git 2.34 or > later). ### Scoping -> [!NOTE] +> [!TIP] > Here's a [good resource](https://youtu.be/bmSAYlu0NcY?si=2lLQeY1PGCY9tcvX) on software design philosophy. When planning the scope of work, make sure you [keep PRs small](https://artsy.github.io/blog/2021/03/09/strategies-for-small-focused-pull-requests/). -You must be able to complete your PR within 3-4 hours. +You must be able to complete your PR within 3–4 hours. If the solution requires more time, then decompose it into smaller independent PRs. In case your smaller PRs can't be used on production, use feature flags. @@ -349,7 +346,7 @@ Referrals claimed after the fact will not be counted. Once the eligibility conditions are met, reach out to your lead to claim the reward. -> [!NOTE] +> [!IMPORTANT] > This referral program applies unless there is a separate commercial > engagement between Holdex and the contributor, in which case referral terms > are governed by that agreement instead. From ddb253c6667be569da8956504e6266fad3c96652 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 16:23:20 +0800 Subject: [PATCH 16/18] docs: view better structure --- docs/CONTRIBUTING.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 628be94..15e0f85 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -157,7 +157,7 @@ All PRs, whether for source code, design, or copy changes, must comply with the following requirements. > [!WARNING] -> PRs that do not correspond to the following criteria are usually rejected. +> PRs that do not correspond to the following criteria will be rejected. Before marking your PR as ready for review, confirm: @@ -295,7 +295,7 @@ Follow these steps in order from start to submission: prototype in the PR description. 1. **Mark as ready for review** only once all steps above are complete. -> [!NOTE] +> [!WARNING] > Do not merge without an approved review. ### Review Process From 088a0f9b735fb579f5b04b9f9ec6af880b8a9389 Mon Sep 17 00:00:00 2001 From: Vadim Zolotokrylin Date: Wed, 8 Apr 2026 16:27:39 +0800 Subject: [PATCH 17/18] docs: view better structure --- README.md | 1 + docs/CONTRIBUTING.md | 21 --------------------- docs/REFERRAL.md | 19 +++++++++++++++++++ 3 files changed, 20 insertions(+), 21 deletions(-) create mode 100644 docs/REFERRAL.md diff --git a/README.md b/README.md index d66dbe4..b6b4ff0 100644 --- a/README.md +++ b/README.md @@ -17,6 +17,7 @@ Align with: - [Code of Conduct](./docs/CODE_OF_CONDUCT.md) - [Leave Policy](./docs/LEAVE_POLICY.md) - [Compensation Guide](./docs/COMPENSATION.md) +- [Referral Program](./docs/REFERRAL.md) Subscribe to repository notifications to stay updated with frequent fixes and improvements. diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index 15e0f85..b691c04 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -23,7 +23,6 @@ approachable and respectful. - [Naming](#naming) - [PR Lifecycle](#pr-lifecycle) - [Review Process](#review-process) -- [Referral Program](#referral-program) ## Getting started @@ -331,26 +330,6 @@ final safety check. We expect contributors to deliver bug-free software, understanding that perfection is an ideal. Stand firm in your solutions and avoid unnecessary revisions based on subjective feedback. -## Referral Program - -Referrals are accepted for two types: - -- **Contributors** — someone you refer who joins and stays active for more than - 3 months. -- **Business** — a client or partner you refer who engages with us. - -In both cases, for a referral to be registered, the applicant or prospect must -name you as the referral at the time of their application or first contact. -Referrals claimed after the fact will not be counted. - -Once the eligibility conditions are met, reach out to your lead to claim the -reward. - -> [!IMPORTANT] -> This referral program applies unless there is a separate commercial -> engagement between Holdex and the contributor, in which case referral terms -> are governed by that agreement instead. - --- [1]: https://chromewebstore.google.com/detail/wizard-browser-extension/gibcadmedmabfnfbolimcndljcopbhep diff --git a/docs/REFERRAL.md b/docs/REFERRAL.md new file mode 100644 index 0000000..9256a80 --- /dev/null +++ b/docs/REFERRAL.md @@ -0,0 +1,19 @@ +# Referral Program + +Referrals are accepted for two types: + +- **Contributors** — someone you refer who joins and stays active for more than + 3 months. +- **Business** — a client or partner you refer who engages with us. + +In both cases, for a referral to be registered, the applicant or prospect must +name you as the referral at the time of their application or first contact. +Referrals claimed after the fact will not be counted. + +Once the eligibility conditions are met, reach out to your lead to claim the +reward. + +> [!IMPORTANT] +> This referral program applies unless there is a separate commercial +> engagement between Holdex and the contributor, in which case referral terms +> are governed by that agreement instead. From 7d5df89e22badff63bbd348f398eff8642af754f Mon Sep 17 00:00:00 2001 From: Vadim Date: Wed, 8 Apr 2026 16:28:59 +0800 Subject: [PATCH 18/18] Update docs/CONTRIBUTING.md Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> Signed-off-by: Vadim --- docs/CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/CONTRIBUTING.md b/docs/CONTRIBUTING.md index b691c04..4b9c114 100644 --- a/docs/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -7,7 +7,7 @@ Please read our [Code of Conduct](./CODE_OF_CONDUCT.md) to keep our community approachable and respectful. > [!TIP] -> You can use [Wizard Github App][2] and [Wizard Browser Extension][1] to +> You can use [Wizard GitHub App][2] and [Wizard Browser Extension][1] to > simplify some of the workflows described in these Guidelines. ## Table of Contents