Add a CONTRIBUTING.md

オープン 初心者向け
  • 何か問題がありますか？
#793 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

まだ誰も着手していません。

評価

難易度
2/5
見積もり時間
1〜3時間
初心者へのやさしさ
88/100
issue の種類
ドキュメント
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
git
領域
documentation

調査の方向性

まず、ルートレベルにある既存の gitmessage と CODING_STANDARDS.md を読み、その後、要求された CONTRIBUTING.md を作成します。短くまとめつつ、テストに関する期待事項、コミットメッセージ、プルリクエストのスコープ、レビュー基準を含め、CODING_STANDARDS.md への参照を入れます。contributors がこれらの期待事項を 1 つの明確なガイドで確認できれば完了です。

索引モデルが issue の本文から書いたものです。

説明

This repo has no CONTRIBUTING.md. A contributor has no way to learn what we
expect before they open a pull request, so they find out in review instead.

That happened on #789. The change itself was good. The review still raised
points that came from standards we have never written down, such as which
verbs a commit title may start with. That is not a fair thing to hold
someone to in review.

The file should cover:

  • How to run and test a change. Right now there is no test harness for bin/
    and no lint in CI, so say plainly how a contributor should show their work.
  • Commit message expectations, and a pointer to gitmessage, which already
    sits in the repo root and which most contributors never open.
  • What one pull request should contain.
  • What review will hold you to, described below.

Keep it short. A long guide goes stale and nobody reads it.

What review will hold you to

This is the part #789 got wrong, so it deserves its own words.

A review may only ask for a change against a standard this repo publishes.
CONTRIBUTING.md, CODING_STANDARDS.md and gitmessage are that list. If a
reviewer wants a change, they should name the file the rule comes from.

Anything a reviewer wants that is not in one of those files is a preference,
not a defect. Preferences are fine to mention, and they are not grounds to
block a pull request or to send a contributor round again. If a preference
turns out to be worth enforcing, the fix is to add it to one of those files,
where the next contributor can read it before they start.

This binds reviewers whether they are people or agents. An agent reviewing a
branch here reads its own operator's config as well as this repo, and the two
are not the same thing. Only this repo binds a contributor.

A maintainer picking up a follow-up is also often better than a round trip.

Related: #794 covers CODING_STANDARDS.md. This file should point at that
one rather than repeat it.

主要言語
Shell
スター
8.2k
フォーク
1.7k
30日以内にマージされた PR はありません

環境構築

このプロジェクトには開発コンテナ、Dockerfile、コントリビューションガイドがありません。まず README を読み、一般的な手順ははじめてのコントリビューションガイドを参照してください。

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

thoughtbot/dotfiles のほかの issue

thoughtbot/dotfiles の issue をすべて見る

似ている issue

Shell/Bash の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。