Contributing to VeriWorkly

First off, thank you for considering contributing to VeriWorkly! We are building a professional, privacy-first career ecosystem, and we value your help.

Getting Started

To ensure a smooth collaboration, please follow these steps to set up your contribution environment:

1. Star the Repository 🌟: Before getting started, please star the VeriWorkly Repository to show your support for this open-source project!

2. Claim an Issue 📋: Browse our open issues. Comment on the one you would like to work on and wait to be officially assigned by a maintainer. Please do not start coding or open a PR until you are officially assigned to the issue to avoid duplicate efforts.

   Issue Claiming & PR Policy

   • Priority for Rule Followers: If a contributor submits a PR without being assigned to the issue, and another contributor subsequently requests to claim/work on that issue following the correct procedure (commenting on the issue), priority will be given to the contributor who requested the claim. * No-Claim PR Procedure: If a PR is opened without an associated claim/assignment, maintainers will post a comment on the corresponding issue directing the author to claim it. * 7-Day Grace Period: Maintainers will wait for up to 7 days for the PR author to claim the issue. If the author fails to comment on the issue and claim it within 7 days, the PR may not be merged (even if the code is correct) and may be closed. * Claim Priority: If another contributor claims the issue during this grace period, the contributor who officially requested the claim will be considered first.

3. Fork the repository on GitHub by clicking the Fork button on the VeriWorkly Repository.

4. Clone your personal fork to your local machine:

   git clone https://github.com/YOUR_USERNAME/veriworkly.git
   cd veriworkly-resume

5. Configure Upstream Remote: Keep your fork in sync with the main project by tracking the original repository:

   git remote add upstream https://github.com/VeriWorkly/veriworkly.git

6. Sync with Upstream Master Branch: Before creating a branch, always ensure your local master branch is up to date:

   git checkout master
   git pull upstream master

7. Create a branch for your work, using our branching convention:

   git checkout -b feat/your-feature-name

Ways to Contribute

1. Code Contributions

We love new features and bug fixes! Check our GitHub Issues for "good first issue" labels if you're new to the project. Remember to claim the issue first!

2. Design & Templates

Our template system is designed to be extensible. If you're a designer or frontend developer, you can contribute new professional, ATS-optimized layouts.

3. Documentation

A great project needs great docs. If you find a typo, a confusing explanation, or want to add a new guide, please open a PR!

4. Bug Reports

If you find a bug, please open an issue with:

• A clear, descriptive title.
• Steps to reproduce the issue.
• Expected vs. actual behavior.
• Screenshots if applicable.

Development Workflow

Branching Policy

• master: Active development, integration, and production branch. All Pull Requests should be opened against master.

Branch Naming Convention

Your branch name should start with one of the following prefixes based on the work type:

• feat/feature-name: For new features.
• fix/bug-name: For bug fixes.
• docs/doc-update: For documentation changes.
• refactor/scope: For code refactoring without behavior changes.

Pre-commit Quality Verification

Before committing and pushing your changes, run automated scripts to ensure style guides and formats are preserved:

# Run typescript compilation and linter
npm run lint

# Format code automatically using Prettier
npm run format:write

# Run the test suite (Vitest / Playwright)
npm test

Pull Request Process

1. PR Title Naming Convention: PR titles must follow the format:

   [Type] [App/Component]: <lowercase description>

   • Type: [Fix], [Feature], [Refactor], [Docs], [Chore]
   • App/Component: [Studio], [Server], [Site], [UI], etc.
   • Example: [Fix] [Studio]: hide auth-only actions in account menu for anonymous users

2. Link the Issue: You must link the issue your PR addresses in the PR description using the hashtag format (e.g., Fixes #123 or Closes #123). This automatically links and closes the issue on merge.

3. Complete the PR Template & Checklist: Describe the modifications and check all boxes in the PR template by changing [ ] to [x]. PRs with empty or unchecked checklists will not be reviewed.

Technical Standards

Deep dive into our engineering practices and standards: