Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

This article is a Private article. Only a writer and users who know the URL can access it.
Please change open range to public in publish setting if you want to share this article with other users.

More than 5 years have passed since last update.

Qithub 設定資料集

Last updated at Posted at 2017-09-26

目次

Qithub とは

QiitaとQiitadonのユーザ間のコラボレーションを支援するためのBOTを共同で作るためのOrganizationです。

Organization の運営ルール

基本ルール(運営ポリシー)

  • KISS: 簡潔
  • CLEAR: 明瞭
  • HAPPY: 楽しく作って、楽しく使える
  • FUNNY: いつもどこかにユーモアを
  • 👍 😄 🤔 : emoji でシンプルに気持ちを伝えよう

コンセプト・目的 (items #4)

Qithub 3 つの moe (注:more のもじり)

  • 共同執筆と互助
  • 帰属意識の向上
  • 楽しく環境改善

運営ルール

issue

issue をクローズしていい時の意思表示方法 (items #15)

1行目に:thumbsup:(:thumbsup:)のみをコメントをした方は「意義なし!クローズしてよし!」と思っていることにします。

issue の最終的な結論をスレッドの頭にとりまとめる (items #33)

最初の質問者(issueを立ち上げた人)は、
知りたかった内容の最終結果もしくは現在の最新状態を
最初の投稿の下部に取りまとめてからクローズする

TL;DR(審議中・結論 yyyy/MM/dd 現在)

  • 決定事項
  • 審議中事項

ブランチの命名規則 (items #20)

<コミット単位メモ/記事ID>-<ブランチ作成時のタイムスタンプ YmdHi>

例) AddClosedIssue#20-201709281309
例) 1a52282f0b132347c2b1-201709281309

Pull Request

PR を建てる基準 (items #52)
  • マージを希望しない PR は行わない。
    (レビュー等でマージがペンディングになっている場合を除く)
  • 平行開発を防ぎたい場合は、 issue を立ててブランチ名を公開しておく。
    (平行開発とは他のメンバーの作業とのバッティングを指すが、同じ機能を別言語やアプローチで開発したい場合はこれを妨げないものとし、同じ issue内で別ブランチを立て、相談により解決するものとする)
  • ブランチの進捗(コミット内容)がわかるようにしたい場合は、PR せずにブランチの Push/Publish のみを行う。
マージ
記事の更新をマージする条件 (items #13)
  • BOTのフォロワーと判断したら関係なく更新する
  • BOTのフォロワー以外からQiitaコラボ記事のリクエストが来た場合のみ、合議制(:thumbsup:(:thumbsup:)or:thumbsdown:(:thumbsdown:)を含む返信のカウント)が発動する
マージを行う人

マージは、 「 PR を上げた本人以外のマージ権限保持者」 によってマージされます。

fork 先からのマージ手順 (scripts #60)

Fork 先のブランチは origin (Qithub-BOT/*) の master に直接 PR してよい。

ラベル

ラベルを貼るルール (items #7)

  • issueはラベルなしでスタートさせる
  • ラベリングラベリング担当チームにまかせる
  • メンバーが増えたら Role を再考する(=担当者を増やす)

ラベル「緊急度:x」の指針 (items #6)

緊急度計算機(仮。paiza.IO にて)

下図参照。

paiza.io: トリアージウィジェット prototype

カスタムラベルの名称と色 (items #5)

リポジトリitemsscriptsで共通です。

タグ名 色コード
不具合 #ee0701
保留 #ffffff
提案 #fbca04
無効 #e6e6e6
相談 #33aa3f
緊急度:中 #ffff00
緊急度:低 #0e8a16
緊急度:高 #b60205
質問 #cc317c
重複 #cccccc

'scripts' のプログラミング・チーム作成 (scripts #13)

チーム名 メンテナ チームの主な担当 参考 issue
ラベル @hidao80 issueにラベル(緊急度、カテゴリ)を割り当てる担当チーム ラベリングの種類 Qithub-BOT/items#5
ラベル「緊急度:x」の指針を決めましょう Qithub-BOT/items#6
プログラム @KEINOS issue に割り当てられた担当者以外のプルリクをマージする担当チーム。( 自身のプルリクを除く) BOT開発におけるマージの基準とデプロイ Qithub-BOT/scripts#5

勧誘方針

プロジェクトメンバーの勧誘基準 (items #12)

以下の条件を満たした人のうち、Organizationのメンバーから推薦を受けた人にお声がけする。

  • Qithub をフォローしている
  • 投票および改善要求を一回以上している

なお、これはこちらからアプローチする場合の基準であり、自発的に参加希望がある場合は、これを拒まない。

BOT のアカウント

Qiita のプロフィール情報

項目名 設定値
名前:姓 (空欄)
名前:名 Qithub(bot)
公開メールアドレス 非公開
サイト/ブログ https://github.com/Qithub-BOT/
所属している組織・会社 Qithub-BOT @ GitHub
居住地 Japan
自己紹介 QiitaとQiitadonのユーザ間コラボレーションを支援するためのBOTをQiitaユーザーで作るためのGitHubのOrganization用アカウントです。
Facebook ID (空欄)
LinkedIn ID (空欄)
Google+ ID (空欄)

Qiita のアカウント情報

項目名 設定値
ユーザ名 Qithub
登録メールアドレス qithub@keinos.com

Qiita のユーザー画面

プロフィール情報

項目名 設定内容
表示名 Qithub(bot)
プロフィール QiitaとQiitadonのユーザ間コラボレーションを支援するためのBOTです。このBOT自体もQiitaユーザのコラボによって作られています。[α版 2017/09/27 現在]
Qiitaアカウント qithub

Qiitadonのアカウント情報

Qiitaコラボ記事 目次

  • 記事の更新時に合わせて索引を自動更新
  • 非Qiita記事(README.mdと同等の)扱い
  • フォーマット
    • ファイル名: items/index.md
    • CSV形式(各ROWの最後のCOL(セル)はスペース2つで終了していることに注意)

<記事ID 1>.md,[記事タイトル1](記事1 URL)
<記事ID 2>.md,[記事タイトル2](記事2 URL)
<記事ID 3>.md,[記事タイトル3](記事3 URL)

企画

BOT のネーミングとアカウント (items #9)

  • 表示名:Qithub(bot)
  • Qiitaアカウント名: qithub
  • Qiitadonアカウント名: qithub

Organization名を変更しましたが、「Qithub」が取られていた(アカウントはBANだった)ので「Qithub-BOT」で登録しました。

「Qithub」のロゴやキャラクター募集 (items #18)

「擬人化したよ!」「キャラ作ったよ」など何かあれば、items リポジトリの issue #18にリクエストしてください。

案1 (current!)

Qithub icon


記事について

スパム記事の場合 (scripts #56)

特に対策しません。

理由:新着記事の通知が Qithub の本筋であって、Qiita の記事のクオリティに言及するものではないからです。

記事のライセンス (items #63)

Qithub-BOT/items リポジトリ内の記事にはクリエイティブ・コモンズの「表示ー継承 4.0 国際 (CC BY-SA 4.0)」ライセンスを適用します。

これは、Qiita の利用規約にも準拠しています。


Qithub の仕様

基本ルール

BOT 開発における主な開発の流れ (scripts #6)

  1. コーディングする
  2. 悩んだら issue or qiitadon でヘルプを求める
  3. プルリクする
  4. ふさわしくないときは、理由をコメントに書き、プルリクを棄却する
    • コミットがでかすぎる
    • Organization の目的とかけ離れた機能を実装している
    • etc.
  5. マージを実行する(同時にデプロイされる)
  6. items の仕様ドキュメントに実装した機能と仕様を記入する(以降はitemsのフローに準拠)
BOT 開発のマージは自動化しない
  • PR のマージは issue に割り当てられた担当者またはプログラミングチームのメンバーが行う(割り当て方法は要検討)
  • コードレビューは基本的にしない。マージ後の不具合が多いようであれば別途検討する

デプロイに関して

  • BOTの稼働先は当面 @KEINOS の個人サーバーで行う
  • マージされたものは自動的に上記サーバーに反映(デプロイ)されるようにする

ライセンス (items #63)

Qithub-BOT/items リポジトリ内の記事にはクリエイティブ・コモンズの「表示ー継承 4.0 国際 (CC BY-SA 4.0)」ライセンスを適用します。

ライセンスに関する相談は、issue をたててもらって都度相談することにします。

リポジトリ管理

BOT 開発におけるマージの基準とデプロイ (scripts #5)

PR の処理 (items #19)

CONTRIBUTING.md を転記します。

pull request を発行する時のルール

  1. 追加機能(記事)ごとにブランチを切る。
  2. 機能追加(記事の完成)が達成されていない PR[^1] の場合、ブランチを残し、 PR もクローズしない。
    PR 時コメントに不足事項を書くことにする。
  3. 機能追加が達成されいる PR の場合、ブランチを削除し、 PR をクローズする。

こんなときは

誤字・脱字の修正だけしたい

自分でブランチを切らずに、修正をしたい記事のブランチを clone して、 PR を上げずに push してください。
このとき、コミットメッセージで説明しきれない内容があれば、 PR のスレッドにコメントを残してください。

修正したい記事のブランチがない

「記事が完成した」として、ブランチを削除した可能性があります。新しくブランチを切って PR を作ってください。

同一記事に対して複数のブランチがある。どれに push してよいかわからない

「<記事ID>.md に対して複数のブランチがある」というタイトルで issue を立ててください。

可能であれば、最初のコメントに同一記事に対するすべてのブランチ名を列挙していただけると、より早く issue が解決し、push していただけます。

マージを行う条件
  1. 「PR を上げた本人以外のマージ権限保持者」 によって、「PR のコメントに記述されている変更が達成されており、記述にない変更がない」 PR
  2. ダイレクトメッセージで:thumbsup:(:thumbsup:)を 10 件以上受けた PR
マージされない例

例1)記事 yyyyyyyyyyy.md だけでなく 記事 zzzzzzzzzzz.md も同一ブランチで編集している

例2) PR のコメントに「投票集計機能を追加しました。」と書かれているのに、同じブランチで定時トゥートも変更されている

マージ後のブランチの処理

ブランチはマージ後、マージを行った人が責任をもって破棄します。

何らかの理由で破棄しない場合は、その理由を PR のコメントに残してください。

例)当該ブランチの範囲で、軽微な修正忘れが発覚した。

要件

BOT の必須機能 (scripts #1)

対 Qiita の必須機能
  • Qiita記事の「作成とID取得」「更新」「削除」
  • 新着Qiita記事の取得
対 GitHub の必須機能
  • GitHubからのWebHookによるトリガー起動
  • BOTからのマージの実行

プラグイン名は、テンプレートをドキュメントに指示し、それに沿わせる

例)<動詞>-<対象>

ファイル名として、エントリポイント(main関数的な、プラグインの起点となるファイル)には main.<拡張子> を指定する。

例1)main.php
例2)main.py

  • 「plugins」内のプラグイン名は issue番号 でなく「<DO>-<WHAT>」
対 Qiitadon の必須機能
  • トゥートおよびトゥートIDの取得
  • トゥートIDに対する返信
  • 公開範囲を指定してトゥート or 返信
  • フォロワーの情報取得
  • フォロワーのQiitaでのユーザー名取得

デプロイ先の必須機能

  • git cloneの実行によるアップデート(もしくはwgetなど)
  • cronによるWebHook実行(5分間隔)

'scripts'リポジトリのディレクトリ構成 (scripts #7)

  • プラグインには <DO>-<WHAT> という名前を使う。
  • テンプレートをドキュメントに指示し、それに沿わせる。
  • ファイル名として、エントリポイント(main関数的な、プラグインの起点となるファイル)には main.<拡張子> を指定する。
    • 例)main.php main.py
─ `scripts`リポジトリ /
    ├─ README.md
    ├─ index.php (本体スクリプト)
    ├─ _samples /
    │    └─ qithub.conf.sample
    │
    ├─ system /
    │    ├─ .htaccess
    │    ├─ index.html (ブランクファイル)
    │    ├─ post-toot /
    │    │     └─ main.php
    │    ├─ reply-toot /
    │    │     └─ main.py
    │    ├─ get-latest-qiita-articles /
    │    │     └─ main.php
    │    ├─ ⋯
    │    ⋮
    │
    └─ plugins /
         ├─ .htaccess
         ├─ index.html (ブランクファイル)
         ├─ count-thumbsup /
         │     └─ main.py
         ├─ say-hello /
         │     └─ main.php
         ⋮

セキュリティ:system/ 下のスクリプトの直接実行 (scripts #17)

.htaccessを作成し以下を設定する。

Options -ExecCGI
order deny,allow
deny from all

以上のようにガチガチに設定しつつ本体スクリプトの動作も確認できました。

記事原稿の保管パス (items #2)

items リポジトリ直下にQiita記事と同じIDのファイル名で保存する。ディレクトリの作成は禁止

  • 理由:QiitaのURLがitems/<ドキュメントID>となっているため
Qithub-BOT (Organization)
    ⊢ items (Repository)
    ∣    ⊢ xxxxxxxxxx.md (Raw MD text of Qiita Doc ID xxxxxxxxxx )
    ∣    ⊢ yyyyyyyyyyy.md (Raw MD text of Qiita Doc ID yyyyyyyyyyy )
    ∣    ∟ zzzzzzzzzzz.md (Raw MD text of Qiita Doc ID zzzzzzzzzzz )
    ∟ scripts (Repository)
         ∟ ??(未定)

動作仕様

BOT の動作

  1. ユーザA が Qiitadon から BOT にメンション・トゥート
  2. ユーザA の Qiita アカウントID を取得(@ユーザA)
  3. トゥート内容に問題がなければ BOT が Qiita に限定公開で記事を新規作成
  4. Qiita 記事 ID を取得
  5. items リポジトリに同内容の Markdown ファイルを作成
  6. 記事を作成した旨を ユーザ A のトゥートに返信
  7. ユーザ A は items リポジトリをローカルにクローンし以降は Git の通常フロー

BOT の実行間隔 (scripts #4)

  • cron による5分間隔の起動(定例処理)
  • GitHub からの WebHook による起動(随時処理)
  • URL 直打ちによる起動(臨時処理)

BOT による新規Qiita記事の作成と同期 (scripts #3)

Qiitaコラボ記事の新規作成
  • Qiita の Qithub アカウントで新規記事を作成、記事IDを取得する
  • 同記事IDで items リポジトリ(master)にテキストファイルを作成する
  • これらの動作は BOT が行うこととする(それまでは手動。2017/09/27 現在 @KEINOS が担当)
items リポジトリの同期
  • items リポジトリにおけるファイル名は Qiita記事のIDと同じとする(README.mdのみ例外)
  • 拡張子は".md"とする(<Qiita記事ID>.md)
  • items リポジトリにはQiita側の Qithub のアカウントに存在しない記事は置いてはいけない(README.md 除く)

トゥートの公開範囲の仕様 (items #11)

トゥートの基本公開範囲
  • 基本は非公開とし、フォロワーのみが閲覧可能とする
  • フォロワーに関するものは未収載とし、フォロワー意外でも閲覧可能にする
  • フォロワーからの一定評価があった内容に関しては公開でトゥートする
新着 Qiita 記事の公開範囲
  • 定時(朝、昼、晩)トゥートは開始のアナウンスのみとし、公開でトゥート
  • cronによる定期チェックにより、新着Qiita記事のお知らせは定時トゥートに非公開で返信
  • 特例として、新着Qiita記事がフォロワーの記事の場合は未収載で返信
  • cronの定期チェックで「ブースト数」「お気に入り数」が一定数を超えたものは公開で別途トゥート

※ 以下の機能に関しては、基本の実装が出来てからの拡張案件とし、別途 issue を立てることとします。

「フォロワーから個別にメンションされたタグを含む新着Qiita記事は、個別にフォロワーへダイレクト・トゥートする」機能

トゥートに ReToot リンクを埋める

新着投稿記事紹介トゥート内に「Boostoot」というキーワードに続いて、ReToot URL を追記する。

【新着Qiita記事】

『<タイトル>』 @<ユーザー>
http://qiita.com/<ユーザー>/items/<記事ID>

[#<タグ1> #<タグ2> #<タグn>]
Boostoot! → https://qiitadon.com/share?text=${URL}
^^^^^^^^^^

プラグイン仕様 (scripts #16)

範囲

  • プラグインは「トゥートの内容のみ」を生成し出力する機能に限定(トゥートの実行はしない)
  • トゥートの実行は'system'ディレクトリ内のスクリプトが担当

入力(データの受け取り)

  • プラグインは、本体スクリプトより標準入力からURLエンコードされたJSONの配列データを受け取る
  • プラグインが受け取る配列内容(データ)は、以下の2カ所に明記・定義すること
    • プラグインの"main"スクリプト内のコメント
    • プラグインの"main"と同階層の"README.md"内

出力(プラグインの処理結果)

  • プラグインの出力結果はJSON形式
  • 本体スクリプトが出力結果を処理するのに必要なデータを含める
{
    "range":"public",
    "text":"@hidao :sob:",
    "cw_title":"閲覧注意",
    "cw_content":":pile_of_poo:",
    "nfsw": false
}
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?