AllMyChangesミッション

私たちのプロジェクトがまだ始まったばかりのとき、それはほとんどすべてのライブラリでchangelogを見つけることができ、見つからない場合はコミットメッセージからビルドできるという仮説に基づいていました。 しかし、現実は私たちが望んでいたほどバラ色ではありませんでした：logい形式のchangelogファイルがキャッチされ、それが維持されなくなり、製品が開発中、または何か他のものです。 そして、世界を解析するだけでは十分ではないことを認識し、それを変更する必要があります。

瞬時に何かを変えることは非常に難しい作業です

したがって、私たちはそのような目標を設定していません。 AllMyChangesの使命は、世界中の開発者にChangeLog



がブログやtwitterアカウントと同じチャンネルである外の世界と対話する方法であることを理解させることです。







サービスが登場する前は、更新を購読する方法がなかったため、単純なChangeLogとブログを比較することは困難でした。 結局のところ、rssブログフィードへのリンクをrssリーダーに投げることができ、人をフォローすることでソーシャルプロフィールを購読することができ、ライブラリの変更を購読することは困難でした。



この問題を認識している一部の開発者は、ブログを使用してライブラリまたはAPIのユーザーとのコミュニケーションを構築しようとしています。 そこで彼らはリリースについて書いており、時にはシールやその他のニュースを投稿しているかもしれません。 しかし、そうする人はほとんどいません。オープンソースライブラリごとにブログを維持するのは非常に高価であり、ご存知のとおり、はるかに簡単です

ChangeLog.md



ファイルにセクションを追加し、リポジトリにコミットします。



GitHubは、その一部として、リポジトリを中心に構築されたコミュニケーションのためのインターフェイスを開発者に提供しようとしています。 GitHub Releasesと呼ばれます 。 これは次のように機能します。バージョンにgitタグを追加し、ChangeLogを追加する代わりに、GitHubインターフェイスに移動して、リリースで発生した内容の説明を追加します。 これらすべてに、たとえば、さまざまなプラットフォーム用に収集されたバイナリアーティファクトを添付できます。 GitHubリリースを使用して作成されたリリースでは、RSSフィードが生成されます。SibbellやAllMyChangesなどのサードパーティサービスを除き、プロジェクトニュースを購読する他の方法はありません。 確かに、SibbelはGitHubリリースでのみ機能し、AllMyChangesにはそのような制限はなく、どのソースでも機能します。



ところで、私たちの推定によると、AllMyChangesに追加されたすべてのプロジェクトの約10％は、すでにgithubのリリースサービスを使用しています。 そのため、最近、GitHubリリースを別のデータソースとしてサポートしました。 それらは右側の細いパイプに入ります：

コミュニケーションが私たちのすべてです。

API開発者の間には、通信チャネルに対する大きなニーズがあります。 彼らの多くはこれを認めたくなく、あらゆる点でAPIの変更内容と変更に関する情報を隠しますが、ユーザーとの定期的なやり取りだけで開発者の健全なコミュニティを構築できることを理解している善人もいます。



ところで、モバイルアプリケーション市場でも同様の状況が生じています。 多くの企業は現在、リリースノーツが優れたコミュニケーションチャネルであることを認識し、ソフトウェアの変更に関する重要な情報を送信するだけでなく、ユーザーを楽しませることを目的の目的に使用し始めています。 たとえば、 SlackとTrelloの開発者が書いているものを参照してください。



そのため、AllMyChangesの使命は、リリースノートに「このアップデートにはマイナーな改良が含まれています」と書いて、達成感を持って眠りにつく人の数を減らすことです。 それらの中にいるのではなく、ユーザーに何が起こっているのかを伝え、AllMyChangesのChenglogの更新を購読するように促します。