一個人也能維護公開專案Maintain a public project on your own

Move from “I finished it” to “I know how to receive problems”

When you develop alone, it is perfectly fine for someone to tell you about a problem and for you to fix it directly. GitHub Issues, Pull Requests (PRs), and Actions are not rituals for every tiny change. They are tools that preserve clues and reduce repeated checking when memory is not enough, the risk grows, or strangers can use your project.

In the previous unit you were the Contributor sending a PR. Here you move to the other side: you are the Maintainer who decides what the project accepts, how to respond, and when a merge is safe.

This is the smallest useful workflow for maintaining a small public project alone. You do not need to copy a large company's process.

Decide whether to keep an Issue

Think of an Issue as a project-specific todo item and discussion record. Not everything needs one:

• A typo or a fix that takes a few minutes: edit and commit directly.
• No time to handle it now, or the problem happens occasionally: create an Issue so it is not forgotten.
• The problem cannot be reproduced or needs questions: use the Issue to collect details.
• A change may affect several features: record the scope, then create a branch.
• A report from a public user: keep the Issue so they can see its status.
• A password, token, or security vulnerability: do not ask for public details; use a private, secure channel.

A useful bug Issue answers five questions:

1. Which version and operating system were used?
2. What actions were taken?
3. What was expected?
4. What actually happened?
5. Is there an error message or screenshot?

When information is missing, you can reply:

Thanks for the report. I cannot reproduce it yet.
Could you add the project version, operating system, steps,
expected result, and actual error? Please do not share passwords or tokens.

A Maintainer can say “not now”

A public repository does not mean you must accept every request. A suggestion may be reasonable but still add server, account, database, security, or long-term maintenance responsibilities. If it does not fit the project, decline politely and clearly.

Thanks for the suggestion. This project intentionally stays offline and login-free.
Adding account sync would expand its privacy and maintenance scope, so it is not planned now.
I will close this Issue while keeping the discussion for future reference.

Do not promise an uncertain date just to be polite. “Accepted”, “needs more information”, “not planned”, or “duplicate” are all more responsible than leaving a request without a conclusion.

Five questions for an incoming Pull Request

1. What does the PR solve? Is there a related Issue?
2. Does the change fit the project scope?
3. Does the diff contain only related changes?
4. Do automatic checks and the existing features still work?
5. Do you understand the change and want to maintain it later?

GitHub review has three common outcomes:

• Comment: ask, discuss, or suggest a non-blocking improvement.
• Approve: you checked it and agree to merge.
• Request changes: a necessary fix is required before merging.

When requesting changes, point to the exact location, impact, and expected result. Do not only say “this is bad”.

GitHub Actions is an automatic check station

Actions can run your chosen work when someone pushes or opens a PR. A workflow contains jobs, and jobs contain steps such as checking out code, installing packages, and running tests:

name: PR checks

on:
  pull_request:

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v6
      - name: Install packages
        run: npm ci
      - name: Run tests
        run: npm test

A green check means the checks you configured passed. It does not prove that the requirements are right, the code is secure, or future maintenance will be easy. A red check may come from the workflow, test cases, or environment, so read the failed job and step logs before judging.

Code from an external PR is not trusted yet. Never put secrets in a workflow or source code, and do not give outside code high privileges just for convenience.

You can open a PR for a larger solo change

Use risk to decide:

• Small, low-risk change: commit directly.
• Several files: use a branch.
• Could break existing behaviour: use a branch, then open a PR to review the full diff and checks.
• Want a decision and verification record: use an Issue plus a PR.

This is not pretending to have a team. It is leaving a merge checkpoint for yourself a few days later.

The smallest complete solo-maintainer loop

Receive report
→ Decide whether an Issue is needed
→ Collect version, steps, and error details
→ Accept, postpone, or decline
→ Fix on a branch and open a PR when useful
→ Read the diff and Actions checks
→ Comment / Approve / Request changes
→ Merge
→ Tell the reporter the fixed version and close the Issue

Merging ends the code change, not the communication. Leave a final note such as “fixed in version X” so both you and the reporter can confirm the result later.

Advanced units can wait

After finishing the personal course, you can add enterprise and large open-source topics gradually: Issue forms, branch protection, required reviewers, CODEOWNERS, GitHub Projects, Actions matrices and caches, automatic deployment, release automation, secret permissions, and self-hosted runners.

You do not need all of these to maintain a small project. Add one only when a real need appears.