Contributing to Workspace Tasks

Thank you for your interest in contributing to Workspace Tasks! Whether you’re reporting a bug, requesting a feature, improving documentation, or submitting code changes, your contributions help make this extension better for everyone.

This guide will help you get started with contributing to the project.

📑 Table of Contents

Ways to Contribute

There are many ways you can contribute to Workspace Tasks:

🐛 Report Bugs

Found a bug? Help us fix it by creating a detailed bug report. See Writing Good Bug Reports.

✨ Request Features

Have an idea for a new feature or enhancement? We’d love to hear it! See Writing Good Feature Requests.

📝 Improve Documentation

Help make the documentation clearer, fix typos, or add examples. Documentation improvements are always welcome!

💻 Submit Code Changes

Fix bugs, implement features, or improve performance by submitting pull requests. See Contributing Code.

💬 Help Others

Answer questions in GitHub Discussions or help troubleshoot issues.

⭐ Spread the Word

Creating Good Issues

Look for an Existing Issue

Before creating a new issue, please search existing issues to see if the problem or request has already been reported.

If you find an existing issue that matches yours:

  • Add a 👍 reaction to show your support
  • Add relevant comments with additional context or information
  • Avoid “+1” comments—use reactions instead

Writing Good Bug Reports

When reporting a bug, please include:

Required Information:

  • xget Version - xget version
  • Command Executed - The exact command you ran, e.g., xget zyedidia/micro --tag nightly
  • Operating System - Windows, macOS, or Linux (including version)
  • Reproducible Steps - Clear numbered steps to reproduce the issue
    1. Open workspace with…
    2. Click on…
    3. See error…
  • Expected Behavior - What you expected to happen
  • Actual Behavior - What actually happened

Helpful Additions:

  • Screenshots or Recordings - Visual evidence of the issue
  • Error Messages - Copy and paste any error messages or stack traces
  • Configuration - Include relevant configuration files

Writing Good Feature Requests

When requesting a feature, please describe:

  • Problem Statement - What problem would this feature solve?
  • Proposed Solution - How should this feature work?
  • Use Case - How would you use this feature?
  • Alternatives Considered - Other solutions you’ve tried
  • Examples - Screenshots or mockups if applicable
  • Impact - Who would benefit from this feature?

Contributing Code

Development Setup

Prerequisites

  • Go - Version 1.27.0 or later for building xget
  • Git - For cloning the repository
  • Visual Studio Code - Latest version recommended

Initial Setup

  1. Fork the Repository

    Click the “Fork” button on the GitHub repository

  2. Clone Your Fork

    git clone https://github.com/YOUR-USERNAME/xget.git
cd xget

  3. Add Upstream Remote

    git remote add upstream https://github.com/camalot/xget.git

  4. Open in Visual Studio Code

    code .

Git Commit Messages

Use Conventional Commits format:

<type>(<scope>): <subject>

<body>

<footer>

Types:

  • feat: - New feature
  • fix: - Bug fix
  • docs: - Documentation changes
  • style: - Code style changes (formatting, no logic change)
  • refactor: - Code refactoring
  • perf: - Performance improvements
  • test: - Adding or updating tests
  • chore: - Maintenance tasks, dependency updates

Testing Your Changes

Before submitting a pull request, test your changes thoroughly:

  1. Run Unit Tests

    go test ./...

  2. Test the Packaging (optional)

    To verify the scoop manifest, homebrew cask, and winget manifests without publishing a release:

    task release:dry-run

    This sets XGET_DRY_RUN=true, which disables the GitHub release and forces skip_upload on every package pipe. The rendered manifests are written to dist/scoop/, dist/homebrew/, and dist/winget/. The android build is skipped locally because it needs the Android NDK; run it with task release:dry-run SKIP_ANDROID=false if the NDK is installed.

    The same pipeline can be run in CI with the release dry-run workflow (workflow_dispatch), which builds every target and uploads the manifests as a workflow artifact.

Submitting a Pull Request

Once your changes are ready:

  1. Update from Upstream

    git fetch upstream
git rebase upstream/develop

  2. Create a Feature Branch

    git checkout -b feature/your-feature-name

    Or for bug fixes:

    git checkout -b fix/issue-description

  3. Commit Your Changes

    git add .
git commit -m "feat: add support for new task type"

  4. Push to Your Fork

    git push origin feature/your-feature-name

  5. Open a Pull Request

    • Go to your fork on GitHub
    • Click “Compare & pull request”
    • Select camalot/xget develop branch as the base
    • Fill out the PR template with details about your changes

Pull Request Guidelines:

  • Clear Title - Summarize the change in the PR title
  • Description - Explain what you changed and why
  • Related Issues - Reference any related issues (e.g., “Fixes #123”)
  • Testing - Describe how you tested your changes
  • Screenshots - Include screenshots for UI changes
  • Documentation - Update README.md or other docs if needed
  • Changelog - Add entry to CHANGELOG.md following existing format

Contributing Documentation

Documentation improvements are valuable contributions! You can help by:

  • Fixing Typos and Grammar - Submit PRs for corrections
  • Clarifying Instructions - Make setup or usage instructions clearer
  • Adding Examples - Provide real-world usage examples
  • Updating Screenshots - Replace outdated images
  • Expanding Sections - Add more detail to existing documentation
  • Creating Guides - Write tutorials or how-to guides

Documentation files to consider:

  • README.md - Main user documentation
  • SUPPORT.md - Support and help resources
  • CHANGELOG.md - Release notes and version history
  • Code comments and Documentation in source files

Code of Conduct

See CODE_OF_CONDUCT.md for details on our code of conduct, which outlines expected behavior and how to report issues.

Reporting Issues

If you experience or witness unacceptable behavior, please report it by:

  • Opening a private issue on GitHub
  • Contacting the project maintainer directly

All reports will be handled with discretion and confidentiality.

Questions?

If you have questions about contributing: