diff --git a/.github/APPLICATION_SUCCESS.md b/.github/APPLICATION_SUCCESS.md deleted file mode 100644 index 453d92b..0000000 --- a/.github/APPLICATION_SUCCESS.md +++ /dev/null @@ -1,29 +0,0 @@ -# Application Submitted! 🙌 - -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. - -## What's next for me? -Begin your [Trial Period](./TRIAL.md) - -## Frequent questions - -### Why am I here? -GitHub is our primary tool for team collaboration. From business and down to engineering, we prefer keeping things simple - in a single place. Since you have applied to one of our positions, it only makes sense to keep our instructions, guidelines, and documents related to our job positions in GitHub. Our goal with time is to give you enough initial guidance so that you are fully prepared to join any of our projects. We hope you'll appreciate our efforts and enjoy this journey we've prepared ahead for you. - -### Why do I need to participate in the trial? -It's all about the team culture that we care about. Part of this team culture is the individual ability to figure things out, provide the right solutions, display initiative, be honest and transparent, take responsibility, care for details, ability to make the right calls, and much more. All of which can't be assessed unless we collaborate on something together. It's also a good opportunity for you to get the real feeling of working with us and see if it fits your style. We'll understand if it doesn't align with your values and you don't want to participate, just let us know. - -### How to participate in the trial? -Follow the steps outlined in our [short instruction](./TRIAL.md) and it will get you started. - -### Are we having an interview call? -Personal time is more precious. Instead of spending 1 hour of collective time on a "whiteboard" interview, we allow you to focus on what really matters. We usually don't have calls until official onboarding where you get to meet the founders and other team members. - -### What benefits do you offer? -1. **We are 100% remote**. Work from anywhere around the world async and ad-hoc. -1. **Salary in stablecoins**. As early adopters, we are very supportive of blockchain payroll. It is negotiable though. -1. **[PTO](./LEAVE_POLICY.md) and Holidays leave**. - diff --git a/.github/CODE_OF_CONDUCT.md b/.github/CODE_OF_CONDUCT.md deleted file mode 100644 index 6f8a1e6..0000000 --- a/.github/CODE_OF_CONDUCT.md +++ /dev/null @@ -1,16 +0,0 @@ -# Code of Conduct - -1. Make sure you are aligned with our Core Values. -2. 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. -3. Assign yourself to the Problem you are solving so others are aware of it. -4. Don’t use `@mention` when it is not crucial for the person to be notified. Use "reactions" (likes) instead. -5. Leave updates daily to keep things transparent and simple for others. - -## Core Values - -- “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 thing to do, your efforts will be in vain. -- “Keep it Simple” – simplicity is a significant key to success. The most complicated skill is to be simple. -- “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 the success of our business is dependent on us. -- “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 goals to ensure that your actions are aligned. Identify areas of improvement constantly to streamline resources and enhance business efficacy. \ No newline at end of file diff --git a/.github/LEAVE_POLICY.md b/.github/LEAVE_POLICY.md deleted file mode 100644 index 5e66522..0000000 --- a/.github/LEAVE_POLICY.md +++ /dev/null @@ -1,59 +0,0 @@ -# Anual Leave Policy - -Every team member benefits from our standard "paid time off" allowance: -| | Leave Reason | Paid Time Off | -|--|--|--| -| 🎄 | Holidays | 3 days | -| đŸ€’ | Being sick | 7 days | -| đŸ–ïž | Personal | 4 days | - -The policy terms are: -1. paid time off can be requested only after 6 months of collaboration; -1. all requests should be submitted through GitHub issues 2 weeks before taking time off; otherwise, your request might be rejected; -1. any leaves outside of the PTO are unpaid; -1. The holidays are Christmas Day, New Year's Day, and Easter Day. If these Holidays are not part of your culture, let us know. We can make an exception for you. - -## FAQ - -
- - Will my unused Personal days carry over to the following year? - -
- Unused personal days can be carried over into the following year. However, we encourage you to get out of the office and refresh. -
- -
- - Will I be compensated for unused days if I stop collaborating with you? - -
- Yes. You will receive compensation for any unused Personal days.
- Sick days and holidays will not be reimbursed.
-
- Formula: compensation = monthlyRate * (unusedPtoDays / totalPtoDays)_ -
- -
- - If I take unpaid leave within the first six months, will my wages be reduced? - -
- Yes, your wages will be reduced accordingly. -
- -
- - How is the reduction calculated? - -
- The deduction is calculated with the following formula:
- x = s/a * b
- Where:
- -
diff --git a/.github/TRIAL.md b/.github/TRIAL.md deleted file mode 100644 index 6aef1d3..0000000 --- a/.github/TRIAL.md +++ /dev/null @@ -1,45 +0,0 @@ -# Trial Period -When hiring, we look for specific qualities and skills in our candidates that 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: -1. lead engineers contribute to defining business Goals along with the Partners and Stakeholders -2. every engineer, who is assigned to the Goal, identifies the Problems stopping us from achieving the Goal -3. every engineer assigns themself one Problem at a time and proposes a solution in the form of PR. - -The main idea is to make the right contributions to achieve the Goals. All this process happens async, without making blockers or individuals being spoon-fed with new assignments. This is what we are expecting from you during your trial period too. For more details please carefully read Developer Guidelines. - -## How the Trial works -Once onboarded in the repository, you won't receive a narrow Problem to resolve. Instead, you will be assigned to a Goal where you will join forces with our team members and be responsible for contributing to the Goal. We'll expect you to define a new Problem and resolve it, or pick from the ones reported by your peers. Our [Developer Guidelines](./CONTRIBUTING.md) will help you navigate your trial and follow our team's principles. - -## Get started -1. Align yourself with our [Developer Guidelines](./CONTRIBUTING.md). Not following them will result in your contribution being rejected. -1. Open a [PRIVATE THREAD](https://github.com/holdex/developers/blob/main/.github/private-thread-instruction-min.png) discussion in our [Discord](https://discord.gg/cHxnURgGgk) and ping there Mark (@MarkCurchin). -1. Join one of the repositories presented below or request an access. -1. Align with the Goal you will get assigned to. -1. Create a Problem (issue) or assign yourself to an existing one. -1. Describe shortly your solution and provide an ETA in the comment section. -1. Communicate in your Discord private thread your intentions to resolve a problem and paste the GitHub link. -1. Begin solving and follow our [Engineering Guidelines](./CONTRIBUTING.md). -1. Once complete, request review according to our [Engineering Guidelines](./CONTRIBUTING.md) and ping Mark in your Discord private thread. - -> [!TIP] -> Repositories where you can begin your trial: -> - **HTML/CSS and JavaScript:** https://github.com/holdex/holdex-venture-studio -> - **Python:** https://github.com/truflation/truflation -> - **Full-stack web3:** [for access - get in touch](https://discord.gg/cHxnURgGgk) -> - **Solidity:** [for access - get in touch](https://discord.gg/cHxnURgGgk) -> - **Go:** [for access - get in touch](https://discord.gg/cHxnURgGgk) -> - **Design:** [for access - get in touch](https://discord.gg/cHxnURgGgk) -> - **DevOps:** [for access - get in touch](https://discord.gg/cHxnURgGgk) - -## I don't have access to open a PR in the repository. What do I do? -Fork the repository and create a PR using a [Fork Strategy](https://gist.github.com/Chaser324/ce0505fbed06b947d962). - -## What is the trial duration? -The trial period can take from 1 to 5 days, which can be extended if necessary. If the PR is kept stale for a long period without previous notice, it will be closed automatically. - -## Can I get a different task on trial? -No. - -## Do I get hired after the trial? -After the trial, your results will undergo a collective verification and assessment from a board of responsible members. Since we will be in touch, we will communicate to you personally the results of the trial and the next steps awaiting. diff --git a/.github/workflows/markdown_lint.yml b/.github/workflows/markdown_lint.yml new file mode 100644 index 0000000..93caa32 --- /dev/null +++ b/.github/workflows/markdown_lint.yml @@ -0,0 +1,28 @@ +name: Markdown Lint + +on: + push: + 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] + +jobs: + lint: + 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.0.185/rumdl-v0.0.185-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/ + + # Ensure the binary is executable and in the PATH + chmod +x /usr/local/bin/rumdl + - name: Lint Markdown + run: rumdl check --output-format github . diff --git a/.rumdl.toml b/.rumdl.toml new file mode 100644 index 0000000..aafc2f0 --- /dev/null +++ b/.rumdl.toml @@ -0,0 +1,75 @@ +# rumdl configuration file + +# Global configuration options +[global] +# List of rules to disable (uncomment and modify as needed) +# disable = ["MD013", "MD033"] + +# List of rules to enable exclusively (if provided, only these rules will run) +# enable = ["MD001", "MD003", "MD004"] + +# List of file/directory patterns to include for linting (if provided, only these will be linted) +# include = [ +# "docs/*.md", +# "src/**/*.md", +# "README.md" +# ] + +# List of file/directory patterns to exclude from linting +exclude = [ + # Common directories to exclude + ".git", + # ".github", + "node_modules", + "vendor", + "dist", + "build", + + # Specific files or patterns + # "CHANGELOG.md", + # "LICENSE.md", +] + +# Respect .gitignore files when scanning directories (default: true) +respect-gitignore = true + +# Markdown flavor/dialect (uncomment to enable) +# Options: mkdocs, gfm, commonmark +# flavor = "mkdocs" + +# Rule-specific configurations (uncomment and modify as needed) + +# [MD003] +# style = "atx" # Heading style (atx, atx_closed, setext) + +# [MD004] +# style = "asterisk" # Unordered list style (asterisk, plus, dash, consistent) + +# [MD007] +# indent = 4 # Unordered list indentation + +[MD013] +line-length = 80 # Line length +code-blocks = false # Exclude code blocks from line length check +tables = false # Exclude tables from line length check +headings = true # Include headings in line length check +reflow = true # Enable automatic line wrapping (required for --fix) +reflow-mode = "normalize" # Reflow mode: "default", "normalize", or "sentence-per-line" (default: "default") + + + +# [MD044] +# names = ["rumdl", "Markdown", "GitHub"] # Proper names that should be capitalized correctly +# code-blocks = false # Check code blocks for proper names (default: false, skips code blocks) + +[MD029] +# Style options: +# - "one" or "one-one": All items numbered "1." (easiest maintenance) +# - "ordered": Sequential numbering (1, 2, 3...) +# - "ordered0": Zero-based sequential (0, 1, 2...) +# - "one-or-ordered": Auto-detect per list (either all-ones OR sequential) +# - "consistent": Document-wide consistency - uses most common style across all lists +style = "one" # Default - matches markdownlint behavior + +[MD033] +allowed-elements = ["details", "summary"] # List of allowed HTML tags (default: none) diff --git a/README.md b/README.md index a3302f9..5009fc1 100644 --- a/README.md +++ b/README.md @@ -1,19 +1,23 @@ # Developer Guidelines -Welcome to our Developer Guidelines! -Your journey to shape the future starts here. +Welcome to our Developer Guidelines! Your journey to shape the future of DeFi +starts here. ## For Developers -_Developers_ are everyone creating value—business developers, designers, engineers, marketers, and beyond. We build businesses, products, partnerships, customer relationships, processes, and delivery methods, crafting the future we envision. +_Developers_ are everyone creating value—business developers, designers, +engineers, marketers, and beyond. We build businesses, products, partnerships, +customer relationships, processes, and delivery methods, crafting the future we +envision. Align with: -- [Principles](./.github/PRINCIPLES.md) -- [Contributing Guidelines](./.github/CONTRIBUTING.md) -- [Advocacy Guidelines](./.github/ADVOCACY.md) -- [Code of Conduct](./.github/CODE_OF_CONDUCT.md) -- [Sick Leave Policy](./.github/LEAVE_POLICY.md) -- [Compensation Guide](./.github/COMPENSATION.md) +- [Principles](./docs/PRINCIPLES.md) +- [Contributing Guidelines](./docs/CONTRIBUTING.md) +- [Advocacy Guidelines](./docs/ADVOCACY.md) +- [Code of Conduct](./docs/CODE_OF_CONDUCT.md) +- [Leave Policy](./docs/LEAVE_POLICY.md) +- [Compensation Guide](./docs/COMPENSATION.md) -Subscribe to repository notifications to stay updated with frequent fixes and improvements. +Subscribe to repository notifications to stay updated with frequent fixes and +improvements. diff --git a/.github/ADVOCACY.md b/docs/ADVOCACY.md similarity index 86% rename from .github/ADVOCACY.md rename to docs/ADVOCACY.md index d4cff96..0f581a6 100644 --- a/.github/ADVOCACY.md +++ b/docs/ADVOCACY.md @@ -1,17 +1,21 @@ # Advocacy Guidelines -If you are a Holdex team member, we expect you to advocate for Holdex, -its mission, and its values. This includes: +If you are a Holdex team member, we expect you to advocate for Holdex, its +mission, and its values. This includes: -- Participate in community events and activities that align with Holdex's mission and values. -- Share Holdex-related content on social media platforms, including LinkedIn and Twitter. -- Represent Holdex professionally and ethically, and to uphold the company's code of conduct at all times. +- Participate in community events and activities that align with Holdex's + mission and values. +- Share Holdex-related content on social media platforms, including LinkedIn and + Twitter. +- Represent Holdex professionally and ethically, and to uphold the company's + code of conduct at all times. ## Social Media Presence Your Personal Social Media Presence: -- Create and maintain a professional LinkedIn profile that showcases your work at Holdex. +- Create and maintain a professional LinkedIn profile that showcases your work + at Holdex. - Use Twitter to share Holdex-related news, updates, and insights. - Engage with Holdex's community on social media platforms, responding to comments and questions. @@ -23,8 +27,8 @@ Twitter) profiles to reflect Holdex. ### GitHub Bio -You must exclusively promote Holdex during the period you being under Holdex contract, you should not include any mentions of other brands or any links other than Holdex-related links. - +While employed by Holdex, exclusively promote Holdex in your bio. Do not include +other brands or non-Holdex links.. | Github Profile Attributes | Acceptance Criteria | |---------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| @@ -38,12 +42,12 @@ You must exclusively promote Holdex during the period you being under Holdex con | Social link 2 – Website | | | Social link 3 – LinkedIn | | | Pinned Repositories | Trial | -| Overview (not urgent) | Guidelines
Create a ‘README.md’ file in public self-repo that states: | - +| Overview | Create a ‘README.md’ file in public self-repo that states: role at Holdex, what you do & what you love about Holdex, link to Holdex website and GitHub organization profile. | ### LinkedIn Profile -Must mention Holdex in the ‘Experiences’ tab & place it as the recent / current role. +Must mention Holdex in the ‘Experiences’ tab & place it as the recent / current +role. Mandatory `Experience` description: > Holdex is 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. @@ -52,4 +56,4 @@ Mandatory `Experience` description: - Must mention your role @HoldexIo within the profile description. - Link to Holdex website / portfolio. -- Location: localhost \ No newline at end of file +- Location: localhost diff --git a/docs/APPLICATION_SUCCESS.md b/docs/APPLICATION_SUCCESS.md new file mode 100644 index 0000000..df952c8 --- /dev/null +++ b/docs/APPLICATION_SUCCESS.md @@ -0,0 +1,52 @@ +# Application Submitted! 🙌 + +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. + +## What's next for me? + +Begin your [Trial Period](./TRIAL.md) + +## Frequent questions + +### Why am I here? + +GitHub is our primary tool for team collaboration. From business and down to +engineering, we prefer keeping things simple - in a single place. Since you have +applied to one of our positions, it only makes sense to keep our instructions, +guidelines, and documents related to our job positions in GitHub. Our goal with +time is to give you enough initial guidance so that you are fully prepared to +join any of our projects. We hope you'll appreciate our efforts and enjoy this +journey we've prepared ahead for you. + +### Why do I need to participate in the trial? + +It's all about the team culture that we care about. Part of this team culture is +the individual ability to figure things out, provide the right solutions, +display initiative, be honest and transparent, take responsibility, care for +details, ability to make the right calls, and much more. All of which can't be +assessed unless we collaborate on something together. It's also a good +opportunity for you to get the real feeling of working with us and see if it +fits your style. We'll understand if it doesn't align with your values and you +don't want to participate, just let us know. + +### How to participate in the trial? + +Follow the steps outlined in our [short instruction](./TRIAL.md) and it will get +you started. + +### Are we having an interview call? + +Personal time is more precious. Instead of spending 1 hour of collective time on +a "whiteboard" interview, we allow you to focus on what really matters. We +usually don't have calls until official onboarding where you get to meet the +founders and other team members. + +### What benefits do you offer? + +1. **We are 100% remote**. Work from anywhere around the world async and ad-hoc. +1. **Salary in stablecoins**. As early adopters, we are very supportive of + blockchain payroll. It is negotiable though. +1. **[PTO](./LEAVE_POLICY.md) and Holidays leave**. diff --git a/docs/CODE_OF_CONDUCT.md b/docs/CODE_OF_CONDUCT.md new file mode 100644 index 0000000..c5207ce --- /dev/null +++ b/docs/CODE_OF_CONDUCT.md @@ -0,0 +1,31 @@ +# 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. Don’t use `@mention` when it is not crucial for the person to be notified. + Use "reactions" (likes) instead. +1. Leave updates daily to keep things transparent and simple for others. + +## Core Values + +- “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 thing + to do, your efforts will be in vain. +- “Keep it Simple” – simplicity is a significant key to success. The most + complicated skill is to be simple. +- “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 the success of our business is dependent on us. +- “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 + goals to ensure that your actions are aligned. Identify areas of improvement + constantly to streamline resources and enhance business efficacy. diff --git a/.github/COMPENSATION.md b/docs/COMPENSATION.md similarity index 93% rename from .github/COMPENSATION.md rename to docs/COMPENSATION.md index 9dce8df..24aafc8 100644 --- a/.github/COMPENSATION.md +++ b/docs/COMPENSATION.md @@ -1,12 +1,15 @@ # Compensation Guide -**Goal:** Reward impact, not titles or location. Pay based on merit—what you deliver independently. +**Goal:** Reward impact, not titles or location. Pay based on merit—what you +deliver independently. > Open roles: [holdex.io/c/jobs](https://holdex.io/c/jobs) | Mission: [holdex.io/about](https://holdex.io/about) ## Core Rules -1. **Clear incentives** — Same job, same level = same pay. More results = more rewards. -2. **Simple framework** — Consistent rules for growth. + +1. **Clear incentives** — Same job, same level = same pay. More results = more + rewards. +1. **Simple framework** — Consistent rules for growth. ## Levels & Core Skills diff --git a/.github/CONTRIBUTING.md b/docs/CONTRIBUTING.md similarity index 66% rename from .github/CONTRIBUTING.md rename to docs/CONTRIBUTING.md index f29730a..10defb0 100644 --- a/.github/CONTRIBUTING.md +++ b/docs/CONTRIBUTING.md @@ -1,10 +1,11 @@ # Contributing Guidelines -Thank you for your interest in contributing to our project! -Your accepted contributions will be reflected in our repositories and related websites. +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. -Also, if you are a permanent contributor, read our [Principles](./PRINCIPLES.md). +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). > [!TIP] > You can use [GitHub Wizard](https://chromewebstore.google.com/detail/github-wizard/gibcadmedmabfnfbolimcndljcopbhep?) Chrome extension to simplify some of the workflows described in these Guidelines. @@ -22,7 +23,8 @@ There are three core contribution pillars: ### Goal -Understanding the Goal and its business context is crucial for successful contribution. +Understanding the Goal and its business context is crucial for successful +contribution. As soon as you get involved, you must: @@ -30,7 +32,8 @@ As soon as you get involved, you must: 1. assess progress and outstanding Problems and 1. provide an estimated time of achieving (ETA) the Goal. -Each Goal description must include Specs (a Google Document with commenting permissions) and an ETA. +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]`. @@ -38,23 +41,29 @@ Each Goal description must include Specs (a Google Document with commenting perm #### Communication within Goal issues -To maintain clarity and efficiency, discussions should be directed to the appropriate channels: +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 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. +- **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. -2. If there isn't, ask for clarification in the Spec document. -3. If necessary, create a new Problem issue and discuss it there. +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. +Avoid extended discussions in Goal issues. Instead, move conversations to the +relevant Spec document or Problem issue. ### 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?". +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. @@ -67,21 +76,27 @@ Make sure each Problem issue is interlinked with it's 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. +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. ### Solution 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 solution from the contributor. +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). ### Referencing -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. +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 @@ -109,17 +124,20 @@ 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 +## 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 our +PR Requirements. > [!WARNING] > PRs that do not correspond to the following criteria are usually rejected. ## Commit Signature Verification -For the security and integrity of our project, we require all contributors to 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). +For the security and integrity of our project, we require all contributors to +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). @@ -129,18 +147,25 @@ For detailed instructions on why and how to sign your commits refer to [GitHub's > [!NOTE] > 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. -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. +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. +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. -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. +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 -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. +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. The required checks are as follows: -``` +```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. @@ -152,18 +177,24 @@ The required checks are as follows: ## Drafting When starting to work on a Problem, you must: -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. -2. [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). -3. Before marking your PR as ready for review, assign **at least one reviewer** (team or individual). Do not merge without approved review. + +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. Before marking your PR as ready for review, assign **at least one reviewer** + (team or individual). Do not merge without approved review. ### 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` +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` Structure the design file with the following markup: -``` +```text ## Feature - [/page](https://figma.com/your-design-file-url) - ./page/{params} @@ -171,18 +202,20 @@ 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. +- **`[...]`** - 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. +- Indentation in the list represents the tree structure or hierarchy, showing + how components or features are nested or related. Example: -``` +```text ## Credit Vaults - [/lending](https://figma.com/your-design-file-url) - ./vaults/{poolAddr} @@ -204,10 +237,10 @@ If there isn't an existing DESIGN.md file: PR names must be: 1. **User-focused**: Describe what users gain, not technical implementation -2. **Follow [Conventional Commits](https://www.conventionalcommits.org)** -3. **Clear & simple** (present tense, action-oriented) +1. **Follow [Conventional Commits](https://www.conventionalcommits.org)** +1. **Clear & simple** (present tense, action-oriented) -### Example Comparison +### Example Comparison | **Good Examples** ✅ | **Bad Examples** ❌ | **Why?** | |-----------------------------|----------------------------------|---------| @@ -217,42 +250,56 @@ PR names must be: --- -### Key Principles +### 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 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. +#### 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**: đŸš« "Add dropdown for filters" → ✅ "Filter search results by category" -2. **Describe outcomes, not components**: đŸš« "Fix API error handling" → ✅ "Gracefully recover from connection errors" -3. **Use user action verbs**: *View, Play, Customize, Save*, etc. +#### 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" -### Before Submitting, Ask -1. Does it use `type(scope): action` format? -2. Could a non-technical user understand the benefit? -3. Is it in the present tense? -4. Does it focus on user capability (not code)? +1. **Use user action verbs**: *View, Play, Customize, Save*, etc. +### Before Submitting, Ask + +1. Does it use `type(scope): 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 -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. +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%). ### 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. +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 -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 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. +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 +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. diff --git a/docs/LEAVE_POLICY.md b/docs/LEAVE_POLICY.md new file mode 100644 index 0000000..8c6b057 --- /dev/null +++ b/docs/LEAVE_POLICY.md @@ -0,0 +1,64 @@ +# Leave Policy + +## Introduction + +Every team member (the Member) benefits from our "paid time off" allowance +described below or directly in the signed agreement. + +> [!IMPORTANT] +> In case of conflict between the signed agreement and scheduler, the signed +agreement terms prevail. + +## Year of Service + +The Year of Service is 365 calendar days starting from the date of signing the +agreement. + +## Minimum Service Period + +The Minimum Service Period is 6 months since the date of signing the agreement. + +## Leave Request + +### Submit Request + +2 weeks in advance (except for sick leave) the Member can submit the Leave +Request by creating a new GitHub issue in HR repository and providing: + +- start and end dates, and +- leave reason. + +### Approve or Reject Request + +HR Manager must consult with relevant Partner and approve leave request by +merging a pull request (PR) in PR Tracker repository or reject the Leave Request +by providing a detailed explanation and closing the issue with "Close as not +planned" option. + +## Leave Allowance + +### Paid Leave + +Members with the [Minimum Service Period](#minimum-service-period) are granted +14 days paid time off allowance (including holidays, sick leave, personal +leave). + +### Reimbursable Leave + +1. In case of the agreement termination after 9 up to 5 unused Paid Leave days + can be compensated based on the following formula: + + ```js + compensation = monthlyRate / 30 * reimbersableDays + ``` +1. Member can carry over 3 unused Paid Leave days into the following + [Year of Service](#year-of-service). + +#### Unpaid Leave + +The Unpaid Leave is deducted from the monthly payout. The deduction is +calculated with the following formula: + +```js +deduction = monthlyRate / 30 * requestedDaysOff +``` diff --git a/.github/PRINCIPLES.md b/docs/PRINCIPLES.md similarity index 86% rename from .github/PRINCIPLES.md rename to docs/PRINCIPLES.md index 6b9f799..941a2f9 100644 --- a/.github/PRINCIPLES.md +++ b/docs/PRINCIPLES.md @@ -7,19 +7,19 @@ 1. **Start with the Goal** Keep the big picture. Break it into clear problems. Solve one at a time. -2. **Own It Like a Founder** +1. **Own It Like a Founder** No one assigns tasks. You spot problems, claim them, and deliver results. -3. **Ship Daily, Small & Often** +1. **Ship Daily, Small & Often** No task >4 hours. Finish, push, move on. Momentum beats perfection. -4. **Respect Time—Yours & Others** +1. **Respect Time—Yours & Others** One team sync/week. Work async. No meetings unless needed. -5. **Wear Many Hats** +1. **Wear Many Hats** Code, design, test, write, explore. We grow by doing. -6. **Figure It Out** +1. **Figure It Out** Research. Read. Ask. Learn fast. No waiting for instructions. --- @@ -36,6 +36,7 @@ --- ## ⏰ Core Hours + **2–6 PM HKT** — Be online. Rest is flexible. --- diff --git a/docs/TRIAL.md b/docs/TRIAL.md new file mode 100644 index 0000000..6249013 --- /dev/null +++ b/docs/TRIAL.md @@ -0,0 +1,79 @@ +# Trial Period + +When hiring, we look for specific qualities and skills in our candidates that +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: + +1. lead engineers contribute to defining business Goals along with the Partners + and Stakeholders +1. every engineer, who is assigned to the Goal, identifies the Problems stopping + us from achieving the Goal +1. every engineer assigns themselves one Problem at a time and proposes a + solution in the form of PR. + +The main idea is to make the right contributions to achieve the Goals. All this +process happens async, without making blockers or individuals being spoon-fed +with new assignments. This is what we are expecting from you during your trial +period too. For more details please carefully read Developer Guidelines. + +## How the Trial works + +Once onboarded in the repository, you won't receive a narrow Problem to resolve. +Instead, you will be assigned to a Goal where you will join forces with our team +members and be responsible for contributing to the Goal. We'll expect you to +define a new Problem and resolve it, or pick from the ones reported by your +peers. Our [Developer Guidelines](./CONTRIBUTING.md) will help you navigate your +trial and follow our team's principles. + +## Get started + +1. Align yourself with our [Developer Guidelines](./CONTRIBUTING.md). Not + following them will result in your contribution being rejected. +1. Open a [PRIVATE THREAD](./private-thread-instruction-min.png) discussion in + our [Discord](https://discord.gg/cHxnURgGgk) and ping there Mark + (@MarkCurchin). +1. Join one of the repositories presented below or request an access. +1. Align with the Goal you will get assigned to. +1. Create a Problem (issue) or assign yourself to an existing one. +1. Describe shortly your solution and provide an ETA in the comment section. +1. Communicate in your Discord private thread your intentions to resolve a + problem and paste the GitHub link. +1. Begin solving and follow our [Engineering Guidelines](./CONTRIBUTING.md). +1. Once complete, request review according to our + [Engineering Guidelines](./CONTRIBUTING.md) and ping Mark in your Discord + private thread. + +> [!TIP] +> Repositories where you can begin your trial: +> +> - **HTML/CSS and JavaScript:** +> - **Python:** +> - **Full-stack web3:** [for access - get in touch](https://discord.gg/cHxnURgGgk) +> - **Solidity:** [for access - get in touch](https://discord.gg/cHxnURgGgk) +> - **Go:** [for access - get in touch](https://discord.gg/cHxnURgGgk) +> - **Design:** [for access - get in touch](https://discord.gg/cHxnURgGgk) +> - **DevOps:** [for access - get in touch](https://discord.gg/cHxnURgGgk) + +## I don't have access to open a PR in the repository. What do I do? + +Fork the repository and create a PR using a [Fork Strategy](https://gist.github.com/Chaser324/ce0505fbed06b947d962). + +## What is the trial duration? + +The trial period can take from 1 to 5 days, which can be extended if necessary. +If the PR is kept stale for a long period without previous notice, it will be +closed automatically. + +## Can I get a different task on trial? + +No. + +## Do I get hired after the trial? + +After the trial, your results will undergo a collective verification and +assessment from a board of responsible members. Since we will be in touch, we +will communicate to you personally the results of the trial and the next steps +awaiting. diff --git a/.github/private-thread-instruction-min.png b/docs/private-thread-instruction-min.png similarity index 100% rename from .github/private-thread-instruction-min.png rename to docs/private-thread-instruction-min.png diff --git a/package-lock.json b/package-lock.json new file mode 100644 index 0000000..3a64f47 --- /dev/null +++ b/package-lock.json @@ -0,0 +1,6 @@ +{ + "name": "developers", + "lockfileVersion": 3, + "requires": true, + "packages": {} +}