Book Corners が OpenStreetMap に貢献を同期しない理由

Book Corners に機能を追加する際に、当初は非常に良い考えだと思われました。 私が Book Corners を紹介したとき、その初期データの多くが OpenStreetMap (OSM) から来ていることを説明しました。OSM は、世界中で何千もの公共の書架がすでにマッピングされており、このプロジェクトに有用な出発点を提供してくれました。 Book Corners はユーザーから直接新しい書架情報も受け付けています。人々は場所と写真を提供でき、その貢献はモデレーション後に公開されます。 それらの投稿のうちのいくつかが OSM にない場合、Book Corners がそれを OSM に貢献できれば、それは公正なことのように思われました。 このアイデアは、制御されないバックグラウンド同期プロセスを作成することではありませんでした。 私が考えていたワークフローは、意図的に慎重なものでした。 1. 書架を投稿する人は、明示的に貢献を許可する。 2. 管理者が最初に書架をレビューする。 3. Book Corners は重複がないか OSM を検索する。 4. 管理者は送信される正確なデータをプレビューする。 5. 管理者が確認するまで何も書き込まれない。 ソフトウェア開発の観点からは、これは管理可能な統合のように見えました。同意の追加、貢献状態の追跡、プレビューの構築、OSM との認証、API を通じた新機能の作成です。 コードは難しい部分ではありませんでした。 データを貢献することは、単なる API 呼び出しではありません。 実装を適切に調査し始めると、API への書き込みは作業のほんの一部にすぎないことがわかりました。 情報は Book Corners のデータベースから来るため、OSM はそれを外部データインポートと見なす可能性があります。 ソフトウェアが変更を準備して送信するため、管理者が個々の書架をレビューする場合でも、スクリプト支援または自動編集のルールに該当する可能性があります。 OSM インポートガイドラインと自動編集行動規範の保守的な解釈に従うには、専用のアカウントと OAuth トークン以上のものが必要になります。 最初の本番貢献の前に、私は以下を行う必要がありました。 * 専用の OSM インポートアカウントを作成し、維持する。 * OSM Wiki に詳細なインポート計画を公開する。 * データソース、ライセンス、フィールドマッピング、重複検出、ソフトウェア、品質チェック、変更セットポリシー、ロールバック手順を文書化する。 * OSM コミュニティフォーラムで提案を開く。 * 貢献の影響を受ける関連するローカルコミュニティに連絡する。 * レビュー期間を経て、懸念事項を解決する。 * インポートアカウント、計画、議論、変更セット間の永続的なリンクを維持する。 * 将来の質問や苦情のための連絡先およびオプトアウトルートを維持する。 ライセンスに関する重要な問題もあります。 ユーザーが書架を OSM に送信する許可は、必ずしもその事実情報を OSM と互換性のある条件で公開するための十分な明確な権利を持っていることと同じではありません。 ユーザー向けの解説と同意は、その区別をカバーする必要があり、情報が互換性のないソースからコピーされたものではないことを確認することも含みます。 これらの要件は、一度完了して忘れるような一時的なフォームではありません。 それらは、アカウント、文書化されたプロセス、コミュニティのフィードバック、失敗、および潜在的なロールバックに関する継続的な責任を生み出します。 なぜこれらのルールが存在するのか理解しています。 OpenStreetMap は共有されるグローバルデータベースです。 悪いインポートは、何千もの重複を作成したり、より良いローカル知識を上書きしたり、他の人が同じオブジェクトを編集した後に削除が困難なエラーを導入したりする可能性があります。 その観点から、文書化、ライセンスの明確さ、重複処理、説明責任のあるオペレーター、およびコミュニティの議論を要求することは合理的です。 OSM コミュニティは、マップの品質を保護しなければなりません。善意だけでは良いデータを保証できません。 Book Corners 自体も、そのデータ品質の恩恵を受けてきました。 OSM が、セーフガードなしで外部サービスからの変更を受け入れることを期待するのは偽善的でしょう。 同時に、このプロセスには実際のコストがかかります。 それは、小規模なプロジェクトに API クライアントになるだけでなく、文書化されたインポートプログラムのオペレーターになることを要求します。 これは大規模なデータセットをインポートする組織には適切かもしれませんが、慎重にレビューされた少数の公共の書架をコモンズに貢献することだけを目的とした低ボリュームの機能にとっては、かなりのコミットメントです。 運用作業が価値を上回る。 Book Corners にはシンプルな目的があります。人々がリトルフリーライブラリを発見し、新しいものを他の人と共有するのを助けることです。 OSM 貢献パイプラインの運用は、その目的に中心的なものではありません。 認証情報、本番環境のセーフガード、監査および照合コード、コミュニティプロセス、ライセンス作業、および長期サポート義務が追加されます。 各部分は個別に正当化できますが、それらを合わせると、当初意図していたよりもはるかに大きな機能になります。 機会費用もあります。 この統合の運用に費やされた時間は、書架の発見、モデレーション、写真、アクセシビリティ、翻訳、またはモバイルエクスペリエンスの改善に費やされる時間ではありません。 これらの改善は Book Corners ユーザーに直接役立ち、小規模プロジェクトが維持するのははるかに容易です。 貢献し返すことは、単純に親切で公正なことだという感情から始めました。 それを調査した後、善意だけでは無期限の運用責任を受け入れる十分な理由にはならないと考えるようになりました。 決定 OSM への書き戻し実装を無期限に一時停止することにしました。 Book Corners は、OSM からインポートされたレコードのソースとして OSM を引き続き認識し、OSM からインポートされた書架は新しいものとして再度送信されることはありません。 しかし、Book Corners に直接投稿された書架は Book Corners に残ります。サービスは、一致する OSM オブジェクトを自動的または手動で作成しません。 現在、Book Corners から本番の OSM に書き込むものはありません。そのため、作業を一時停止しても、既存の統合を無効化したり移行したりする必要はありません。 本当に軽量なワークフローが利用可能になった場合、または Book Corners の貢献の規模と価値が最終的にプロセスを正当化するようになった場合は、この決定を再考するかもしれません。 別の可能性としては、ユーザー主導のワークフローで既存の OSM エディタに提案された機能を開くことが考えられますが、それでもルールを回避する方法としてではなく、コミュニティと議論する必要があります。 今のところ、責任ある選択は、適切にサポートできると確信していない機能を構築・運用しないことです。 時には、正しい機能とは機能がないこと。 実装の決定を純粋に技術的なものとして考えるのは簡単です。API はそれを実行できるか、アプリケーションは認証できるか、コードは重複を回避できるか？ この経験は、外部統合にも組織的および社会的な契約が伴うことを思い出させてくれました。 時には、それらの契約はコードよりも高価になります。 展開前にそれを発見することは、結果が残念であっても有用です。 共有プロジェクトにデータを貢献することは依然として価値があると思います。 また、OSM がデータベースを非常に注意深く保護している理由も理解しています。 しかし、Book Corners にとっては、現在の規模では、利益と責任のバランスが取れていません。 したがって、これは私が提供しないことを選択した機能の1つです。