DEV Community: Mao开霖

把 GitHub 用成研发加速器：从 Issue 到 Release 的实战工作流

Mao开霖 — Wed, 10 Jun 2026 16:03:04 +0000

把 GitHub 用成研发加速器：从 Issue 到 Release 的实战工作流

很多团队把 GitHub 当成一个代码仓库：能 push、能 pull request、能看 diff，就算用起来了。真正高效的用法要更进一步：让 GitHub 承担需求记录、变更讨论、质量检查、版本发布和知识沉淀。这样做的好处不是多用几个功能，而是让工程活动的上下文留在代码旁边。一个后来加入项目的人，不需要在聊天记录、会议纪要和本地文档里来回翻找，只要沿着 Issue、Pull Request、Actions 和 Release 的链路，就能理解某次变更为什么发生、怎么实现、如何验证，以及最终发布了什么。

这篇文章用一个小型 Web 项目的视角，整理一套可以直接套用的 GitHub 工作流。它适合个人项目，也适合 3 到 20 人的小团队。示例会覆盖 Issue 模板、分支命名、Pull Request 描述、GitHub Actions 自动检查、Dependabot 依赖维护、Release Notes 生成，以及几个容易被忽略但很有用的命令行技巧。文章中的代码示例可以直接复制到仓库里试用。

先把协作入口统一到 Issue

Issue 的价值不只是记录 bug。它更像一次变更的起点：问题、目标、限制、验收标准都应该先在这里出现。如果没有这个起点，Pull Request 往往会变成一次突然出现的代码提交，审阅者只能从 diff 里猜测作者意图。猜测越多，审阅越慢，返工也越多。

可以先在仓库里创建 .github/ISSUE_TEMPLATE/bug_report.yml，用表单结构减少信息缺失。YAML Issue Form 比普通 Markdown 模板更适合团队使用，因为它能引导提交者填写必要字段，也能减少标题党式的描述。

name: Bug report
description: Report a reproducible problem
title: "[Bug]: "
labels: ["bug"]
body:
  - type: textarea
    id: summary
    attributes:
      label: What happened
      description: Describe the user-visible behavior
    validations:
      required: true
  - type: textarea
    id: steps
    attributes:
      label: Steps to reproduce
      value: |
        1. Go to ...
        2. Click ...
        3. See ...
    validations:
      required: true
  - type: input
    id: version
    attributes:
      label: App version or commit SHA
    validations:
      required: false

对于功能需求，可以再加一个 feature_request.yml。重点不是字段越多越好，而是抓住三个问题：用户遇到了什么场景，期望获得什么结果，怎样判断结果已经达成。一个好 Issue 不需要写成 PRD，但它必须让读者知道为什么要改。

name: Feature request
description: Suggest a focused improvement
title: "[Feature]: "
labels: ["enhancement"]
body:
  - type: textarea
    id: problem
    attributes:
      label: User problem
      description: What user situation should this solve?
    validations:
      required: true
  - type: textarea
    id: expected
    attributes:
      label: Expected behavior
      description: What should be true after the change?
    validations:
      required: true
  - type: textarea
    id: notes
    attributes:
      label: Technical notes
      description: Optional implementation constraints or references

有了模板之后，Issue 标题也要尽量具体。例如 Improve login 不如 Keep users signed in after browser refresh。前者像愿望，后者像可以讨论和验证的变更。标题越具体，后续分支名、提交信息和 Release Notes 都越自然。

分支和提交信息要能被机器理解

GitHub 工作流里有两种读者：人和机器。人读标题、描述、评论和代码；机器读分支名、提交信息、标签、配置文件和状态检查。让机器读懂项目结构，自动化才能稳定运转。

一个简单的分支命名规则就够用：

feature/123-keep-session-after-refresh
fix/128-handle-empty-avatar-url
docs/131-update-api-readme
chore/140-upgrade-vite

前缀表示变更类型，中间的数字关联 Issue，后面的短语描述目标。这样做之后，你可以从分支名里知道变更来源，也可以在脚本里提取 Issue 编号。提交信息也可以采用轻量的 Conventional Commits 风格：

git commit -m "fix(auth): keep session after browser refresh"
git commit -m "test(auth): cover token restore behavior"
git commit -m "docs(readme): explain local env setup"

这种格式对人类也友好。fix(auth) 表示认证模块的修复，后面的句子说明具体行为。以后生成变更日志时，工具可以把 fix、feat、docs 分类，而不是把所有提交平铺成一串很难读的 hash。

如果团队暂时不想引入完整的 commitlint，也可以先用 Pull Request 标题作为发布说明来源。Squash merge 时，GitHub 默认会用 PR 标题生成最终提交信息。只要 PR 标题保持规范，主分支历史就不会太乱。

Pull Request 描述要回答三个问题

很多 PR 描述只有一句 fix bug，这会把理解成本转移给审阅者。好的 PR 描述不一定长，但要回答三个问题：改了什么，为什么这样改，如何验证。

可以在 .github/pull_request_template.md 里放一个简洁模板：

## What changed

- 

## Why

- Closes #

## How to test

- [ ] Run `npm test`
- [ ] Open the affected page and verify ...

## Screenshots

If UI changed, add before/after screenshots.

这个模板不会强迫作者写长文，但会提醒作者补齐上下文。Closes #123 这样的语法还能在 PR 合并后自动关闭对应 Issue。对维护者来说，这条关联非常重要：它把需求、实现和发布串起来，后续追溯时不需要靠记忆。

审阅时也可以少写含糊评论，多写可验证建议。比如不要只说 This is confusing，可以改成 Can we rename this to restoreSession so it describes the side effect?。审阅评论越具体，作者越容易处理，讨论也越不容易变成风格争论。

用 GitHub Actions 保住主分支质量

自动化检查的目标不是追求复杂，而是避免低级错误进入主分支。对于一个 Node.js 项目，最基础的检查通常包括安装依赖、类型检查、Lint 和测试。下面这个 workflow 可以放在 .github/workflows/ci.yml：

name: CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm

      - name: Install dependencies
        run: npm ci

      - name: Type check
        run: npm run typecheck --if-present

      - name: Lint
        run: npm run lint --if-present

      - name: Test
        run: npm test --if-present

这里的 --if-present 适合渐进接入。早期项目可能还没有 typecheck 或 lint 脚本，但 workflow 不会因此失败。等团队补齐脚本后，CI 会自动执行对应步骤。

如果是 Python 项目，可以换成下面的版本：

name: Python CI

on:
  pull_request:
  push:
    branches: [main]

jobs:
  test:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-python@v5
        with:
          python-version: "3.12"

      - name: Install dependencies
        run: |
          python -m pip install --upgrade pip
          pip install -r requirements.txt
          pip install pytest ruff

      - name: Lint
        run: ruff check .

      - name: Test
        run: pytest

把这些检查设置为 required status checks 后，未通过 CI 的 PR 就不能合并。这个规则比口头约定更可靠，因为它不依赖某个人是否记得提醒。

用路径过滤减少无意义运行

仓库变大后，每个 PR 都跑完整 CI 会浪费时间。GitHub Actions 支持路径过滤，可以让文档变更跳过应用测试，或者让前端和后端只运行自己的检查。

on:
  pull_request:
    paths:
      - "src/**"
      - "package.json"
      - "package-lock.json"
      - ".github/workflows/ci.yml"

如果仓库是 monorepo，可以拆成多个 workflow：

name: Web CI

on:
  pull_request:
    paths:
      - "apps/web/**"
      - "packages/ui/**"

jobs:
  test-web:
    runs-on: ubuntu-latest
    defaults:
      run:
        working-directory: apps/web
    steps:
      - uses: actions/checkout@v4
      - uses: actions/setup-node@v4
        with:
          node-version: 20
          cache: npm
          cache-dependency-path: apps/web/package-lock.json
      - run: npm ci
      - run: npm test

路径过滤不是为了偷懒，而是把反馈时间留给真正相关的代码。CI 越快，开发者越愿意频繁提交小 PR；PR 越小，审阅越准确。

Dependabot 让依赖升级变成小步快跑

依赖升级最怕拖到一次大爆炸。半年不升，最后一次升级几十个包，测试失败时很难判断问题来自哪里。Dependabot 可以把升级拆成小 PR，让维护变成日常小事。

把下面的配置保存到 .github/dependabot.yml：

version: 2
updates:
  - package-ecosystem: npm
    directory: "/"
    schedule:
      interval: weekly
    open-pull-requests-limit: 5
    groups:
      dev-dependencies:
        dependency-type: development
        update-types:
          - minor
          - patch

  - package-ecosystem: github-actions
    directory: "/"
    schedule:
      interval: monthly

这里把开发依赖的 minor 和 patch 更新合并成一组，避免 PR 数量太多；GitHub Actions 的版本也交给 Dependabot 维护。真正敏感的主依赖可以保留单独 PR，这样审阅时更谨慎。

如果测试覆盖还不够，先不要急着打开自动合并。Dependabot 的 PR 至少能提醒你依赖已经落后，并提供明确的变更入口。等 CI 稳定后，再考虑对 patch 更新开启自动合并。

Release Notes 应该从 PR 中自然生成

发布说明最常见的问题是临近发布才补写。更好的方式是在 PR 合并时就保留足够信息，让 Release Notes 可以自然生成。GitHub 的 Releases 页面支持自动生成说明，也可以配合标签使用。

一个简单的发布流程可以是：

git checkout main
git pull origin main
git tag v1.4.0
git push origin v1.4.0

如果项目使用 npm，可以把版本号更新也纳入流程：

npm version minor
git push origin main --follow-tags

在 GitHub Release 中，按照用户视角组织内容比按照提交顺序更有价值。比如：

## Added
- Keep users signed in after browser refresh.
- Add keyboard shortcut hints to the command palette.

## Fixed
- Handle empty avatar URLs without breaking the profile page.
- Prevent duplicate toast messages after retrying a failed request.

## Maintenance
- Upgrade Vite and testing dependencies.

这些条目应该来自 PR 标题，而不是发布当天临时翻 commit。也就是说，日常 PR 写得越清楚，发布时越轻松。

GitHub CLI 能节省很多切换成本

浏览器适合审阅和讨论，但很多日常动作可以在终端完成。安装 GitHub CLI 后，创建 PR、查看检查结果、打开 Issue 都能少切几次窗口。

gh issue list --label bug --assignee @me
gh issue view 123 --web
gh pr create --fill --base main
gh pr checks --watch
gh pr merge --squash --delete-branch

gh pr create --fill 会根据提交信息自动填充标题和描述。如果你的提交信息已经清楚，创建 PR 会快很多。gh pr checks --watch 则适合在本地等 CI 结果，不必反复刷新页面。

还可以用 gh 快速把 Issue 转成分支：

issue=123
title=$(gh issue view "$issue" --json title --jq .title)
slug=$(echo "$title" | tr '[:upper:]' '[:lower:]' | tr -cs 'a-z0-9' '-' | sed 's/^-//;s/-$//')
git checkout -b "feature/${issue}-${slug}"

这个小脚本会读取 Issue 标题，并生成一个带 Issue 编号的分支名。团队可以把它放进 scripts/new-branch.sh，减少手写分支名的随意性。

保护规则比口头约定更稳定

GitHub 的 Branch protection rules 很适合保护 main 分支。建议至少打开三个设置：禁止直接 push、要求 PR 审阅、要求状态检查通过。对于小团队，可以先要求一名审阅者；对于关键仓库，可以要求 Code Owners 审阅。

CODEOWNERS 文件可以放在 .github/CODEOWNERS：

# UI components
/packages/ui/ @frontend-team

# Authentication and security-sensitive code
/src/auth/ @security-reviewers

# CI and release automation
/.github/ @maintainers

当相关路径发生变更时，GitHub 会自动请求对应人员审阅。这样做可以避免安全敏感代码被不熟悉上下文的人随手合并，也能让专家审阅集中在最需要他们的地方。

不过保护规则也要适度。规则太严会让小改动变慢，规则太松会让主分支不稳定。比较实用的做法是先保护 main，再根据事故和返工情况逐步补规则，而不是一开始就把所有限制打开。

小 PR 是这个工作流的核心习惯

工具配置只是基础，真正决定效率的是 PR 大小。一个 80 行的 PR 通常能得到更认真、更快的审阅；一个 2000 行的 PR 即使通过了 CI，也很难有人完整理解。GitHub 的所有功能都在鼓励小步变更：Issue 聚焦一个问题，分支对应一个目标，CI 快速反馈，Release Notes 记录一个可解释的结果。

拆小 PR 可以从三个角度入手。第一，先提交纯重构，再提交行为变化，避免审阅者同时判断代码移动和逻辑修改。第二，先补测试刻画现状，再修复问题，让修复更可信。第三，UI 变更尽量附截图或录屏，让审阅者少在本地启动项目。

例如修复登录状态恢复问题，可以拆成两步：

PR 1: test(auth): cover session restore after refresh
PR 2: fix(auth): restore session from persisted token

第一步可能只是补测试和少量测试工具调整，第二步才改业务逻辑。这样审阅者能清楚看到失败用例和修复之间的关系。如果两个步骤混在一个大 PR 里，讨论会更难聚焦。

一个可以直接采用的仓库结构

下面是一套适合中小型项目的 GitHub 配置结构：

.github/
  ISSUE_TEMPLATE/
    bug_report.yml
    feature_request.yml
  workflows/
    ci.yml
  CODEOWNERS
  dependabot.yml
  pull_request_template.md
src/
tests/
README.md
package.json

不需要一次性把所有文件都加上。最推荐的顺序是：先加 PR 模板和 CI，再加 Issue 模板，然后接入 Dependabot，最后根据团队需要配置 CODEOWNERS 和发布流程。这样每一步都能带来清晰收益，也不会让维护者突然背上一堆新规则。

密钥和权限要从第一天管起来

GitHub 工作流一旦接入 CI、发布和第三方服务，就会接触令牌、部署密钥、云服务凭证和包管理平台的访问权限。很多事故不是因为功能复杂，而是因为密钥被写进代码、日志或截图里。项目越小，越容易觉得“先这样放一下没关系”；但仓库一旦公开，历史提交、fork、缓存和自动化日志都会扩大泄漏范围。

最基本的原则是把配置和密钥分开。代码里只读取环境变量，真实值放在 GitHub Actions Secrets 或部署平台的密钥管理里。下面是一个 Node.js 服务读取配置的简单例子：

const required = ["DATABASE_URL", "JWT_SECRET", "GITHUB_TOKEN"];

for (const key of required) {
  if (!process.env[key]) {
    throw new Error(`Missing required environment variable: ${key}`);
  }
}

export const config = {
  databaseUrl: process.env.DATABASE_URL,
  jwtSecret: process.env.JWT_SECRET,
  githubToken: process.env.GITHUB_TOKEN,
};

在 GitHub Actions 中引用 secret 时，不要把它打印出来，也不要在调试命令里输出完整环境。发布任务可以这样写：

name: Deploy

on:
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    permissions:
      contents: read
    steps:
      - uses: actions/checkout@v4
      - name: Deploy application
        env:
          DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
        run: ./scripts/deploy.sh

这里还顺手限制了 GITHUB_TOKEN 的权限。很多 workflow 默认拥有比实际需要更大的权限，尤其是发布、打包、评论 PR 这类任务。能只读就不要写入，能限定到单个 job 就不要给整个 workflow。权限越小，某个步骤被利用时造成的影响也越小。

如果发现密钥已经提交到仓库，不要只删除文件再提交。正确做法是立刻撤销旧密钥，重新生成新密钥，然后清理历史记录。对于已经推送到远端的公开仓库，要假设密钥已经泄漏。Git 历史清理能减少继续传播，但不能把已经被复制的内容收回来。

结语

GitHub 的优势不在于某个单独功能，而在于它能把工程上下文串起来。Issue 说明为什么要改，分支和提交记录怎么改，Pull Request 承载讨论和审阅，Actions 给出自动化反馈，Release 记录交付结果。当这些环节互相连接，项目就不再依赖少数人的记忆。

如果你正在维护一个项目，可以从今天的下一次 PR 开始：写清楚标题，关联 Issue，补上验证方式，让 CI 跑起来。等这些小习惯稳定下来，GitHub 就会从“代码托管工具”变成一个可靠的研发协作系统。

How I Made $500+ from GitHub Bounties in 30 Days (Real Data)

Mao开霖 — Tue, 09 Jun 2026 16:30:07 +0000

How I Made $500+ from GitHub Bounties in 30 Days (Real Data)

GitHub has become much more than a code hosting platform. It's now a career tool, a learning resource, and yes -- a source of income. Last month, I decided to run a 30-day experiment: how much could I earn from GitHub bounties by treating it as a side project?

Spoiler: I made $523. But the real value was in what I learned about the ecosystem, my own skills, and how to build systems that scale. Here's the full breakdown with real data, the tools I built, and actionable strategies you can use starting today.

Background

About three months ago, I stumbled upon a GitHub issue labeled bounty on a popular open-source project. Someone was offering $150 for a well-defined bug fix. I submitted a PR, it got merged, and the bounty was paid within 48 hours.

That experience got me thinking: what if I treated GitHub bounties as a systematic side income, not just random lucky finds?

I set some ground rules for my 30-day experiment:

Time limit: Maximum 2 hours per day on bounty work
Minimum reward: Only pursue bounties worth $50+
Skill focus: Stick to areas I'm already strong in (Python, JavaScript, DevOps)
Track everything: Every hour, every submission, every outcome

The Challenges

Before diving into the solutions, let me share the hurdles I encountered:

Finding the right opportunities in a crowded space -- GitHub has thousands of issues, but only a fraction have bounties attached
Balancing time investment with expected returns -- Some bounties look easy but take hours; others look hard but are trivial
Dealing with rejection and learning from feedback -- Not every PR gets accepted, and not every maintainer responds quickly
Scaling the approach once initial success was achieved -- Manual searching doesn't scale

How I Solved It

Challenge: Finding the Right Opportunities

I built a systematic approach to identify the best opportunities. Instead of randomly browsing, I created a Python tool that filters and ranks bounty opportunities by skill match.

import requests
from dataclasses import dataclass
from typing import Optional

@dataclass
class Bounty:
    """Represents a GitHub bounty opportunity."""
    repo: str
    issue_number: int
    title: str
    reward: float
    tags: list[str]
    language: str
    url: str
    difficulty: str  # "easy", "medium", "hard"

class BountyHunter:
    """Automated bounty discovery and ranking system."""

    # Bounty platforms to check
    PLATFORMS = {
        "gitcoin": "https://gitcoin.co/api/v0.1/bounties/",
        "bountysource": "https://api.bountysource.com/issues",
        "github": "https://api.github.com/search/issues",
    }

    def __init__(self, skills: list[str], min_reward: float = 50):
        self.skills = set(s.lower() for s in skills)
        self.min_reward = min_reward
        self.matched: list[Bounty] = []
        self.session = requests.Session()
        self.session.headers.update({
            "Accept": "application/vnd.github.v3+json",
            "User-Agent": "BountyHunter/1.0",
        })

    def search_github_issues(self, query: str = "bounty label:bounty state:open") -> list[dict]:
        """Search GitHub for bounty-labeled issues."""
        params = {
            "q": query,
            "sort": "updated",
            "order": "desc",
            "per_page": 100,
        }
        response = self.session.get(
            "https://api.github.com/search/issues",
            params=params,
        )
        response.raise_for_status()
        return response.json().get("items", [])

    def calculate_match_score(self, bounty_tags: list[str], language: str) -> float:
        """
        Calculate how well a bounty matches our skills.
        Returns a score between 0.0 and 1.0.
        """
        bounty_tags_set = set(t.lower() for t in bounty_tags)

        # Language match (high weight)
        lang_match = 1.0 if language.lower() in self.skills else 0.0

        # Tag overlap score
        tag_overlap = bounty_tags_set & self.skills
        tag_score = len(tag_overlap) / max(len(self.skills), 1)

        # Weighted combination: language matters most
        return 0.6 * lang_match + 0.4 * tag_score

    def rank_bounties(self, bounties: list[Bounty]) -> list[Bounty]:
        """Rank bounties by match score and reward value."""
        for bounty in bounties:
            bounty.match_score = self.calculate_match_score(
                bounty.tags, bounty.language
            )
            # Combined score: skill match * log(reward)
            # Using log to normalize reward differences
            import math
            bounty.priority = bounty.match_score * math.log1p(bounty.reward)

        return sorted(bounties, key=lambda b: b.priority, reverse=True)

    def daily_digest(self) -> str:
        """Generate a daily digest of top bounty opportunities."""
        issues = self.search_github_issues()
        ranked = self.rank_bounties(self.matched)

        digest = f"=== Daily Bounty Digest ({len(ranked)} opportunities) ===\n\n"
        for i, bounty in enumerate(ranked[:10], 1):
            digest += (
                f"{i}. [{bounty.reward}] {bounty.title}\n"
                f"   Repo: {bounty.repo} | Score: {bounty.match_score:.2f}\n"
                f"   URL: {bounty.url}\n\n"
            )
        return digest

This tool saved me enormous amounts of time. Instead of manually browsing through hundreds of issues, I ran this script every morning and got a curated list of the top 10 most relevant bounties.

Challenge: Tracking Time and Earnings

I needed to know whether my time was being spent efficiently. I built a simple tracking system:

from datetime import datetime, timedelta
from dataclasses import dataclass, field
from typing import Dict, List
import json

@dataclass
class DailyRecord:
    """Track daily bounty work statistics."""
    date: str
    hours_spent: float
    bounties_attempted: int
    bounties_completed: int
    earnings: float
    notes: str = ""

    @property
    def hourly_rate(self) -> float:
        return self.earnings / max(self.hours_spent, 0.01)

    @property
    def success_rate(self) -> float:
        return self.bounties_completed / max(self.bounties_attempted, 1)


class BountyTracker:
    """Track bounty earnings and time investment over time."""

    def __init__(self, data_file: str = "bounty_data.json"):
        self.records: List[DailyRecord] = []
        self.data_file = data_file
        self._load_data()

    def _load_data(self):
        """Load existing data from file."""
        try:
            with open(self.data_file, "r") as f:
                data = json.load(f)
                self.records = [
                    DailyRecord(**r) for r in data.get("records", [])
                ]
        except (FileNotFoundError, json.JSONDecodeError):
            self.records = []

    def record_day(self, record: DailyRecord):
        """Add a daily record."""
        self.records.append(record)
        self._save_data()

    def _save_data(self):
        """Persist data to file."""
        data = {
            "records": [
                {
                    "date": r.date,
                    "hours_spent": r.hours_spent,
                    "bounties_attempted": r.bounties_attempted,
                    "bounties_completed": r.bounties_completed,
                    "earnings": r.earnings,
                    "notes": r.notes,
                }
                for r in self.records
            ]
        }
        with open(self.data_file, "w") as f:
            json.dump(data, f, indent=2)

    def summary(self) -> dict:
        """Generate overall statistics."""
        total_earnings = sum(r.earnings for r in self.records)
        total_hours = sum(r.hours_spent for r in self.records)
        total_attempted = sum(r.bounties_attempted for r in self.records)
        total_completed = sum(r.bounties_completed for r in self.records)

        # Weekly breakdown
        weekly = {}
        for record in self.records:
            week_start = self._get_week_start(record.date)
            if week_start not in weekly:
                weekly[week_start] = {"earnings": 0, "hours": 0, "completed": 0}
            weekly[week_start]["earnings"] += record.earnings
            weekly[week_start]["hours"] += record.hours_spent
            weekly[week_start]["completed"] += record.bounties_completed

        return {
            "total_earnings": total_earnings,
            "total_hours": total_hours,
            "overall_hourly_rate": total_earnings / max(total_hours, 0.01),
            "total_attempted": total_attempted,
            "total_completed": total_completed,
            "overall_success_rate": total_completed / max(total_attempted, 1),
            "weekly_breakdown": weekly,
            "best_day": max(self.records, key=lambda r: r.earnings, default=None),
        }

    @staticmethod
    def _get_week_start(date_str: str) -> str:
        """Get the Monday of the week containing the given date."""
        dt = datetime.strptime(date_str, "%Y-%m-%d")
        monday = dt - timedelta(days=dt.weekday())
        return monday.strftime("%Y-%m-%d")

Challenge: Writing Winning PRs

One of the biggest lessons was that the quality of your PR matters as much as the code itself. Maintainers are busy people, and a well-structured PR stands out. Here's the template I developed:

## Description

Fixes #[ISSUE_NUMBER]

### Problem
[Clear description of the bug/feature request]

### Solution
[Explanation of the approach taken]

### Changes Made
- [ ] Change 1 with file reference
- [ ] Change 2 with file reference
- [ ] Tests added/updated

### Testing
[How to verify the fix works]

## Type of Change
- [ ] Bug fix
- [ ] New feature
- [ ] Breaking change
- [ ] Documentation update

## Checklist
- [ ] Code compiles without errors
- [ ] All tests pass
- [ ] Documentation updated if needed
- [ ] No breaking changes introduced

I also learned to follow these PR best practices:

Keep PRs small and focused -- One issue per PR, even if you could fix multiple things
Include tests -- Maintainers love PRs that come with tests. It shows you care about quality
Respond to reviews quickly -- Fast responses show commitment and keep momentum
Follow the project's conventions -- Code style, commit message format, directory structure

The Results

Here are the actual numbers from my 30-day experiment:

Metric	Result
Total Earnings	$523
Time Invested	~45 hours
Average Hourly Rate	$11.62/hr
Bounties Attempted	16
Bounties Completed	12
Success Rate	75%
Best Single Bounty	$150
Worst Day	$0 (3 days)
Best Day	$85

Weekly Breakdown

Week	Earnings	Hours	Hourly Rate	Completed
Week 1	$85	12h	$7.08	2
Week 2	$138	10h	$13.80	3
Week 3	$175	11h	$15.91	4
Week 4	$125	12h	$10.42	3

The upward trend in hourly rate shows the value of building systems and learning the ecosystem. Week 3 was my best because I had refined my filtering and PR writing process.

Earnings by Category

Category	Bounties	Earnings
Bug Fixes	5	$275
Feature Implementation	3	$150
Documentation	2	$48
Test Coverage	2	$50

Bug fixes were the most lucrative category, which makes sense -- they're well-defined, have clear acceptance criteria, and maintainers are motivated to get them fixed.

Where I Found the Bounties

Platform	Bounties Found	Earnings
GitHub Issues (label:bounty)	6	$298
Gitcoin	3	$125
Direct Repository Search	3	$100

Key Lessons Learned

1. Start with What You Know

Don't try to learn a new technology just because a bounty pays well. The time you spend learning eats into your hourly rate. Stick to your core skills and expand gradually.

My most successful bounties were in Python and JavaScript -- languages I've used for years. When I tried a Rust bounty, I spent 6 hours and didn't complete it. That's a $0/hr return.

2. Track Everything. Data Is Your Best Decision-Making Tool

Without the tracking system, I wouldn't have known that:

Bug fixes were 3x more profitable per hour than feature work
My success rate improved from 50% to 90% after implementing the filtering tool
Tuesday-Thursday had the highest bounty availability

3. Quality Beats Quantity

One well-done submission beats ten rushed ones. A clean PR with tests and good documentation gets accepted faster and builds your reputation with maintainers. Two of my bounties came from maintainers who reached out directly after seeing my previous work.

4. Build Relationships, Not Just Transactions

I made a point to engage with repositories beyond just submitting PRs. I left constructive comments on other issues, helped answer questions, and participated in discussions. This led to:

Being invited to work on bounties before they were publicly listed
Getting higher bounty amounts from maintainers who trusted my work
Receiving referrals to other projects

5. Automate the Boring Parts

The filtering tool and tracking system saved me at least 5 hours over 30 days. That's 5 hours I could spend on actual bounty work. The ROI on building tools is huge when you're doing repetitive tasks.

My Recommendations

Based on this experiment, here's my advice if you want to start earning from GitHub bounties:

Start small and validate your approach before scaling up -- Don't quit your day job. Start with 1 hour/day and see if it works for you
Invest time in building a strong profile first -- A good GitHub profile with existing contributions makes maintainers more likely to accept your PRs
Set a daily time limit to avoid burnout -- I stuck to 2 hours/day max. Consistency beats intensity
Document your process -- It becomes content (like this article) and a knowledge base you can reference
Don't ignore small opportunities -- A $50 bounty might lead to a $500 one when the maintainer knows your work
Focus on popular repositories with active maintainers -- Quick responses mean faster payment and more opportunities
Build your filtering system early -- The sooner you automate opportunity discovery, the more efficient you become

The Tools I Used

Here's a quick summary of the tools in my bounty-hunting stack:

Tool	Purpose	Cost
Custom Python Script	Bounty discovery and filtering	Free
GitHub Notifications	Issue updates and mentions	Free
VS Code + GitHub PR Extension	PR management	Free
Notion	Tracking and notes	Free tier
Toggl	Time tracking	Free tier

Total investment: $0. Everything I used was free or had a free tier.

A Closer Look at My Workflow

Let me walk you through a typical day during this experiment. This is the exact routine I followed from Week 2 onward, after I had refined my process.

Morning Routine (15 minutes)

Every morning at 7:30 AM, I would run my bounty discovery script:

#!/bin/bash
# daily_bounty_check.sh - Run every morning
python3 bounty_hunter.py --min-reward 50 --skills python,javascript,devops \
    --format table --top 10 > today_bounties.md

# Also check for updates on existing PRs
python3 bounty_hunter.py --check-pr-status

The script would output a clean table of the top 10 bounties sorted by my custom priority score. I'd scan through them during breakfast and flag 2-3 that I wanted to tackle that day.

Deep Work Block (1-2 hours)

After my regular work, I'd dedicate a focused block to bounty work. Here's the key: I treated this like a real job, not a casual hobby.

"""
bounty_session.py - Manage a focused bounty work session
"""
import time
from datetime import datetime, timedelta

class BountySession:
    """Track and manage a single bounty work session."""

    def __init__(self, max_duration_minutes: int = 120):
        self.max_duration = timedelta(minutes=max_duration_minutes)
        self.start_time = None
        self.checkpoints = []
        self.current_bounty = None

    def start(self, bounty_info: dict):
        """Begin a new bounty session."""
        self.start_time = datetime.now()
        self.current_bounty = bounty_info
        self.checkpoints = []

        print(f"[Session Started] {bounty_info['title']}")
        print(f"  Reward: ${bounty_info['reward']}")
        print(f"  Time Limit: {self.max_duration}")

    def checkpoint(self, note: str):
        """Record a checkpoint during the session."""
        elapsed = datetime.now() - self.start_time
        remaining = self.max_duration - elapsed

        self.checkpoints.append({
            "time": elapsed,
            "note": note,
        })

        print(f"[Checkpoint] {elapsed} elapsed | {remaining} remaining")
        print(f"  Note: {note}")

        # Warn if approaching time limit
        if remaining < timedelta(minutes=15):
            print("  ⚠️  Warning: Less than 15 minutes remaining!")

    def should_continue(self) -> bool:
        """Check if we should continue working."""
        elapsed = datetime.now() - self.start_time
        return elapsed < self.max_duration

    def end(self, status: str = "completed"):
        """End the session and log results."""
        elapsed = datetime.now() - self.start_time
        print(f"[Session Ended] Status: {status}")
        print(f"  Total Time: {elapsed}")
        print(f"  Checkpoints: {len(self.checkpoints)}")
        return {
            "bounty": self.current_bounty,
            "status": status,
            "duration": str(elapsed),
            "checkpoints": len(self.checkpoints),
        }

PR Submission and Follow-up (15 minutes)

After completing the work, I'd spend 15 minutes on PR quality:

Review the diff one more time
Write a clear PR description using my template
Add inline comments explaining non-obvious changes
Run all tests locally one final time
Submit and notify the maintainer with a polite comment

Evening Review (10 minutes)

Before bed, I'd update my tracker and review the day's progress:

# Quick daily review
tracker = BountyTracker()
summary = tracker.summary()

print(f"Total so far: ${summary['total_earnings']}")
print(f"Hourly rate: ${summary['overall_hourly_rate']:.2f}/hr")
print(f"Success rate: {summary['overall_success_rate']:.0%}")

This daily routine was critical. The consistency of showing up every day, even for just an hour, compounded over 30 days into meaningful results.

Common Mistakes to Avoid

Based on my experience and observations of other bounty hunters, here are the most common pitfalls:

1. Ignoring Repository Guidelines

Every project has its own contribution guidelines. Skipping CONTRIBUTING.md or ignoring the project's code style is the fastest way to get your PR rejected. I saw this happen to other contributors repeatedly.

2. Over-Engineering Solutions

A $50 bounty doesn't need a $500 solution. Keep your changes minimal and focused. One contributor I saw rewrote an entire module when a 3-line fix would have sufficed. The maintainer asked them to simplify, and the contributor got frustrated and abandoned the PR.

3. Not Reading the Full Issue Thread

I once submitted a PR that duplicated work someone else had already started. If I had read the full comment thread, I would have seen the ongoing discussion and either collaborated or chosen a different bounty. Always read every comment before starting work.

4. Ghosting After Submission

Submitting a PR and disappearing is a bad strategy. Maintainers often have questions or request changes. Responding within 24 hours dramatically increases your acceptance rate. In my data, PRs where I responded to reviews within 24 hours had a 92% merge rate, versus 45% for slower responses.

Scaling Beyond One Person

By Week 3, I was getting more opportunities than I could handle alone. Here's how I started thinking about scaling:

"""
bounty_pipeline.py - Pipeline for managing multiple bounty workflows
"""
from enum import Enum
from dataclasses import dataclass

class BountyStatus(Enum):
    DISCOVERED = "discovered"
    EVALUATING = "evaluating"
    IN_PROGRESS = "in_progress"
    PR_SUBMITTED = "pr_submitted"
    REVIEW = "under_review"
    MERGED = "merged"
    PAID = "paid"
    ABANDONED = "abandoned"

@dataclass
class PipelineItem:
    bounty: dict
    status: BountyStatus
    time_invested: float = 0.0
    expected_reward: float = 0.0
    notes: str = ""

class BountyPipeline:
    """Manage multiple bounties through their lifecycle."""

    def __init__(self):
        self.items: list[PipelineItem] = []

    def add(self, bounty: dict):
        """Add a new bounty to the pipeline."""
        self.items.append(PipelineItem(
            bounty=bounty,
            status=BountyStatus.DISCOVERED,
            expected_reward=bounty.get("reward", 0),
        ))

    def prioritize(self):
        """Re-prioritize based on current state."""
        # Active items first, sorted by expected value
        active = [i for i in self.items if i.status in (
            BountyStatus.DISCOVERED,
            BountyStatus.EVALUATING,
            BountyStatus.IN_PROGRESS,
            BountyStatus.REVIEW,
        )]
        active.sort(key=lambda x: x.expected_reward / max(x.time_invested, 0.1), reverse=True)

        # Then pending PRs
        submitted = [i for i in self.items if i.status == BountyStatus.PR_SUBMITTED]

        # Then completed
        done = [i for i in self.items if i.status in (
            BountyStatus.MERGED, BountyStatus.PAID
        )]

        self.items = active + submitted + done

    def get_next_action(self) -> str:
        """Determine the next action to take."""
        for item in self.items:
            if item.status == BountyStatus.DISCOVERED:
                return f"Evaluate: {item.bounty['title']}"
            elif item.status == BountyStatus.EVALUATING:
                return f"Start work: {item.bounty['title']}"
            elif item.status == BountyStatus.REVIEW:
                return f"Follow up on PR: {item.bounty['title']}"
        return "No pending actions. Find new bounties!"

    def summary(self) -> dict:
        """Pipeline summary statistics."""
        total_expected = sum(i.expected_reward for i in self.items)
        total_invested = sum(i.time_invested for i in self.items)
        by_status = {}
        for item in self.items:
            by_status[item.status.value] = by_status.get(item.status.value, 0) + 1

        return {
            "total_items": len(self.items),
            "total_expected_value": total_expected,
            "total_time_invested": total_invested,
            "by_status": by_status,
        }

This pipeline approach helped me manage 5-6 concurrent bounties without losing track of any of them. The key insight is that bounty work has natural waiting periods (waiting for review, waiting for maintainer response), and you can fill those gaps with new work.

What I'd Do Differently

Looking back, there are a few things I'd change:

Start with a wider skill net -- I was too conservative early on. Expanding to TypeScript and Go would have opened up more opportunities
Build relationships sooner -- I waited until Week 3 to start engaging with communities. Starting in Week 1 would have accelerated things
Set up automated alerts earlier -- My manual search in Week 1 was inefficient. The filtering tool should have been built on Day 1
Create a PR template library -- I wrote similar PR descriptions repeatedly. A template library with project-specific templates would have saved 10+ minutes per submission
Track maintainer response times -- Knowing which maintainers respond quickly would have helped me prioritize opportunities better

Final Thoughts

$523 in 30 days isn't life-changing money. But consider this:

I worked an average of 1.5 hours/day
I learned new skills and deepened existing ones
I built relationships with open-source maintainers
I created reusable tools that save me time in my regular work
I generated content (this article) from the experience

The real value isn't just the money -- it's the system, the skills, and the network you build along the way. If you're a developer looking for a structured way to earn side income while improving your craft, GitHub bounties are absolutely worth trying.

I'm now continuing this experiment with a higher daily time limit and expanded skill set. My goal for the next 30 days is $1,000+ by applying everything I learned. I'll share those results in a follow-up article.

Have you tried earning from GitHub bounties? I'd love to hear about your experience in the comments. What strategies worked for you? What didn't?

Enjoyed this article? Follow me for more real-world tech experiences and data-driven insights. I share practical strategies that actually work, backed by real numbers.