個人的には付けても付けなくてもどちらでも良いくらいの運用で良いかなーと思っています。
将来的には重要な Issue が分かりやすいようにラベル付けることは考えています。
x64 を作ってみました。
https://github.com/sakura-editor/sakura/labels/x64
デフォルトで入っている使わなそうなラベルを削除しました。
必要なものだけ随時追加していくようにしましょう。
label license を足しませんか?
label installer を足しませんか?
必要と判断したラベルは好きに足してしまって良いです。事後申告で。
後から煩雑になってきたな~と感じるタイミングがあったらそのときに突っ込みます。
迷いがあるようなものがあれば事前相談くらいの感じで良いかと。
document
installer
license
management
refactoring
research
specification change
を追加しました。
めちゃくちゃ増やしましたね。目がチカチカしません?
フィルタリングしやすいかと
さらに CI (appveyor 関連) も足しました。
CI 追加は良いと思います。
他ラベルについては今はノーコメントで。
ラベル多すぎるとラベル選ぶときに迷うというデメリットがあります。
GitHubの習慣なのかもしれませんが、ちかちかするぐらいいろんな話がごっちゃにポストされてるのもどうかなって思っとります、純粋にここには、sakura.exeの話題だけになればあまりLabelでちかちかしなくて、たとえば、Installの話は、
https://github.com/sakura-editor/installer/issues
こっちにいれればここでは話さなくていいんじゃねとか。
Web運用系の話は、
https://github.com/sakura-editor/sakura-editor.github.io/issues
こっちじゃねとか。
ただあっちこっち見ないといけなくなるのでしょうかねそうすると。
一覧でみるにはここに全部書いてあって、適切にLabelがついててふるいにかけられるほうがいいかもしれませんが、今のところ気づいた人がちまちまLabelつけてても廻る範囲かなって思います。
あ、すみません、installer については sakura 側に統合されたのでリポジトリは消しちゃうつもりでしたが単に消し忘れです。
作業効率を考えて web と bregexp 以外のリポジトリは sakura に集約しちゃう方針なのです。
自分の考えとしては、今の時期は移行直後なので例外として issues ポコポコ立ってますが、平常運転時にはそこまで様々なカテゴリの話が乱立しないと思っています。出てくるのはだいたいバグ報告か機能追加でしょう。それ以上細かい粒度のラベリングは不要と考えています。
CI は別軸なので残すの良いと思いますが、management 的なラベルに吸収するくらいでも良いと思っています。
@kobake さんへ、なるほどです。
このあたり使い分けとかまだ探り探りなので、吸収させていただきますです。
とりあえずラベルは既に運用開始されているのでこの Issue の Close 条件はほぼほぼ満たされていると思います。
が、この Issue を Close したとして、今後の「こういうラベル追加しました」みたいなちょっとした連絡はどこに書くのが適切ですかね。ラベル追加に限らずちょっとした連絡全般を書く場について。
いくつか案は出しておきますが、もっと良い案あればください。
ちなみにこれが「仕事」であれば僕は (案4) を採用します。
Slackって後から参加しても過去にさかのぼれるでしたっけ。
Team Discussionは役割がかぶりますよねぇ。同じ理由でOSDNはもうエンドユーザとの情報交換にしぼったほうがいいきがしています(あっちの会議室の開発管理フォーラム消してもいいかなと、開発メンバーもOSDNにアカウント無い人もいますし)
通知って意味なら、Notificationsに表示される何かであればなんでも良い気がしてるのですが、そもそも未読を0にしない人もいるみたいだし。。。
Issueはやっぱりそこに的があると当てたくなるのが性(サガ)なので、消したいですよね。
うちの会社メンバー(仕事場がバラバラ)だと、チーム共通のグランドルール掲示板(ポータルRedmineだったり、客先だとExcelだったりします)でWhat's Newお知らせ&MLへメール流すです。
掲示板っていうとここだとWikiっすかね、Wikiページの更新をウォッチしてNotificationsとかに表示されるといいのかな。
Issueって運用系ってあまり混ざらない方がいいのかなってのも同意です。
ご意見ありがとうございます :)
Slackって後から参加しても過去にさかのぼれるでしたっけ。
遡れるはず…ですがちょっとあとで確認し直してみます
掲示板っていうとここだとWikiっすかね、Wikiページの更新をウォッチしてNotificationsとかに表示されるといいのかな。
一方的な告知であれば Wiki もアリですが、どちらかというと相互にコメントし合える場が欲しいですねぇ
引き続きいろいろご提案お待ちしてます!
Slackって後から参加しても過去にさかのぼれるでしたっけ。
無料だと遡れる期間だか件数だかに制限があります。
https://qiita.com/methane/items/78a90c6efb1a7c4da57d
の記事では別のリポジトリを作って、フォーラムを
提供する方法を提案しています。
(オリジナルは https://medium.com/@methane/why-you-must-not-ask-questions-on-github-issues-51d741d83fde)
あと、https://gitter.im/ も紹介しています。
Discord も良さそうです。Slack ライクなインターフェースのオープンなチャット場。
↓は試しに作ってみたサクラエディタチャンネルです。
https://discord.gg/MTWB4ut
名前だけ入力すれば即入室可能。追加でメールアドレスとパスワードを登録するとスマホアプリからも操作可能。Slack よりも参入ハードル低そう。
ログは無期限保存の模様。情報源は reddit ですが。
https://www.reddit.com/r/discordapp/comments/6vu7mz/for_how_long_are_chat_logs_saved/
Gitter はちょっと触ってみたのですが個人的には画面がゴチャゴチャしていて初見としてはちょっと抵抗ありました。慣れの問題だと思いますが。
Slack引っ越しですかね?
Discordでもいいかもしれませんが、さすがにおなか一杯気味なので、
情報交換専用リポジトリ作ってでIssueで通知でもいいかなぁなんて。
名前は、ryouzanpakuとかtoranoanaとかtreasureboxでもいいですが、べたにinformationっすかね。
Discord はあくまでもひとつの検討材料としての実験場です。
リポジトリでやるとしたら名前は
information
forum
discussion
あたりですかねぇ
今話している本題ではないのですが、ちょっとしたつぶやきの場という意味でのチャットは運用続けていきたいと思っています(今は Slack ですが Discord のほうが良さそうであればそっちに引っ越しも検討)
はい、この前はチャットで助かりましたのであったほうがうれしいです。
Team Discussionは一般公開できないのか・・・
Slackはかなりクローズドなので、Discordの方がマシだとは思います。
なんか、もっと簡単な(ROMや通りすがりの人にも優しい)チャットツールの選択肢はないものか・・・
すみません、もともとの Issue の本題から逸れすぎたので別 Issue を立てました。
本 Issue はラベルの話ということで運用が始まった以上は帰着したのでクローズします。
掲示板・チャットの運用についての話は以下 Issue に場を移しましょう。