<?xml version="1.0" encoding="utf-8"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/">
    <channel>
        <title>Creative Commons Open Source Blog (日本語翻訳)</title>
        <link>http://opensource.creativecommons.org/</link>
        <description>Creative Commons Open Source Blog の日本語翻訳フィード</description>
        <lastBuildDate>Wed, 29 Jul 2026 23:18:09 GMT</lastBuildDate>
        <docs>https://validator.w3.org/feed/docs/rss2.html</docs>
        <generator>https://github.com/jpmonette/feed</generator>
        <language>ja</language>
        <item>
            <title><![CDATA[Sunsetting api.creativecommons.org]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2026-05-06-sunsetting-api/</link>
            <guid isPermaLink="false">urn:uuid:6792d0e4-fa95-3111-820d-2d226beb749a</guid>
            <pubDate>Wed, 06 May 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[Creative Commons (CC)は、api.creativecommons.orgサービスを2026年11月2日に終了することを決定しました。ただし、ホスティングやソフトウェアの故障により、その日より前にサービスが利用できなくなる可能性があることに注意してください。

削除理由：このAPIは、2023年9月27日に現在のCC Legal Toolsに置き換えられた旧ccEngineに依存しています。これ以上維持することが難しくなっています。また、APIをホスティングするインフラストラクチャもサポートされていません。提供されるデータはあまり変更されないため、APIが最適なソリューションではないと判断されています。

次の一歩：既存のflat filesを使用してAPIを置き換えることを評価してください: creativecommons.org/rdf/index.rdf このccRELファイルは長く存在していますが、これまでにあまり注目されていませんでした。2023年9月から新しいCC Legal Tools Appによる静的サイト生成が始まり、その正確性が大幅に向上しました。

creativecommons/cc-legal-tools-data: config/cc-legal-tools.csv このファイルは今年新しく追加されました。このファイルの生成はCC Legal Tools Appで変更可能であり、必要な追加データや異なるフォーマットが必要な場合は新しいファイルを生成することができます。

DSpaceを使用している場合：api.creativecommons.orgを置き換える方法については、DSpace/DSpace#11808をご覧ください。懸念点や継続的なコミュニケーションの要請がある場合は、以下のフォームを使用してください: Sunsetting api.creativecommons.org feedback.

関連ブログ記事：
2024-05-28: 新しいCreativeCommons.orgがリリースされました。
2023年9月: 現在のライセンスツールの概要。
2011-08-31: CC REST APIがPublic Domain Markに対応しました。
2009-04-02: CC Web Servicesにおける列挙記述。
2008-07-24: cc.licenseのアルファ版。]]></description>
            <content:encoded><![CDATA[Creative Commons (CC)は、api.creativecommons.orgサービスを2026年11月2日に終了することを決定しました。ただし、ホスティングやソフトウェアの故障により、その日より前にサービスが利用できなくなる可能性があることに注意してください。

削除理由：このAPIは、2023年9月27日に現在のCC Legal Toolsに置き換えられた旧ccEngineに依存しています。これ以上維持することが難しくなっています。また、APIをホスティングするインフラストラクチャもサポートされていません。提供されるデータはあまり変更されないため、APIが最適なソリューションではないと判断されています。

次の一歩：既存のflat filesを使用してAPIを置き換えることを評価してください: creativecommons.org/rdf/index.rdf このccRELファイルは長く存在していますが、これまでにあまり注目されていませんでした。2023年9月から新しいCC Legal Tools Appによる静的サイト生成が始まり、その正確性が大幅に向上しました。

creativecommons/cc-legal-tools-data: config/cc-legal-tools.csv このファイルは今年新しく追加されました。このファイルの生成はCC Legal Tools Appで変更可能であり、必要な追加データや異なるフォーマットが必要な場合は新しいファイルを生成することができます。

DSpaceを使用している場合：api.creativecommons.orgを置き換える方法については、DSpace/DSpace#11808をご覧ください。懸念点や継続的なコミュニケーションの要請がある場合は、以下のフォームを使用してください: Sunsetting api.creativecommons.org feedback.

関連ブログ記事：
2024-05-28: 新しいCreativeCommons.orgがリリースされました。
2023年9月: 現在のライセンスツールの概要。
2011-08-31: CC REST APIがPublic Domain Markに対応しました。
2009-04-02: CC Web Servicesにおける列挙記述。
2008-07-24: cc.licenseのアルファ版。]]></content:encoded>
            <author>['TimidRobot']</author>
        </item>
        <item>
            <title><![CDATA[仕事プログラムの優先度を下げる]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2026-03-11-deprioritizing-work-programs/</link>
            <guid isPermaLink="false">urn:uuid:20dc8fc5-21aa-355d-a420-ef3ab8b945a1</guid>
            <pubDate>Wed, 11 Mar 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[残念ながら、Creative Commons (CC) は、Google Summer of Code (GSoC) や Outreachy のような将来のワークプログラムに参加する予定はありません。テクノロジーチームは、これらの価値あるプログラムと、それらがもたらした多くの貢献者、インターンシップ生、ボランティアに対して感謝しています。それでも、私たちのコミュニティからの貢献は、それらを記録する能力を超えており、その歴史については Creative Commons Open Source の「Open Source Work Programs: History」をご覧ください。これらのワークプログラムが解決しようとした問題や課題は、テクノロジー業界の変化とともに増加し続けています。しかし、それらのミッションは今も以前と同様に重要です。その価値が継続的に認識されることを望みます。私たちの立場としては、これらのワークプログラムとの関わりで開発したリソースが他の人々にも役立つことを願い、いつか再び参加できる日が来るよう希望しています。]]></description>
            <content:encoded><![CDATA[残念ながら、Creative Commons (CC) は、Google Summer of Code (GSoC) や Outreachy のような将来のワークプログラムに参加する予定はありません。テクノロジーチームは、これらの価値あるプログラムと、それらがもたらした多くの貢献者、インターンシップ生、ボランティアに対して感謝しています。それでも、私たちのコミュニティからの貢献は、それらを記録する能力を超えており、その歴史については Creative Commons Open Source の「Open Source Work Programs: History」をご覧ください。これらのワークプログラムが解決しようとした問題や課題は、テクノロジー業界の変化とともに増加し続けています。しかし、それらのミッションは今も以前と同様に重要です。その価値が継続的に認識されることを望みます。私たちの立場としては、これらのワークプログラムとの関わりで開発したリソースが他の人々にも役立つことを願い、いつか再び参加できる日が来るよう希望しています。]]></content:encoded>
            <author>['TimidRobot']</author>
        </item>
        <item>
            <title><![CDATA[The Commonsの量化: 一時代の終焉]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2026-30-03-the-end-of-an-era/</link>
            <guid isPermaLink="false">urn:uuid:eaec2419-2ad5-3631-9f37-b781c05ce43d</guid>
            <pubDate>Tue, 03 Mar 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[The Commonsの量化: 一時代の終焉
敬愛する読者へ、これは私のメンターたちと共に素晴らしい旅を終えた瞬間であり、グローバルな舞台で成長を目指す若きデータプロフェッショナルとして新たな始まりです。このプロジェクトがクリエイティブコモンズのオープンソースコミュニティにおいて成熟したプロジェクトとなったことを目の当たりにし、不思議な感覚を覚えています。The Commonsの量化はさらに発展していますので、Creative Commonsでの異なるチームにおけるその影響をご期待ください。
振り返ると、Timid RobotとSaraとの初めてのミーティングでは非常に緊張していました。プロジェクトの自動化部分について理解が不十分で、スクリプトがどのくらい実行されるのか、なぜそうなのか分からなかったのです。しかし、Timid Robotからの詳細な説明を受けてシステム全体のプロセスに興奮し、設計思考に感銘を受けました。プロジェクトリーダーと以前の貢献者たちには大きな感謝の意を表します。彼らが築いた基盤はしっかりとしており、私の作業をより楽しく価値あるものにしてくれました。
1日目は素晴らしい出来事でした、90日目は成長です。コードベースで使用される概念に戸惑っていた私が、システムの自動化プロセス改善に関するアイデアを提案するまでになりました。私は記事を読み続け、テストを行い、機能とメカニズムを改良しました。データ構造やアルゴリズムスキルを向上させ、テストケース、制限、リスクに対応する必要がありました。システムがAPIから得られるライブで動的なデータにさらされているため、変化に対するリスクも考慮しました。
このインターンシップの最初の半分ではこのようなことを行いました。次回のブログ記事では、残りの半分について書きます。プロジェクトの大半は、データの整合性と自動化プロセスの効率を保つことです。
Smithsonian四半期レポートの自動化
Smithsonianはアメリカで最大の公共機関の一つです。私がこのプロジェクトに携わった時には38のユニット/データソース（博物館、動物園、図書館など）がありました。CC0ライセンスがメディア記録とメディアなしの記録における使用状況について洞察を得ました。これにより、レポートシステムの可視化に水平な積み棒グラフを追加しました。これにより、CC0ライセンスを持つ記録の分布を見ることができます。また、上位10のユニットと下位10のユニットの分布も調査しました。これはこれらの機関でCC0ライセンスがどの程度使用されているかを示しています。
ワークフロー全体を複数回テストした後、ユニットコードが頻繁に更新されることが分かりました（追加または削除）。これに対応するための機能を開発し、次回の自動化プロセスでの変更について警告が出るようにしました。これはその時点では最も効果的な方法であり、データを予測可能で最新に保つことができました。
arXiv四半期レポートの自動化
arXivは500万人以上の月間アクティブユーザーを持つキュレーションされた研究共有プラットフォームです。260万件の研究論文をホストしています。このデータソースから非常に興味深い洞察を得ました。plot.pyで折れ線グラフと垂直な積み棒グラフの機能を追加することで、可視化コレクションを拡大しました。洞察には年次ベースでの法的ツールの数や、過去数年のツールに関する比較分析が含まれます。また、これらのツールの使用状況を異なるカテゴリーで分解することも調査しました。
学んだこと
問題解決時に構造を作成する重要性について多く学びました。これによりデバッグが容易になり、将来的な貢献者にとって詳細なワークフローが理解しやすくなります。これは変数の名付け方や関数での使用方法にまで及びます。また、「なぜ」を常に問うことが大切であることも学びました。Timid Robotは私に仮定を疑い、決定の理由を理解するよう奨励しました。これがインターンシップ全体を通じて楽しく謎解きのようなものとなった最大の要因でした。
次は何が待っているのか！
私は今後もこのプロジェクトでボランティアとして時間を提供したいと思っています。また、研究、ビッグデータ、自動化に関連する他のオープンソースプロジェクトにも興味があり、これらのスキルセットをアクチュアリー科学の背景とさらに統合していきたいと考えています。
さようなら
私はメンターたちとの仕事にとても楽しんでいました。休暇や天気、旅行についての小さな会話が懐かしいです。将来また再開できる日を楽しみにしています。]]></description>
            <content:encoded><![CDATA[The Commonsの量化: 一時代の終焉
敬愛する読者へ、これは私のメンターたちと共に素晴らしい旅を終えた瞬間であり、グローバルな舞台で成長を目指す若きデータプロフェッショナルとして新たな始まりです。このプロジェクトがクリエイティブコモンズのオープンソースコミュニティにおいて成熟したプロジェクトとなったことを目の当たりにし、不思議な感覚を覚えています。The Commonsの量化はさらに発展していますので、Creative Commonsでの異なるチームにおけるその影響をご期待ください。
振り返ると、Timid RobotとSaraとの初めてのミーティングでは非常に緊張していました。プロジェクトの自動化部分について理解が不十分で、スクリプトがどのくらい実行されるのか、なぜそうなのか分からなかったのです。しかし、Timid Robotからの詳細な説明を受けてシステム全体のプロセスに興奮し、設計思考に感銘を受けました。プロジェクトリーダーと以前の貢献者たちには大きな感謝の意を表します。彼らが築いた基盤はしっかりとしており、私の作業をより楽しく価値あるものにしてくれました。
1日目は素晴らしい出来事でした、90日目は成長です。コードベースで使用される概念に戸惑っていた私が、システムの自動化プロセス改善に関するアイデアを提案するまでになりました。私は記事を読み続け、テストを行い、機能とメカニズムを改良しました。データ構造やアルゴリズムスキルを向上させ、テストケース、制限、リスクに対応する必要がありました。システムがAPIから得られるライブで動的なデータにさらされているため、変化に対するリスクも考慮しました。
このインターンシップの最初の半分ではこのようなことを行いました。次回のブログ記事では、残りの半分について書きます。プロジェクトの大半は、データの整合性と自動化プロセスの効率を保つことです。
Smithsonian四半期レポートの自動化
Smithsonianはアメリカで最大の公共機関の一つです。私がこのプロジェクトに携わった時には38のユニット/データソース（博物館、動物園、図書館など）がありました。CC0ライセンスがメディア記録とメディアなしの記録における使用状況について洞察を得ました。これにより、レポートシステムの可視化に水平な積み棒グラフを追加しました。これにより、CC0ライセンスを持つ記録の分布を見ることができます。また、上位10のユニットと下位10のユニットの分布も調査しました。これはこれらの機関でCC0ライセンスがどの程度使用されているかを示しています。
ワークフロー全体を複数回テストした後、ユニットコードが頻繁に更新されることが分かりました（追加または削除）。これに対応するための機能を開発し、次回の自動化プロセスでの変更について警告が出るようにしました。これはその時点では最も効果的な方法であり、データを予測可能で最新に保つことができました。
arXiv四半期レポートの自動化
arXivは500万人以上の月間アクティブユーザーを持つキュレーションされた研究共有プラットフォームです。260万件の研究論文をホストしています。このデータソースから非常に興味深い洞察を得ました。plot.pyで折れ線グラフと垂直な積み棒グラフの機能を追加することで、可視化コレクションを拡大しました。洞察には年次ベースでの法的ツールの数や、過去数年のツールに関する比較分析が含まれます。また、これらのツールの使用状況を異なるカテゴリーで分解することも調査しました。
学んだこと
問題解決時に構造を作成する重要性について多く学びました。これによりデバッグが容易になり、将来的な貢献者にとって詳細なワークフローが理解しやすくなります。これは変数の名付け方や関数での使用方法にまで及びます。また、「なぜ」を常に問うことが大切であることも学びました。Timid Robotは私に仮定を疑い、決定の理由を理解するよう奨励しました。これがインターンシップ全体を通じて楽しく謎解きのようなものとなった最大の要因でした。
次は何が待っているのか！
私は今後もこのプロジェクトでボランティアとして時間を提供したいと思っています。また、研究、ビッグデータ、自動化に関連する他のオープンソースプロジェクトにも興味があり、これらのスキルセットをアクチュアリー科学の背景とさらに統合していきたいと考えています。
さようなら
私はメンターたちとの仕事にとても楽しんでいました。休暇や天気、旅行についての小さな会話が懐かしいです。将来また再開できる日を楽しみにしています。]]></content:encoded>
            <author>['Oreoluwa']</author>
        </item>
        <item>
            <title><![CDATA[Commonsの量化: Outreachyでの私の旅]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2026-01-22-My-outreachy-journey/</link>
            <guid isPermaLink="false">urn:uuid:38874a7e-4773-3892-96e6-17e26e362452</guid>
            <pubDate>Thu, 22 Jan 2026 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは！ナイジェリア出身のOreoluwaです。私はCreative Commonsで2025年12月期のOutreachyインターンシップに参加しています。私のプロジェクトは、Quantifying the commonsを改善し拡大することに関わっています。この投稿では、インターンシップの最初の半分での進捗と重要な教訓について共有します。

プロジェクト概要：
Quantifying the commonsは、Creative Commonsの法的ツールのトレンドを追跡および分析するための取り組みです。これらの法律ツールを使用しているのは誰で、どこで、なぜ、どのように使用されているのか？これらのツールの影響を測定することを目指しています。

組織は25年以上にわたり、インターネット上の知識とコンテンツの民主化に努めてきました。私たちが成長した部分や改善すべき領域を見つけることを目指しています。

短い歴史：
私のメンターから推薦されたドキュメンタリーを見てAaron Schwartzという偉大な人物を知りました。彼は「インターネットの少年」とも呼ばれ、知識は誰でも自由にアクセスできるべきだと信じていました。彼のアイデアはCreative Commonsのような運動をインスピレーションとしています。

プロジェクトにおける進捗：
プロジェクトをスクリプト要件に合わせて改善するため、スクリプトが再現可能であることを確保するためにGithub Actionsを使用してPythonスクリプトを自動化しています。また、スクリプトの効率性を高めるために、タスクが既に完了している場合や複数回実行が必要な場合は適切な場所から継続できるようにしました。

プロジェクトドキュメンテーション：
貢献者の経験を改善することはこのプロジェクトの大切な部分です。Outreachyの貢献フェーズでは、新しい貢献者が同じ質問を何度も繰り返し聞くことがありました。そのため、Timid Robotと私は情報が不足している箇所を見つけ出し、より明確な文脈を追加しました。

現在の状況：
私は他のデータソースのプロセスとレポートステージを完成させています。そして新しいデータソースを追加してプロジェクトを拡大しています。

メンターとの協力：
私の好きな部分は毎週のミーティングで、質問をしたりアイデアを得たりすることです。また、彼らの作業をレビューすることで学び、自分の貢献に取り入れています。

重要な教訓：
オープンソースは私の技術的な旅の中で最も素晴らしい経験の一つでした。新しいプログラミング言語を習得しスキルセットを拡大することができました。制約や限界が結果に影響を与える場合、最適な解決策を見つける方法も学びました。

次半期への期待：
このプロジェクトでさらに貢献したいと思っています。]]></description>
            <content:encoded><![CDATA[こんにちは！ナイジェリア出身のOreoluwaです。私はCreative Commonsで2025年12月期のOutreachyインターンシップに参加しています。私のプロジェクトは、Quantifying the commonsを改善し拡大することに関わっています。この投稿では、インターンシップの最初の半分での進捗と重要な教訓について共有します。

プロジェクト概要：
Quantifying the commonsは、Creative Commonsの法的ツールのトレンドを追跡および分析するための取り組みです。これらの法律ツールを使用しているのは誰で、どこで、なぜ、どのように使用されているのか？これらのツールの影響を測定することを目指しています。

組織は25年以上にわたり、インターネット上の知識とコンテンツの民主化に努めてきました。私たちが成長した部分や改善すべき領域を見つけることを目指しています。

短い歴史：
私のメンターから推薦されたドキュメンタリーを見てAaron Schwartzという偉大な人物を知りました。彼は「インターネットの少年」とも呼ばれ、知識は誰でも自由にアクセスできるべきだと信じていました。彼のアイデアはCreative Commonsのような運動をインスピレーションとしています。

プロジェクトにおける進捗：
プロジェクトをスクリプト要件に合わせて改善するため、スクリプトが再現可能であることを確保するためにGithub Actionsを使用してPythonスクリプトを自動化しています。また、スクリプトの効率性を高めるために、タスクが既に完了している場合や複数回実行が必要な場合は適切な場所から継続できるようにしました。

プロジェクトドキュメンテーション：
貢献者の経験を改善することはこのプロジェクトの大切な部分です。Outreachyの貢献フェーズでは、新しい貢献者が同じ質問を何度も繰り返し聞くことがありました。そのため、Timid Robotと私は情報が不足している箇所を見つけ出し、より明確な文脈を追加しました。

現在の状況：
私は他のデータソースのプロセスとレポートステージを完成させています。そして新しいデータソースを追加してプロジェクトを拡大しています。

メンターとの協力：
私の好きな部分は毎週のミーティングで、質問をしたりアイデアを得たりすることです。また、彼らの作業をレビューすることで学び、自分の貢献に取り入れています。

重要な教訓：
オープンソースは私の技術的な旅の中で最も素晴らしい経験の一つでした。新しいプログラミング言語を習得しスキルセットを拡大することができました。制約や限界が結果に影響を与える場合、最適な解決策を見つける方法も学びました。

次半期への期待：
このプロジェクトでさらに貢献したいと思っています。]]></content:encoded>
            <author>['Oreoluwa']</author>
        </item>
        <item>
            <title><![CDATA[生成AI開発ツールの回避]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2025-12-01-avoiding-gen-ai-tools/</link>
            <guid isPermaLink="false">urn:uuid:ad0d890c-6979-302d-a258-cfa4e0dfd274</guid>
            <pubDate>Mon, 01 Dec 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[現在、Creative Commons (CC) Technologyチームは、生成AI開発ツールがオープンソースプロジェクトへの貢献においてコストと利益の分析をパスしないことを結論付けています。今後、AIで生成されたコードやコンテンツを含むCCオープンソースの提出を受け付けません。過大評価された生成AIの生産性に関する主張はしばしば、その採用から実質的な利益を得る人々によって推進され（EditorDavid, 2025）、支払われます。デフォルトでAIツールが含まれている場合やオフにできない場合、採用率は選択肢の欠如により虚偽的に高められます。私たちは、その採用を支持する議論がしばしば「見逃すまい」という恐怖心や潜在的な将来の利益に訴えかけることに過ぎないと観察しています。「開発者がAIツールを使用すると、19%長くかかる」（METR, 2025）という最近のMIT NANDAからの報告書によると、「組織の95％が生成AIからゼロのリターンを得ている」とあります。AIツールはレビュー者に対して虚偽の作業を生み出します。たとえば、以下のようなAIスロップ提出に対するコメントがあります：このコードはcurlを呼び出しません。これは「POC」ではありません。あなたがAIを使用してこれをしたことを示すものではなく、ここで何をしているのか理解していないことを示しています。問題があるというあなたの主張の具体的なcurlソースコード行を特定してください。（badger, 2025）特に私たちの貢献者にとって、Google Summer of Code (GSoC)やOutreachyなどのワークプログラムに参加するとき、AIツールは間違ったスキルを訓練します。私たちは、オープンソースプロジェクトを支える技術を学んでいる貢献者を求めています。業界代表者の一人が学生に「デザイン思考と質問を投げかける能力」を持たせたいと言っているのを聞いたとき、彼が推奨するAIツールを使用することで学生の批判的思考スキルが阻害され、彼らが質問を投げかけたり興味深い「デザイン思考」を行うことが不可能になることを認識していません。（Valeries, 2025）責任と団結感に加えて、生成AI技術がどのように作成され、実装/展開されるかについての懸念もあります。生成AI開発ツールが実際に役立つ場合でも、Technologyチームは、他人を害する方法で開発されたツールや、他人を害する実装/展開によって資金提供を受けているツールを使用することにためらいを感じます。また、存続のコストがある短期的な利益を提供するツールも同様です。]]></description>
            <content:encoded><![CDATA[現在、Creative Commons (CC) Technologyチームは、生成AI開発ツールがオープンソースプロジェクトへの貢献においてコストと利益の分析をパスしないことを結論付けています。今後、AIで生成されたコードやコンテンツを含むCCオープンソースの提出を受け付けません。過大評価された生成AIの生産性に関する主張はしばしば、その採用から実質的な利益を得る人々によって推進され（EditorDavid, 2025）、支払われます。デフォルトでAIツールが含まれている場合やオフにできない場合、採用率は選択肢の欠如により虚偽的に高められます。私たちは、その採用を支持する議論がしばしば「見逃すまい」という恐怖心や潜在的な将来の利益に訴えかけることに過ぎないと観察しています。「開発者がAIツールを使用すると、19%長くかかる」（METR, 2025）という最近のMIT NANDAからの報告書によると、「組織の95％が生成AIからゼロのリターンを得ている」とあります。AIツールはレビュー者に対して虚偽の作業を生み出します。たとえば、以下のようなAIスロップ提出に対するコメントがあります：このコードはcurlを呼び出しません。これは「POC」ではありません。あなたがAIを使用してこれをしたことを示すものではなく、ここで何をしているのか理解していないことを示しています。問題があるというあなたの主張の具体的なcurlソースコード行を特定してください。（badger, 2025）特に私たちの貢献者にとって、Google Summer of Code (GSoC)やOutreachyなどのワークプログラムに参加するとき、AIツールは間違ったスキルを訓練します。私たちは、オープンソースプロジェクトを支える技術を学んでいる貢献者を求めています。業界代表者の一人が学生に「デザイン思考と質問を投げかける能力」を持たせたいと言っているのを聞いたとき、彼が推奨するAIツールを使用することで学生の批判的思考スキルが阻害され、彼らが質問を投げかけたり興味深い「デザイン思考」を行うことが不可能になることを認識していません。（Valeries, 2025）責任と団結感に加えて、生成AI技術がどのように作成され、実装/展開されるかについての懸念もあります。生成AI開発ツールが実際に役立つ場合でも、Technologyチームは、他人を害する方法で開発されたツールや、他人を害する実装/展開によって資金提供を受けているツールを使用することにためらいを感じます。また、存続のコストがある短期的な利益を提供するツールも同様です。]]></content:encoded>
            <author>['TimidRobot']</author>
        </item>
        <item>
            <title><![CDATA[新しいCC Chooserの再設計とリリース：パート2]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2025-10-06-refactoring-the-cc-chooser-pt-2/</link>
            <guid isPermaLink="false">urn:uuid:37b05421-d008-3d52-8984-d785641d4a38</guid>
            <pubDate>Mon, 06 Oct 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[このブログは、三部作の第2部で、「新しいCC Chooserの再設計とリリース」を扱います。Creative Commons Chooser 2025の再設計では、アプリケーション全体にわたる多くの改善が行われました。可能な限り、フットプリントや実装がより簡潔でシンプルになるよう考慮し、その上で作業を行いました。最終目標は、メンテナンスと進化において大幅に柔軟性を高めたアプリケーションを作成することです。

コア機能の再評価と使用：最初に、Chooserが提供すべき基本的な機能セットを理解し、再確立しました。2020年のベータ版Chooserで存在していた使用例から始めました：ライセンスの推奨を行う ライセンスおよびその特性/使用例についてユーザーに対して静かに教育する 著者であるユーザーがさまざまな形式で「マーク」を生成できるようにする（一般的にはライセンス要件を満たす） 再利用者/再ミキサーが適切な属性情報を提供されていない場合、属性マークを生成できるようにする

上記の4つの使用例から、1と2はChooserの元々のコア目標でした。使用例3は、適用をより容易にするためのメカニズムとして追加されましたが、著者が適切な属性情報を提供しない場合、再利用者/再ミキサーがライセンス条項の精神に従うことができない可能性があります（属性情報が必要）。属性詳細がオプションであることは事実ですが、それはライセンス推奨や静かな教育を妨げません。しかし、ユーザーが3を主要な使用例として期待している場合、属性詳細は必須となり、文脈的な期待と衝突します。

使用例4はChooserの意図ではありませんでしたが、著者が一般的なマークステートメントを使用するため、ユーザーが定期的にこれを利用しています。今後は、1から3までの使用例に焦点を当てることを目指し、Chooserの再設計初期のMVPスコープでは1を優先し、その後2と3をサポートする使用例として扱います。使用例4は主にサポートされない使用例ですが、より良いツールが登場するまでユーザーがこれを続けることを期待しています。

範囲を技術的方法に変換：Chooserは、ステッパーを通じて一連の質問と結果的な推奨を順次提示します。これらのパスウェイには、最初で分岐する2つの主要なブランチ（「ライセンスが必要ですか？はい/いいえ」）があり、必要なフィールドがすべて満たされると適切な推奨が提供されます。

その後、属性フィールドを入力し、マークセクションにデータを自動的に反映させることができます。つまり、ステッパーは技術的な機能の核心部分であり、それを安定化させることが最初の目標となります。if/elseやswitch文を使用して一連の論理ゲートを通じて推奨を生成する方法もありますが、Chooserの場合、すべての答えは既知です。

推奨は7つの可能な法的ツールのいずれかであり、「ライセンスが必要ですか？はい/いいえ」の質問からそれぞれのツールに到達する2つの主要なパスウェイがあります。この前提から逆算することで、これらのパスウェイを形式化し、完全な決定木を記述することができます。

これにより、特定のUXを通じて状態を一貫して記述できるようになり、フォームを設定して質問に答えることで状態パスを作成します。完全なパスが可能となると推奨が正確に出力されます。それ以外は未知として扱います。

これにより、単純なステートマシンの設定から始めることができ、特定のイベントでチェックし、推奨やインターフェースを更新することができます。

JavaScriptのフットプリントとオーバーヘッドの削減：複雑な状態管理エンジンが不要になったため、Vue.jsのようなより大きなフレームワークから離れ、単一のvanilla JavaScriptファイルを使用する新しい2025年版Chooserを実装しました。これによりJavaScriptの量は約98%削減されました。

この結果、依存関係チェーンも大幅に削減され、Chooserがより安全で安定し、維持しやすくなります。SCCツールを使用すると、新しい再設計は開発に6.02ヶ月と1.68人の人材が必要であり、費用は$113,716になると推定されます。

再設計の計画は2024年に始まりましたが、コード完成までには約3ヶ月かかりました（予想時間の半分）。一方、元の2020年ベータ版Chooserは8.88ヶ月と3.16人の人材が必要でした。つまり、再設計はコスト効率が高く、元のコード量の1.8%で同等の機能を実装し、9ヶ月フルタイムで3人が行う作業を達成しました。

ネイティブサポートとセマンティクスの活用：ステッパーが主要なインタラクション要素であるため、新しいマークアップはそこから構築され、セマンティックフォームに分類され、クラスを使用して各コンポーネントを記述します。

動的な「データ + マークアップ」の交換も行われますが、Vue.jsパッケージではなくvanilla JavaScriptを使用することで、より柔軟なインターフェースが実現しました。また、ユーザーが情報を理解しやすくするための追加の摩擦を導入しています。

関連UX要素の結合と分離：Chooserはシンプルなインターフェースですが、多くの重複使用例があります。そのため、入力エリアと出力エリアをつなぐ方法を見つける努力を行いました。

属性フィールドには説明的なプレースホルダーデータがあり、マーク形式セクションでも表示されます。これにより、ユーザーが入力と出力を関連付けることができます。

最終的に、再設計の結果は大幅に小さく管理しやすいコードベースとなりました。Vocabulary Designシステムとの統合も改善され、セマンティックでアクセシブルなマークアップを効果的に使用しています。この大幅な削減により、2025年のChooserはより柔軟になり、ユーザーにとって最適な方向に成長できるようになりました。

総じて、コードのフットプリントは57.52倍小さくなりました！再設計後のコードベースが地球だとすると、旧コードベースは海王星であり、海王星の体積は地球の58倍です（海王星には58個の地球が収まります）。この大幅な改善により、プロジェクトが適切に成長できる余地ができました。Chooserを再設計する目的は、静的なリリースだけでなく、ユーザーにとって最適な方向に柔軟に成長できるようにすることです。

次回のパート3では、「Chooserの未来の成長：次は何をするべきか」というテーマで詳しく説明します。]]></description>
            <content:encoded><![CDATA[このブログは、三部作の第2部で、「新しいCC Chooserの再設計とリリース」を扱います。Creative Commons Chooser 2025の再設計では、アプリケーション全体にわたる多くの改善が行われました。可能な限り、フットプリントや実装がより簡潔でシンプルになるよう考慮し、その上で作業を行いました。最終目標は、メンテナンスと進化において大幅に柔軟性を高めたアプリケーションを作成することです。

コア機能の再評価と使用：最初に、Chooserが提供すべき基本的な機能セットを理解し、再確立しました。2020年のベータ版Chooserで存在していた使用例から始めました：ライセンスの推奨を行う ライセンスおよびその特性/使用例についてユーザーに対して静かに教育する 著者であるユーザーがさまざまな形式で「マーク」を生成できるようにする（一般的にはライセンス要件を満たす） 再利用者/再ミキサーが適切な属性情報を提供されていない場合、属性マークを生成できるようにする

上記の4つの使用例から、1と2はChooserの元々のコア目標でした。使用例3は、適用をより容易にするためのメカニズムとして追加されましたが、著者が適切な属性情報を提供しない場合、再利用者/再ミキサーがライセンス条項の精神に従うことができない可能性があります（属性情報が必要）。属性詳細がオプションであることは事実ですが、それはライセンス推奨や静かな教育を妨げません。しかし、ユーザーが3を主要な使用例として期待している場合、属性詳細は必須となり、文脈的な期待と衝突します。

使用例4はChooserの意図ではありませんでしたが、著者が一般的なマークステートメントを使用するため、ユーザーが定期的にこれを利用しています。今後は、1から3までの使用例に焦点を当てることを目指し、Chooserの再設計初期のMVPスコープでは1を優先し、その後2と3をサポートする使用例として扱います。使用例4は主にサポートされない使用例ですが、より良いツールが登場するまでユーザーがこれを続けることを期待しています。

範囲を技術的方法に変換：Chooserは、ステッパーを通じて一連の質問と結果的な推奨を順次提示します。これらのパスウェイには、最初で分岐する2つの主要なブランチ（「ライセンスが必要ですか？はい/いいえ」）があり、必要なフィールドがすべて満たされると適切な推奨が提供されます。

その後、属性フィールドを入力し、マークセクションにデータを自動的に反映させることができます。つまり、ステッパーは技術的な機能の核心部分であり、それを安定化させることが最初の目標となります。if/elseやswitch文を使用して一連の論理ゲートを通じて推奨を生成する方法もありますが、Chooserの場合、すべての答えは既知です。

推奨は7つの可能な法的ツールのいずれかであり、「ライセンスが必要ですか？はい/いいえ」の質問からそれぞれのツールに到達する2つの主要なパスウェイがあります。この前提から逆算することで、これらのパスウェイを形式化し、完全な決定木を記述することができます。

これにより、特定のUXを通じて状態を一貫して記述できるようになり、フォームを設定して質問に答えることで状態パスを作成します。完全なパスが可能となると推奨が正確に出力されます。それ以外は未知として扱います。

これにより、単純なステートマシンの設定から始めることができ、特定のイベントでチェックし、推奨やインターフェースを更新することができます。

JavaScriptのフットプリントとオーバーヘッドの削減：複雑な状態管理エンジンが不要になったため、Vue.jsのようなより大きなフレームワークから離れ、単一のvanilla JavaScriptファイルを使用する新しい2025年版Chooserを実装しました。これによりJavaScriptの量は約98%削減されました。

この結果、依存関係チェーンも大幅に削減され、Chooserがより安全で安定し、維持しやすくなります。SCCツールを使用すると、新しい再設計は開発に6.02ヶ月と1.68人の人材が必要であり、費用は$113,716になると推定されます。

再設計の計画は2024年に始まりましたが、コード完成までには約3ヶ月かかりました（予想時間の半分）。一方、元の2020年ベータ版Chooserは8.88ヶ月と3.16人の人材が必要でした。つまり、再設計はコスト効率が高く、元のコード量の1.8%で同等の機能を実装し、9ヶ月フルタイムで3人が行う作業を達成しました。

ネイティブサポートとセマンティクスの活用：ステッパーが主要なインタラクション要素であるため、新しいマークアップはそこから構築され、セマンティックフォームに分類され、クラスを使用して各コンポーネントを記述します。

動的な「データ + マークアップ」の交換も行われますが、Vue.jsパッケージではなくvanilla JavaScriptを使用することで、より柔軟なインターフェースが実現しました。また、ユーザーが情報を理解しやすくするための追加の摩擦を導入しています。

関連UX要素の結合と分離：Chooserはシンプルなインターフェースですが、多くの重複使用例があります。そのため、入力エリアと出力エリアをつなぐ方法を見つける努力を行いました。

属性フィールドには説明的なプレースホルダーデータがあり、マーク形式セクションでも表示されます。これにより、ユーザーが入力と出力を関連付けることができます。

最終的に、再設計の結果は大幅に小さく管理しやすいコードベースとなりました。Vocabulary Designシステムとの統合も改善され、セマンティックでアクセシブルなマークアップを効果的に使用しています。この大幅な削減により、2025年のChooserはより柔軟になり、ユーザーにとって最適な方向に成長できるようになりました。

総じて、コードのフットプリントは57.52倍小さくなりました！再設計後のコードベースが地球だとすると、旧コードベースは海王星であり、海王星の体積は地球の58倍です（海王星には58個の地球が収まります）。この大幅な改善により、プロジェクトが適切に成長できる余地ができました。Chooserを再設計する目的は、静的なリリースだけでなく、ユーザーにとって最適な方向に柔軟に成長できるようにすることです。

次回のパート3では、「Chooserの未来の成長：次は何をするべきか」というテーマで詳しく説明します。]]></content:encoded>
            <author>['sara']</author>
        </item>
        <item>
            <title><![CDATA[新しいCC Chooserの再設計とリリース: 第1部]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2025-07-11-refactoring-the-cc-chooser-pt-1/</link>
            <guid isPermaLink="false">urn:uuid:12eaf1bd-68c0-324c-99c8-931d8b2c255d</guid>
            <pubDate>Fri, 11 Jul 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[このブログは、3部構成シリーズの第1部で、「新しいCC Chooserの再設計とリリース」を紹介します。私たちは、長期間のベータ版から完成し安定したv1.0に移行させたことをお知らせできます。しかし、その道のりは決して平坦ではありませんでした。Chooserは多くの課題に直面しましたが、このシリーズでは3つのパートでその旅を振り返ります: 第1部: 歴史と負債: 新しい再設計と2025年版Chooserのリリースに至る歴史的背景。第2部: 詳細と修正: 技術的な負債、問題、複雑さ、コンテキストシフトのズレ、そしてその解決策について詳しく説明します。第3部: 未来の成長: Chooserの次のステップは何か、そして私たちが目指す方向性は何なのかを紹介します。

Chooserとは？ 当社のウェブサイトによると、「Chooser」はあなたがCreative Commonsライセンスを選ぶための簡単な手順を提供するツールです。Creative Commonsに初めて触れる方は、チョーサーを使用する前にライセンスに関する考慮事項も読んでみてください。

状況とコンテキスト: エコシステムが変化し、エンジニアの数だけでなく、コア製品自体が存在しない組織で複雑さが中心となった場合、その文脈を評価し、そこから何が機能するかを見直す必要があります。ChooserはCreative Commons (CC) のウェブサイト内で15年以上にわたりツールとして存在し、多くの人々が共有の制約と自由を選択する際に役立ちました。

2019年には、ChooserのUXとコア技術アプローチを再設計する必要がありました。CC Technologyチームは、後に2019年の夏にリリースされる予定だったCC Searchに重点を置いていました。CC Searchは非常に複雑なアプリケーションであり、より強力で動的なユーザーインターフェイスが必要でした。

Vue.jsを使用してCC Searchエンジンを開発したことで、開発時間の速さと柔軟性を得ることができましたが、コード依存関係や複雑さが増加しました。チームの規模や構築しようとしているエコシステムを考えると、これは適切な判断でした。

強力なコア製品からエコシステムを構築する: Vueを選択し、検索エンジンの開発に取り組んだ後、他の多くのプロジェクトも同じエコシステムに移行することで、更新がより効果的に全体としてサポートされる環境を作り出すことが合理的になりました。

2020年の状況変化: コロナウイルスは社会を震撼させ、寄付を混乱させ、Creative Commonsのスタッフ削減につながりました。技術チームの大半が解雇され、多くのプロジェクトが中断または終了しました。しかし、CC SearchはAutomatticによって[Openverse][openverse]として引き継がれました。

2020年のChooser: 最小限のメンテナンスで残された2020年版Chooserはベータ版でした。最新の法的ツールに焦点を当て、より良いUXとVocabularyデザインシステムを統合するために再設計されました。Vueから完全に構築されましたが、技術的な負債が増えるにつれてベータ版のままでした。

2023年以降: 技術チームは2023年に技術的負債を削減する能力を取り戻し、その年の後半にはCCサイトのリデザインが行われました。これによりVocabularyデザインシステムの再設計、Vueの除去、そしてより簡潔なエンジニアリングリソースに適したアプローチへの移行が可能になりました。

リファクタリングとリリースのための基盤を整える: 初期のベータ版リデザインから2020年のベータ版リリースまで、多くの時間が経過しました。Chooserのスコープを見直し、機能の核心を再評価する必要がありました。

2025年には、Chooserはより統合され、バランスが取れ、長期的なエンジニアリングに適した製品となりました。

今後の展開: このシリーズの次のパートでは、Chooserが蓄積した技術的負債と、実装された具体的な改善点について詳しく紹介します！]]></description>
            <content:encoded><![CDATA[このブログは、3部構成シリーズの第1部で、「新しいCC Chooserの再設計とリリース」を紹介します。私たちは、長期間のベータ版から完成し安定したv1.0に移行させたことをお知らせできます。しかし、その道のりは決して平坦ではありませんでした。Chooserは多くの課題に直面しましたが、このシリーズでは3つのパートでその旅を振り返ります: 第1部: 歴史と負債: 新しい再設計と2025年版Chooserのリリースに至る歴史的背景。第2部: 詳細と修正: 技術的な負債、問題、複雑さ、コンテキストシフトのズレ、そしてその解決策について詳しく説明します。第3部: 未来の成長: Chooserの次のステップは何か、そして私たちが目指す方向性は何なのかを紹介します。

Chooserとは？ 当社のウェブサイトによると、「Chooser」はあなたがCreative Commonsライセンスを選ぶための簡単な手順を提供するツールです。Creative Commonsに初めて触れる方は、チョーサーを使用する前にライセンスに関する考慮事項も読んでみてください。

状況とコンテキスト: エコシステムが変化し、エンジニアの数だけでなく、コア製品自体が存在しない組織で複雑さが中心となった場合、その文脈を評価し、そこから何が機能するかを見直す必要があります。ChooserはCreative Commons (CC) のウェブサイト内で15年以上にわたりツールとして存在し、多くの人々が共有の制約と自由を選択する際に役立ちました。

2019年には、ChooserのUXとコア技術アプローチを再設計する必要がありました。CC Technologyチームは、後に2019年の夏にリリースされる予定だったCC Searchに重点を置いていました。CC Searchは非常に複雑なアプリケーションであり、より強力で動的なユーザーインターフェイスが必要でした。

Vue.jsを使用してCC Searchエンジンを開発したことで、開発時間の速さと柔軟性を得ることができましたが、コード依存関係や複雑さが増加しました。チームの規模や構築しようとしているエコシステムを考えると、これは適切な判断でした。

強力なコア製品からエコシステムを構築する: Vueを選択し、検索エンジンの開発に取り組んだ後、他の多くのプロジェクトも同じエコシステムに移行することで、更新がより効果的に全体としてサポートされる環境を作り出すことが合理的になりました。

2020年の状況変化: コロナウイルスは社会を震撼させ、寄付を混乱させ、Creative Commonsのスタッフ削減につながりました。技術チームの大半が解雇され、多くのプロジェクトが中断または終了しました。しかし、CC SearchはAutomatticによって[Openverse][openverse]として引き継がれました。

2020年のChooser: 最小限のメンテナンスで残された2020年版Chooserはベータ版でした。最新の法的ツールに焦点を当て、より良いUXとVocabularyデザインシステムを統合するために再設計されました。Vueから完全に構築されましたが、技術的な負債が増えるにつれてベータ版のままでした。

2023年以降: 技術チームは2023年に技術的負債を削減する能力を取り戻し、その年の後半にはCCサイトのリデザインが行われました。これによりVocabularyデザインシステムの再設計、Vueの除去、そしてより簡潔なエンジニアリングリソースに適したアプローチへの移行が可能になりました。

リファクタリングとリリースのための基盤を整える: 初期のベータ版リデザインから2020年のベータ版リリースまで、多くの時間が経過しました。Chooserのスコープを見直し、機能の核心を再評価する必要がありました。

2025年には、Chooserはより統合され、バランスが取れ、長期的なエンジニアリングに適した製品となりました。

今後の展開: このシリーズの次のパートでは、Chooserが蓄積した技術的負債と、実装された具体的な改善点について詳しく紹介します！]]></content:encoded>
            <author>['sara']</author>
        </item>
        <item>
            <title><![CDATA[AWS RDSからMariaDB 10.4をMariaDB 10.11に移行する]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2025-03-06-AWS-RDS-blog-post/</link>
            <guid isPermaLink="false">urn:uuid:5883a758-4e87-369c-b744-dee79053503c</guid>
            <pubDate>Mon, 24 Mar 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[AWSからの要請に基づき、RDS DBエンジンをMariaDB 10.4から10.11へ移行するための手順について、詳細なステップバイステップガイドを提供します。この記事では、事前準備、実際のアップグレードプロセス、移行後の検証方法について説明し、ダウンタイムや問題を最小限に抑えるために必要な情報を提供します。それでは始めましょう！

事前準備ステップ
アップグレードを行う前に、特にカスタマイズされたデータベースパラメータがある環境では構造化した移行計画を確保することが重要です。以下の初期手順を行ってください：
- DB Parameter Groupの作成：新しいエンジンバージョン用にデータベース固有の設定をカスタマイズします。
- Option Groupの作成：レプリケーションやログ記録などの追加機能を管理します。
- バックアップとテスト：既存のデータベースのスナップショットを作成してデータ損失を防ぎます。

DB Parameter Groupの作成
RDS DB Parameter Groupsを使用すると、メモリやキャッシュなど、データベース固有のパラメータを設定できます。MariaDB 10.11用にカスタムDB Parameter Groupを作成する必要があります（異なるバージョンでは異なる設定が必要となるため）。

Parameter Groupの作成方法
- AWS Management Consoleにログインします。
- RDSサービスを選択し、パラメータグループへ移動します。
- 新しいパラメータグループを作成します。パラメータグループファミリーとしてmariadb10.11を選択し、適切な名前と説明を追加して作成ボタンをクリックします。

Parameterの変更
パラメータグループが作成されたら、アプリケーションの要件に応じてパラメータを変更します（innodb_buffer_pool_sizeやtime_zoneなど）。完了したら保存します。

Option Groupの作成
Option Groupsはレプリケーションやバックアップなどのデータベースオプションを集めたものです。10.4から10.11への移行では、新しいエンジンバージョン用にOption Groupを作成し、関連付けする必要があります。

Option Groupの作成方法
- AWS Management ConsoleでRDSのOption Groupsを選択します。
- 新しいオプショングループを作成します。適切な名前とエンジンバージョン（MariaDB 10.11）を指定して作成ボタンをクリックします。

MariaDBバージョンアップグレードの実行
必要なDB Parameter GroupとOption Groupが作成されたら、MariaDB 10.4から10.11への移行を行います。

アップグレード方法
- データベースのバックアップ：アップグレードプロセスを開始する前に現在のDBインスタンスのスナップショットを作成します。これにより、問題が発生した場合にロールバックできます。
- DBインスタンスの変更：新しいバージョンを使用するためにDBインスタンスを選択し、必要な設定（エンジンバージョン、パラメータグループ、オプショングループ）を指定します。変更を適用するタイミングを選択し、変更を保存します。
- インスタンスの再起動：必要に応じてインスタンスを再起動して変更を有効化します。

移行後の検証とクリーニング
アップグレードが完了したら、次の手順で移行を確認します：
- DBエンジンバージョンの確認
- アプリケーションパフォーマンスのテスト
- ログのレビュー

移行後のクリーニングでは不要になったParameterとOption Groupsを削除し、インスタンスのモニタリングとリソースのスケーリングを行います。

結論
AWS RDSからMariaDB 10.4を10.11に移行することは比較的簡単ですが、DB Parameter GroupやOption Group周りでの慎重な計画が必要です。この記事で示した手順に従うことで、最新のMariaDBバージョンへのスムーズな移行が可能になり、アプリケーションのパフォーマンス、セキュリティ、スケーラビリティを向上させることができます。

ベストプラクティス
- 生産環境での変更適用前にステージング環境でテストを行う。
- アップグレード後はRDSログとアプリケーションパフォーマンスをモニタリングする。
- エンジンバージョンの変更を開始する前に適切なバックアップを確保する。
これらのベストプラクティスを実装することで、パフォーマンス、セキュリティ、スケーラビリティを向上させつつ、移行の成功を確実にできます。]]></description>
            <content:encoded><![CDATA[AWSからの要請に基づき、RDS DBエンジンをMariaDB 10.4から10.11へ移行するための手順について、詳細なステップバイステップガイドを提供します。この記事では、事前準備、実際のアップグレードプロセス、移行後の検証方法について説明し、ダウンタイムや問題を最小限に抑えるために必要な情報を提供します。それでは始めましょう！

事前準備ステップ
アップグレードを行う前に、特にカスタマイズされたデータベースパラメータがある環境では構造化した移行計画を確保することが重要です。以下の初期手順を行ってください：
- DB Parameter Groupの作成：新しいエンジンバージョン用にデータベース固有の設定をカスタマイズします。
- Option Groupの作成：レプリケーションやログ記録などの追加機能を管理します。
- バックアップとテスト：既存のデータベースのスナップショットを作成してデータ損失を防ぎます。

DB Parameter Groupの作成
RDS DB Parameter Groupsを使用すると、メモリやキャッシュなど、データベース固有のパラメータを設定できます。MariaDB 10.11用にカスタムDB Parameter Groupを作成する必要があります（異なるバージョンでは異なる設定が必要となるため）。

Parameter Groupの作成方法
- AWS Management Consoleにログインします。
- RDSサービスを選択し、パラメータグループへ移動します。
- 新しいパラメータグループを作成します。パラメータグループファミリーとしてmariadb10.11を選択し、適切な名前と説明を追加して作成ボタンをクリックします。

Parameterの変更
パラメータグループが作成されたら、アプリケーションの要件に応じてパラメータを変更します（innodb_buffer_pool_sizeやtime_zoneなど）。完了したら保存します。

Option Groupの作成
Option Groupsはレプリケーションやバックアップなどのデータベースオプションを集めたものです。10.4から10.11への移行では、新しいエンジンバージョン用にOption Groupを作成し、関連付けする必要があります。

Option Groupの作成方法
- AWS Management ConsoleでRDSのOption Groupsを選択します。
- 新しいオプショングループを作成します。適切な名前とエンジンバージョン（MariaDB 10.11）を指定して作成ボタンをクリックします。

MariaDBバージョンアップグレードの実行
必要なDB Parameter GroupとOption Groupが作成されたら、MariaDB 10.4から10.11への移行を行います。

アップグレード方法
- データベースのバックアップ：アップグレードプロセスを開始する前に現在のDBインスタンスのスナップショットを作成します。これにより、問題が発生した場合にロールバックできます。
- DBインスタンスの変更：新しいバージョンを使用するためにDBインスタンスを選択し、必要な設定（エンジンバージョン、パラメータグループ、オプショングループ）を指定します。変更を適用するタイミングを選択し、変更を保存します。
- インスタンスの再起動：必要に応じてインスタンスを再起動して変更を有効化します。

移行後の検証とクリーニング
アップグレードが完了したら、次の手順で移行を確認します：
- DBエンジンバージョンの確認
- アプリケーションパフォーマンスのテスト
- ログのレビュー

移行後のクリーニングでは不要になったParameterとOption Groupsを削除し、インスタンスのモニタリングとリソースのスケーリングを行います。

結論
AWS RDSからMariaDB 10.4を10.11に移行することは比較的簡単ですが、DB Parameter GroupやOption Group周りでの慎重な計画が必要です。この記事で示した手順に従うことで、最新のMariaDBバージョンへのスムーズな移行が可能になり、アプリケーションのパフォーマンス、セキュリティ、スケーラビリティを向上させることができます。

ベストプラクティス
- 生産環境での変更適用前にステージング環境でテストを行う。
- アップグレード後はRDSログとアプリケーションパフォーマンスをモニタリングする。
- エンジンバージョンの変更を開始する前に適切なバックアップを確保する。
これらのベストプラクティスを実装することで、パフォーマンス、セキュリティ、スケーラビリティを向上させつつ、移行の成功を確実にできます。]]></content:encoded>
            <author>['shafiya']</author>
        </item>
        <item>
            <title><![CDATA[Creative CommonsとのOutreachyインターンシップの旅を振り返る]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/reflecting-on-my-outreachy-journey-with-creative-commons/</link>
            <guid isPermaLink="false">urn:uuid:e9199616-ea65-3705-aea7-fa6f5ddc421b</guid>
            <pubDate>Thu, 27 Feb 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[昨日のことのように感じるのは、初めてブログ記事を書いたときで、このインターンシップ中に何をするのか理解しようと必死だったからだ。そして今、私は最終記事を書いているところだ—コードに没頭し、リファクタリングや問題解決をしていると時間が早く過ぎていくものだと感じる。始めの頃は興奮と緊張が交錯していた。Creative Commonsの補助サイトでVocabularyデザインシステムを実装し統合するという仕事を行うことが分かっていたが、その過程でどれだけ学ぶことになるのかは完全には理解していなかった。このような影響力のある組織に有意義な貢献をすることができると考えただけで興奮したが、同時に自分自身に問いかけた—本当にこれができるだろうか？予告編：はい、できた！

最初の日から現在まで：旅路
最初の数週間はコードベースを理解し、Vocabularyがどのように機能するのかを学び、異なるウェブサイトがそれをどのように使用しているのかを把握することに費やした。当時、一度複雑に感じたことが今では自然なことのように感じる。

Issue Finderのリファクタリング：Vueを削除してシンプルなセットアップにする
私の主要なタスクの一つはCreative Commons Open Sourceウェブサイト上のissue finderツールをリファクタリングすることだった。このツールはVue.jsで構築されていたが、目標はVueを削除し、JavaScriptをVocabularyアプローチに合わせてリファクタリングすること—可能な限りHTMLとCSSを使用し、シンプルなJavaScriptを使うことだった。最初はこれが大きな課題だと感じた—特にVueを使ったことがなかったからだ。

DataTablesとの作業：新たな学習曲線
インターンシップ中に最も興味深かったことは、DataTablesの使用を学ぶことだった。このプロジェクトが始まる前には、DataTablesについて聞いたこともなかった。ドキュメントを読み、さまざまな設定を試し、データセットの取り扱い方を実験した。

中間期から現在まで：最終的な貢献とまとめ
中間期のブログ記事後は、Creative Commons Open Sourceウェブサイトでの再設計プロセスを完了し、小さなバグを修正することに焦点を移した。これらは小さなが重要な改良点で、一貫性を確保し、UIの一貫性を修正し、すべてがVocabularyデザインシステムと一致するようにした。

検索ポータルの改善：
私が手がけたウェブサイトの一つはSearch Portalだった。この作業には、ヘッダーセクションでCC略語を定義して明確性とアクセシビリティを向上させること、Vocabularyのデザインシステムに合わせて視覚的に統一感のある検索入力を再設計することなどが含まれていた。

CC Legal Database (LegalDB)：将来の貢献に向けて計画する
LegalDBは当初プロジェクトスコープに含まれていたが、時間制約により実装できなかった。代わりに、次の貢献者にとってスムーズで明確な道筋を確保するために、必要な変更点を特定し、詳細に文書化することに焦点を当てた。

次は？
このインターンシップは、美しいデザインと機能性の両方を持つインターフェースを作成するフロントエンド開発への愛着を確固たるものにした。次の目標は、アニメーションやインタラクティブな要素を深く学び、ウェブをより没入感のあるものにする（GSAPとThree.jsを見よ！）ことだ。

心からの別れ（一時的なもので）
メンターやこのインターンシップ中に私を支えてくれたすべての人へ：感謝します。あなたの指導、忍耐、そして励ましにより、この経験は本当に特別なものとなった。将来のOutreachyインターン生へ：もし何かに圧倒されたとしても、それは旅路の一環だということを覚えておいてほしい。質問を続け、課題を乗り越え、最も重要なのはプロセスを楽しむことだ。あなたはスキルと自信を持ち、オープンソースに対する新たな感謝の気持ちを得て戻ってくるだろう。

それでは、この章への別れの言葉を述べるときが来た。それまで、楽しいコーディングを！🚀]]></description>
            <content:encoded><![CDATA[昨日のことのように感じるのは、初めてブログ記事を書いたときで、このインターンシップ中に何をするのか理解しようと必死だったからだ。そして今、私は最終記事を書いているところだ—コードに没頭し、リファクタリングや問題解決をしていると時間が早く過ぎていくものだと感じる。始めの頃は興奮と緊張が交錯していた。Creative Commonsの補助サイトでVocabularyデザインシステムを実装し統合するという仕事を行うことが分かっていたが、その過程でどれだけ学ぶことになるのかは完全には理解していなかった。このような影響力のある組織に有意義な貢献をすることができると考えただけで興奮したが、同時に自分自身に問いかけた—本当にこれができるだろうか？予告編：はい、できた！

最初の日から現在まで：旅路
最初の数週間はコードベースを理解し、Vocabularyがどのように機能するのかを学び、異なるウェブサイトがそれをどのように使用しているのかを把握することに費やした。当時、一度複雑に感じたことが今では自然なことのように感じる。

Issue Finderのリファクタリング：Vueを削除してシンプルなセットアップにする
私の主要なタスクの一つはCreative Commons Open Sourceウェブサイト上のissue finderツールをリファクタリングすることだった。このツールはVue.jsで構築されていたが、目標はVueを削除し、JavaScriptをVocabularyアプローチに合わせてリファクタリングすること—可能な限りHTMLとCSSを使用し、シンプルなJavaScriptを使うことだった。最初はこれが大きな課題だと感じた—特にVueを使ったことがなかったからだ。

DataTablesとの作業：新たな学習曲線
インターンシップ中に最も興味深かったことは、DataTablesの使用を学ぶことだった。このプロジェクトが始まる前には、DataTablesについて聞いたこともなかった。ドキュメントを読み、さまざまな設定を試し、データセットの取り扱い方を実験した。

中間期から現在まで：最終的な貢献とまとめ
中間期のブログ記事後は、Creative Commons Open Sourceウェブサイトでの再設計プロセスを完了し、小さなバグを修正することに焦点を移した。これらは小さなが重要な改良点で、一貫性を確保し、UIの一貫性を修正し、すべてがVocabularyデザインシステムと一致するようにした。

検索ポータルの改善：
私が手がけたウェブサイトの一つはSearch Portalだった。この作業には、ヘッダーセクションでCC略語を定義して明確性とアクセシビリティを向上させること、Vocabularyのデザインシステムに合わせて視覚的に統一感のある検索入力を再設計することなどが含まれていた。

CC Legal Database (LegalDB)：将来の貢献に向けて計画する
LegalDBは当初プロジェクトスコープに含まれていたが、時間制約により実装できなかった。代わりに、次の貢献者にとってスムーズで明確な道筋を確保するために、必要な変更点を特定し、詳細に文書化することに焦点を当てた。

次は？
このインターンシップは、美しいデザインと機能性の両方を持つインターフェースを作成するフロントエンド開発への愛着を確固たるものにした。次の目標は、アニメーションやインタラクティブな要素を深く学び、ウェブをより没入感のあるものにする（GSAPとThree.jsを見よ！）ことだ。

心からの別れ（一時的なもので）
メンターやこのインターンシップ中に私を支えてくれたすべての人へ：感謝します。あなたの指導、忍耐、そして励ましにより、この経験は本当に特別なものとなった。将来のOutreachyインターン生へ：もし何かに圧倒されたとしても、それは旅路の一環だということを覚えておいてほしい。質問を続け、課題を乗り越え、最も重要なのはプロセスを楽しむことだ。あなたはスキルと自信を持ち、オープンソースに対する新たな感謝の気持ちを得て戻ってくるだろう。

それでは、この章への別れの言葉を述べるときが来た。それまで、楽しいコーディングを！🚀]]></content:encoded>
            <author>['Queen']</author>
        </item>
        <item>
            <title><![CDATA[問題を見つけることと共感を示すこと]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2025-02-04-finding-solutions-exercising-compassion/</link>
            <guid isPermaLink="false">urn:uuid:d3b97d81-1fc2-36ba-bca9-1d7114aab599</guid>
            <pubDate>Tue, 04 Feb 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[エンジニアリング、プログラミング、コーディング——人間とコンピュータが交差するあらゆるものを構築する際には、文脈が重要です。変数のスコープ、関数の呼び出し方、CSSファイルでのスタイルの適用方法など、文脈は制御します。「文脈はすべてである」という言葉通り、文脈は非常に重要です。しかし、その一方で、問題を追跡したり探しているときに、文脈を見逃したり無視することが容易です。

エンジニアリングの世界では多くのものが作られ、移動され、再設計されます。これらは創造活動に似ていますが、同時に多くの役割や仕事は意図的または偶発的に問題を発見することに焦点を当てています。「コードリポジトリ」にある「Issues」という名前自体が何かが間違っていることを示しています。

共感のための一時停止 問題を見つけることはエンジニアリングの一部であり、一度問題が見つかったら、その次のステップは解決策を見つけ出すことになります。この移行点、境界線で一時的に立ち止まり、先ほど見た問題を再考することをお勧めします。

それは問題が発生し、解決策を探している間の空間であり、ここで私たち全員が共感という程度の心地よさを持つことができます。この問題は多くの面で最初に導入された文脈から生まれたものです。非現実的なタイムラインの後遺症や、エンジニアのコントロールと影響力の外で行われた決定の意図しない結果である可能性があります。

その問題は必ずしも一人の人間、一つのチーム、または一つのプロセスの産物ではありません。それは通常、人々と技術が相互に作用して影響を与え合う複雑なシステムの結果です。この問題を避けることが容易だったかのように仮定するのは簡単ですが、これは不適切な決定や悪意の証拠とは限りません。

エンジニアリングは時として選択肢が限られている場所であり、最良の選択は問題ゼロではなく、最も少ない問題または最も影響のない問題を達成できるものである場合が多いです。さらに、厳格なレビューとテストを行っても、ミスが見逃されたり、状況が変化したりします。

文脈は鍵ですが、しばしば謎です。継承されたシステムの場合、あなたは問題を受け継ぐかもしれませんが、それらが生成された文脈の証拠はほとんどないかもしれません。解決策を求める責任がありながらも、なぜその問題が最初に導入されたのかという理由はありません。

これらの瞬間すべてで、共感を思い出すことが重要です。私たちは全体像や完全な文脈を知らないことを受け入れ、私たちの周りの人々は彼らが属するシステムの中で最善を尽くした可能性があることを理解します。

結論を急ぐこと、責任を追及すること、判断することは容易ですが、共感があれば信頼と健全さを育むコミュニティを築くことができます。学びや改善のための安全な環境を作ることで、人々は失敗を恐れずに済みます。

共感がなければ、人々はミスを恐れて行動できなくなります。初心者は初心者として合理的なミスを犯すことが多いので、彼らがミスを恐れるならオープンソースの世界は初心者を失い、それがなければ繁栄や成長はありません。

人間と技術的なシステムは完璧ではありません。それらを改善する方法はコード上の問題だけを解決することではなく、特にその解決策に共感がない場合です。

次回問題に直面したときには一時的に立ち止まり、共感を持って先のコーダーの立場になってみてください。時間の経過とともに理解を深めながら解決策を探し、私たちが同じ文脈で出会うことはなくても、お互いが少しでも良いものを作ろうとしていた可能性があることを思い出してみてください。]]></description>
            <content:encoded><![CDATA[エンジニアリング、プログラミング、コーディング——人間とコンピュータが交差するあらゆるものを構築する際には、文脈が重要です。変数のスコープ、関数の呼び出し方、CSSファイルでのスタイルの適用方法など、文脈は制御します。「文脈はすべてである」という言葉通り、文脈は非常に重要です。しかし、その一方で、問題を追跡したり探しているときに、文脈を見逃したり無視することが容易です。

エンジニアリングの世界では多くのものが作られ、移動され、再設計されます。これらは創造活動に似ていますが、同時に多くの役割や仕事は意図的または偶発的に問題を発見することに焦点を当てています。「コードリポジトリ」にある「Issues」という名前自体が何かが間違っていることを示しています。

共感のための一時停止 問題を見つけることはエンジニアリングの一部であり、一度問題が見つかったら、その次のステップは解決策を見つけ出すことになります。この移行点、境界線で一時的に立ち止まり、先ほど見た問題を再考することをお勧めします。

それは問題が発生し、解決策を探している間の空間であり、ここで私たち全員が共感という程度の心地よさを持つことができます。この問題は多くの面で最初に導入された文脈から生まれたものです。非現実的なタイムラインの後遺症や、エンジニアのコントロールと影響力の外で行われた決定の意図しない結果である可能性があります。

その問題は必ずしも一人の人間、一つのチーム、または一つのプロセスの産物ではありません。それは通常、人々と技術が相互に作用して影響を与え合う複雑なシステムの結果です。この問題を避けることが容易だったかのように仮定するのは簡単ですが、これは不適切な決定や悪意の証拠とは限りません。

エンジニアリングは時として選択肢が限られている場所であり、最良の選択は問題ゼロではなく、最も少ない問題または最も影響のない問題を達成できるものである場合が多いです。さらに、厳格なレビューとテストを行っても、ミスが見逃されたり、状況が変化したりします。

文脈は鍵ですが、しばしば謎です。継承されたシステムの場合、あなたは問題を受け継ぐかもしれませんが、それらが生成された文脈の証拠はほとんどないかもしれません。解決策を求める責任がありながらも、なぜその問題が最初に導入されたのかという理由はありません。

これらの瞬間すべてで、共感を思い出すことが重要です。私たちは全体像や完全な文脈を知らないことを受け入れ、私たちの周りの人々は彼らが属するシステムの中で最善を尽くした可能性があることを理解します。

結論を急ぐこと、責任を追及すること、判断することは容易ですが、共感があれば信頼と健全さを育むコミュニティを築くことができます。学びや改善のための安全な環境を作ることで、人々は失敗を恐れずに済みます。

共感がなければ、人々はミスを恐れて行動できなくなります。初心者は初心者として合理的なミスを犯すことが多いので、彼らがミスを恐れるならオープンソースの世界は初心者を失い、それがなければ繁栄や成長はありません。

人間と技術的なシステムは完璧ではありません。それらを改善する方法はコード上の問題だけを解決することではなく、特にその解決策に共感がない場合です。

次回問題に直面したときには一時的に立ち止まり、共感を持って先のコーダーの立場になってみてください。時間の経過とともに理解を深めながら解決策を探し、私たちが同じ文脈で出会うことはなくても、お互いが少しでも良いものを作ろうとしていた可能性があることを思い出してみてください。]]></content:encoded>
            <author>['sara']</author>
        </item>
        <item>
            <title><![CDATA[Outreachy 中間進捗：Creative Commons]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/outreachy-midpoint-progess-with-creative-commons/</link>
            <guid isPermaLink="false">urn:uuid:667f699a-cc21-3b0a-8eef-e01c1f08f66c</guid>
            <pubDate>Sun, 19 Jan 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは！私の名前はQueenで、Creative CommonsでのOutreachyインターンシップを行っています。私のプロジェクトは、Creative Commonsのサテライトサイト全体にVocabularyデザインシステムを統合と実装することです。この記事では、インターンシップの最初の半分における進捗状況と重要な教訓について共有します。

プロジェクト概要：
私のプロジェクトの目標は、CC Open Source、CC Legal Database、CC Search Portal、およびCC Resource ArchiveなどのCreative CommonsサテライトサイトにVocabularyデザインシステムを実装することです。

現在までの進捗状況：
第一フェーズ：マークアップの再設計
最初のフェーズでは、Vocabularyのコンポーネントと文脈に合わせてマークアップを再設計しました。このフェーズでマージされたプルリクエスト（PR）は以下の通りです。
- PR 118: ホームページの最近のブログ投稿セクションの再設計
- PR 856: ホームページのマークアップをVocabularyコンポーネントに合わせて再設計
- PR 862: page-with-toc.htmlの更新（多くのページで使用されるテンプレート）
- PR 863: レガシークラス名を削除し、テーブル構造を維持するための修正
- PR 865: ブログの著者ページをVocabularyの「person」コンテキストに合わせて再設計
- PR 866: ブログの構造をVocabularyマークアップに合わせて更新
- PR 867: プロジェクトリストページの再設計（テーブルマークアップは維持）
- PR 868: Issue Finderツールの再設計（Vue.jsから純粋なJavaScriptへの移行）
- PR 870: AuthorsページをVocabularyのチームスタイルに合わせて更新
- PR 871: プロジェクトアイデアページの再設計（Vocabularyのプロジェクトマークアップとレガシースタイルの削除）
- PR 873: layout.html内のbodyタグのクラスを動的に更新し、blog.iniモデルファイルにbody-classフィールドを追加
- PR 880: page-with-title.html（CC Tech Archivesで使用）をVocabularyに合わせて再設計
- PR 886: ヘッダーコンポーネントのマークアップ更新とレガシークラス名の削除
第二フェーズ：ローカルスタイルの追加
マークアップの再設計後、Vocabularyがカバーしていないセクションにローカルスタイルを追加しました。以下は現在までマージされたPRの一覧です。
- PR 888: ホームページと「Get Involved」、「Featured Projects」などのセクションにCreative Commonsのメインサイトに基づくローカルスタイルを追加
- PR 891: Issue Finderページの再設計（レガシースタイルの削除と維持）
- PR 898: DatatablesとjQueryの統合（vendorフォルダへの追加）および既存のウェブサイトスタイルを使用したテーブルとコードブロックのスタイリング
- PR 990: CC SearchアーカイブテーブルのDatatablesによるスタイリング
現在の状況：
スケジュール通りには進んでいません。CC Legal Databaseサイトへの作業を始める予定でしたが、この週にCC Open Sourceサイトの完了に向けて取り組んでいます。
学んだこと：
このインターンシップは素晴らしい学習経験でした。以下が重要な教訓です。
- 技術スキル：Lektor（私にとって全く新しい静的ウェブサイトジェネレーター）を使用するのに慣れました。Vocabularyデザインシステムの実装を通じて、特に既存コードと独自のウェブサイト要件に対応するために問題解決能力を向上させることができました。
- コラボレーション：メンターとの協働は、ブロッカーへの対処やフィードバックを求めることの重要性を教えてくれました。
- プロジェクト管理：タスクを小さな部分に分割し、効果的に優先順位をつけ、一貫した進捗を維持することがこのプロジェクトを成功させるためには不可欠でした。この経験はフロントエンド開発者としての自信を大幅に向上させました。

以上が現在までの進捗状況です！私の進行状況について読んでいただき、ありがとうございます。次の半分の旅がどのように展開するか楽しみにしています！]]></description>
            <content:encoded><![CDATA[こんにちは！私の名前はQueenで、Creative CommonsでのOutreachyインターンシップを行っています。私のプロジェクトは、Creative Commonsのサテライトサイト全体にVocabularyデザインシステムを統合と実装することです。この記事では、インターンシップの最初の半分における進捗状況と重要な教訓について共有します。

プロジェクト概要：
私のプロジェクトの目標は、CC Open Source、CC Legal Database、CC Search Portal、およびCC Resource ArchiveなどのCreative CommonsサテライトサイトにVocabularyデザインシステムを実装することです。

現在までの進捗状況：
第一フェーズ：マークアップの再設計
最初のフェーズでは、Vocabularyのコンポーネントと文脈に合わせてマークアップを再設計しました。このフェーズでマージされたプルリクエスト（PR）は以下の通りです。
- PR 118: ホームページの最近のブログ投稿セクションの再設計
- PR 856: ホームページのマークアップをVocabularyコンポーネントに合わせて再設計
- PR 862: page-with-toc.htmlの更新（多くのページで使用されるテンプレート）
- PR 863: レガシークラス名を削除し、テーブル構造を維持するための修正
- PR 865: ブログの著者ページをVocabularyの「person」コンテキストに合わせて再設計
- PR 866: ブログの構造をVocabularyマークアップに合わせて更新
- PR 867: プロジェクトリストページの再設計（テーブルマークアップは維持）
- PR 868: Issue Finderツールの再設計（Vue.jsから純粋なJavaScriptへの移行）
- PR 870: AuthorsページをVocabularyのチームスタイルに合わせて更新
- PR 871: プロジェクトアイデアページの再設計（Vocabularyのプロジェクトマークアップとレガシースタイルの削除）
- PR 873: layout.html内のbodyタグのクラスを動的に更新し、blog.iniモデルファイルにbody-classフィールドを追加
- PR 880: page-with-title.html（CC Tech Archivesで使用）をVocabularyに合わせて再設計
- PR 886: ヘッダーコンポーネントのマークアップ更新とレガシークラス名の削除
第二フェーズ：ローカルスタイルの追加
マークアップの再設計後、Vocabularyがカバーしていないセクションにローカルスタイルを追加しました。以下は現在までマージされたPRの一覧です。
- PR 888: ホームページと「Get Involved」、「Featured Projects」などのセクションにCreative Commonsのメインサイトに基づくローカルスタイルを追加
- PR 891: Issue Finderページの再設計（レガシースタイルの削除と維持）
- PR 898: DatatablesとjQueryの統合（vendorフォルダへの追加）および既存のウェブサイトスタイルを使用したテーブルとコードブロックのスタイリング
- PR 990: CC SearchアーカイブテーブルのDatatablesによるスタイリング
現在の状況：
スケジュール通りには進んでいません。CC Legal Databaseサイトへの作業を始める予定でしたが、この週にCC Open Sourceサイトの完了に向けて取り組んでいます。
学んだこと：
このインターンシップは素晴らしい学習経験でした。以下が重要な教訓です。
- 技術スキル：Lektor（私にとって全く新しい静的ウェブサイトジェネレーター）を使用するのに慣れました。Vocabularyデザインシステムの実装を通じて、特に既存コードと独自のウェブサイト要件に対応するために問題解決能力を向上させることができました。
- コラボレーション：メンターとの協働は、ブロッカーへの対処やフィードバックを求めることの重要性を教えてくれました。
- プロジェクト管理：タスクを小さな部分に分割し、効果的に優先順位をつけ、一貫した進捗を維持することがこのプロジェクトを成功させるためには不可欠でした。この経験はフロントエンド開発者としての自信を大幅に向上させました。

以上が現在までの進捗状況です！私の進行状況について読んでいただき、ありがとうございます。次の半分の旅がどのように展開するか楽しみにしています！]]></content:encoded>
            <author>['Queen']</author>
        </item>
        <item>
            <title><![CDATA[Google Summer of Code (GSoC) 2025への参加を見送ります]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2025-01-15-skipping-gsoc-2025/</link>
            <guid isPermaLink="false">urn:uuid:61e914ed-e3a7-3119-9960-1c5fa9f1b224</guid>
            <pubDate>Wed, 15 Jan 2025 00:00:00 GMT</pubDate>
            <description><![CDATA[クリエイティブコモンズ(Creative Commons、CC)の技術チームは、残念ながらGoogle Summer of Code (GSoC) 2025に参加しないことをお知らせします。プログラム自体は依然として優れているものの、今年は当社の主要な責任を果たすためのリソースが不足しているためです。Google様から提供されるこのプログラムには感謝しており、過去数年間で大きな価値を得てきました。今後も参加できるよう努力します。貢献者の皆様の労力と時間を心より感謝いたします。これは喜ばしいニュースではありませんが、将来的にワークプログラムへの参加をより適切に行えるようになるでしょう。

再参画に向けて
今年の第1四半期には、当社のCCオープンソースウェブサイトを刷新するとともに、構造化されたコミュニティ関与を強化し、プロジェクトリーダー向けのリソースを改善する予定です。CCオープンソースウェブサイトは、技術的な複雑さを軽減し、現在のVocabulary設計システム(creativecommons/vocabulary)を使用して更新されています。

コミュニティ関与が停滞していたのは、COVIDパンデミックによる技術チームの縮小の影響でした（202-12-07 CCオープンソースコミュニティにおける予定の変更 — クリエイティブコモンズオープンソース）。コミュニティ関与を簡素化することで、より迅速に対応し、透明性が向上します。

ワークプログラムで最もリソースが必要な時期は申請期間です。この時期には通常、私たちの能力を超えるほどの活動があります。プロジェクトリーダー向けのリソースを開発することで、期待値を設定しやすく、コミュニケーションを円滑にし、申請者に対してより生産的な道筋を示すことができます。

過去の参加について
過去の参加で行われた優れた作業に関する情報は以下の通りです：オープンソースワークプログラム：歴史 — クリエイティブコモンズオープンソース。]]></description>
            <content:encoded><![CDATA[クリエイティブコモンズ(Creative Commons、CC)の技術チームは、残念ながらGoogle Summer of Code (GSoC) 2025に参加しないことをお知らせします。プログラム自体は依然として優れているものの、今年は当社の主要な責任を果たすためのリソースが不足しているためです。Google様から提供されるこのプログラムには感謝しており、過去数年間で大きな価値を得てきました。今後も参加できるよう努力します。貢献者の皆様の労力と時間を心より感謝いたします。これは喜ばしいニュースではありませんが、将来的にワークプログラムへの参加をより適切に行えるようになるでしょう。

再参画に向けて
今年の第1四半期には、当社のCCオープンソースウェブサイトを刷新するとともに、構造化されたコミュニティ関与を強化し、プロジェクトリーダー向けのリソースを改善する予定です。CCオープンソースウェブサイトは、技術的な複雑さを軽減し、現在のVocabulary設計システム(creativecommons/vocabulary)を使用して更新されています。

コミュニティ関与が停滞していたのは、COVIDパンデミックによる技術チームの縮小の影響でした（202-12-07 CCオープンソースコミュニティにおける予定の変更 — クリエイティブコモンズオープンソース）。コミュニティ関与を簡素化することで、より迅速に対応し、透明性が向上します。

ワークプログラムで最もリソースが必要な時期は申請期間です。この時期には通常、私たちの能力を超えるほどの活動があります。プロジェクトリーダー向けのリソースを開発することで、期待値を設定しやすく、コミュニケーションを円滑にし、申請者に対してより生産的な道筋を示すことができます。

過去の参加について
過去の参加で行われた優れた作業に関する情報は以下の通りです：オープンソースワークプログラム：歴史 — クリエイティブコモンズオープンソース。]]></content:encoded>
            <author>['TimidRobot']</author>
        </item>
        <item>
            <title><![CDATA[Creative CommonsでのOutreachyインターンシップ]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/my-outreachy-internship-with-creative-commons/</link>
            <guid isPermaLink="false">urn:uuid:032f105a-3718-34cb-955f-4c2429a76c43</guid>
            <pubDate>Tue, 10 Dec 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは、皆さん！私の名前はQueenで、薬学を卒業したばかりの技術に情熱を持つ人です。コードへの道が始まったのは4年前、初めてHTMLを書いたときでした。「そうだ、私はFAANG向けだ！」と感じたのですが、結論としてはそうではありませんでした——それでも大きな夢を諦めませんでした。薬学学校とコーディングを学ぶバランスは時々手に余るような感覚でしたが、フロントエンド開発者になるという夢から離れないことに誇りを持っています。
私の核心的な価値観：成長、好奇心、知識です。成長：私は人生のあらゆる面で向上することを目指しています——精神的に、身体的に、知的に、そして霊性においても。失敗は私にとってただ次のステップへの足場に過ぎません。好奇心：これは進行中のプロセスですが、質問をし、知らないことを受け入れることを学んでいます。なぜ物事がそのように機能するのか理解するのが好きです。知識：私は新しいことについて学ぶのが好きなのでたくさん読みます。私にとって知識は自信と成長の鍵です。
Outreachyへの道：Outreachyは、技術分野で表現が少ない人々を対象とした3ヶ月間のオープンソースインターンシッププログラムです。去年、申請締切の2日前に初めて聞きました——その時は初期申請段階を通過できませんでした。12月2024年のコホートの初期申請が始まったときには、私にとって絶好のタイミングでした。薬学学位を終え、フロントエンド開発とオープンソースでのプロフェッショナルな経験を得る準備ができていました。この時、私は成功するためだけに決意しました。申請が開始された日には既にエッセイの質問に対する答えをノートアプリに保存していました。結果待ちの間、スキルを磨き、過去のインターンからの記事を読み、貢献期間に向けて準備しました。初期申請が承認されたメールを受け取ったとき、興奮でいっぱいでした。次のステップへ進むためには、プロジェクトへの少なくとも1つの貢献が必要でした。必要なスキルに基づいて選択肢を2つに絞りましたが、Creative Commonsが目を引きました。そのミッションとプロジェクトの説明が私の関心を引きつけました。
貢献期間：貢献期間は競争的で、少し恐れを感じました。他の申請者の素晴らしい仕事を見ると自分自身を疑いました。しかし、私はこのプロジェクトを愛し、コミュニティがとても歓迎してくれたので諦めませんでした。メンターやフィードバックの提供者は非常にサポート的で、各貢献ごとに改善するためのフィードバックをくれました。最終申請と提案書を作成するときには、私の計画を共有し、アドバイスを得てプロジェクトのタイムラインを作成しました。選ばれるかどうか知らないうちからも満足感がありました。Creative Commonsへの貢献は充実した経験で、インターンであろうとなかろうとコミュニティに継続的に貢献したいと思いました。
インターンシッププロジェクト：語彙設計システムの統合と実装私はインターンとして、Creative Commonsの補助サイト全体に語彙設計システムを統合し実装する仕事を行います。語彙は一貫したユーザーインターフェース（UI）とユーザーエクスペリエンス（UX）を保証するデザインシステムですが、その実装は不規則で、機能やバージョンが異なるサイト間でのばらつきがあります。私の役割はこれらの違いを見つけ出し、アクセシビリティにも焦点を当てた統一された実装に取り組むことです。また、設計システムへの追加になる可能性のある機能も実装します。このプロジェクトにはフロントエンド開発に対する情熱が反映されており、グローバルコミュニティに対して有意義な貢献ができると感じています。スキルを向上させるとともに新たなスキルを得ることも楽しみです。
結論：このインターンシップは私にとってのマイルストーン以上のもので、忍耐力と成長への証明です。Creative Commonsと共にこの旅に出発できることを嬉しく思いますし、それがどこへ導いてくれるのか楽しみにしています。Outreachyへの申請を考えている方は、自分自身を信じ、好奇心を持ち続け、学び続けることをお勧めします。あなたの旅はあなたを驚かせるかもしれません。読んでいただきありがとうございました！]]></description>
            <content:encoded><![CDATA[こんにちは、皆さん！私の名前はQueenで、薬学を卒業したばかりの技術に情熱を持つ人です。コードへの道が始まったのは4年前、初めてHTMLを書いたときでした。「そうだ、私はFAANG向けだ！」と感じたのですが、結論としてはそうではありませんでした——それでも大きな夢を諦めませんでした。薬学学校とコーディングを学ぶバランスは時々手に余るような感覚でしたが、フロントエンド開発者になるという夢から離れないことに誇りを持っています。
私の核心的な価値観：成長、好奇心、知識です。成長：私は人生のあらゆる面で向上することを目指しています——精神的に、身体的に、知的に、そして霊性においても。失敗は私にとってただ次のステップへの足場に過ぎません。好奇心：これは進行中のプロセスですが、質問をし、知らないことを受け入れることを学んでいます。なぜ物事がそのように機能するのか理解するのが好きです。知識：私は新しいことについて学ぶのが好きなのでたくさん読みます。私にとって知識は自信と成長の鍵です。
Outreachyへの道：Outreachyは、技術分野で表現が少ない人々を対象とした3ヶ月間のオープンソースインターンシッププログラムです。去年、申請締切の2日前に初めて聞きました——その時は初期申請段階を通過できませんでした。12月2024年のコホートの初期申請が始まったときには、私にとって絶好のタイミングでした。薬学学位を終え、フロントエンド開発とオープンソースでのプロフェッショナルな経験を得る準備ができていました。この時、私は成功するためだけに決意しました。申請が開始された日には既にエッセイの質問に対する答えをノートアプリに保存していました。結果待ちの間、スキルを磨き、過去のインターンからの記事を読み、貢献期間に向けて準備しました。初期申請が承認されたメールを受け取ったとき、興奮でいっぱいでした。次のステップへ進むためには、プロジェクトへの少なくとも1つの貢献が必要でした。必要なスキルに基づいて選択肢を2つに絞りましたが、Creative Commonsが目を引きました。そのミッションとプロジェクトの説明が私の関心を引きつけました。
貢献期間：貢献期間は競争的で、少し恐れを感じました。他の申請者の素晴らしい仕事を見ると自分自身を疑いました。しかし、私はこのプロジェクトを愛し、コミュニティがとても歓迎してくれたので諦めませんでした。メンターやフィードバックの提供者は非常にサポート的で、各貢献ごとに改善するためのフィードバックをくれました。最終申請と提案書を作成するときには、私の計画を共有し、アドバイスを得てプロジェクトのタイムラインを作成しました。選ばれるかどうか知らないうちからも満足感がありました。Creative Commonsへの貢献は充実した経験で、インターンであろうとなかろうとコミュニティに継続的に貢献したいと思いました。
インターンシッププロジェクト：語彙設計システムの統合と実装私はインターンとして、Creative Commonsの補助サイト全体に語彙設計システムを統合し実装する仕事を行います。語彙は一貫したユーザーインターフェース（UI）とユーザーエクスペリエンス（UX）を保証するデザインシステムですが、その実装は不規則で、機能やバージョンが異なるサイト間でのばらつきがあります。私の役割はこれらの違いを見つけ出し、アクセシビリティにも焦点を当てた統一された実装に取り組むことです。また、設計システムへの追加になる可能性のある機能も実装します。このプロジェクトにはフロントエンド開発に対する情熱が反映されており、グローバルコミュニティに対して有意義な貢献ができると感じています。スキルを向上させるとともに新たなスキルを得ることも楽しみです。
結論：このインターンシップは私にとってのマイルストーン以上のもので、忍耐力と成長への証明です。Creative Commonsと共にこの旅に出発できることを嬉しく思いますし、それがどこへ導いてくれるのか楽しみにしています。Outreachyへの申請を考えている方は、自分自身を信じ、好奇心を持ち続け、学び続けることをお勧めします。あなたの旅はあなたを驚かせるかもしれません。読んでいただきありがとうございました！]]></content:encoded>
            <author>['Queen']</author>
        </item>
        <item>
            <title><![CDATA[AnsibleとDockerを使用したローカル環境の作成：パート2]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2024-08-23-create-local-ansible-dev-env/</link>
            <guid isPermaLink="false">urn:uuid:2c9a29f3-0d0b-3daa-9fc6-280495e05ab8</guid>
            <pubDate>Fri, 23 Aug 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[6週間かけてカスタムDockerfileとdocker-compose.ymlを作成し、ウェブ、データベース、およびansible用に設定を完了しました。しかし、プロダクション環境をより正確に再現するために、SSHアクセスが不要なAWS RDSインスタンスを使用しているため、データベースのカスタムDockerfileを削除することに決めました。

週ごとの進捗：初期アーキテクチャ設計後、bastionサーバーの構築を始めました。このプロセスで学んだ重要な教訓はシンプルさの価値です。たとえば、カスタムDockerfileを作成するか、コミュニティによって維持されている既存のイメージを使用するか評価する必要がありました。

DevOpsでは、いくつかの用語が曖昧に定義されることがあります。例えば、bastionサーバーに関する調査中に、MFA統合やログ記録などのセキュリティ機能を含むさまざまなユースケースを見つけることができましたが、これらは現在のプロジェクトの範囲外でした。

このプロジェクトでは、bastionサーバーを内部サーバーへの管理アクセス用の安全なゲートウェイとして構築します。この特定の要件により、より単純な実装が必要となりました。「YAGNI」（You Aren’t Gonna Need It）という概念もここで出会いました。これは、必要になるまで不要な機能を追加しないように私たちに思い出させるものです。

Creative Commons (CC)と作業を行う中で、多くのツールやソフトウェア、技術が利用可能であるため、環境と要件に合わせてカスタマイズされた設定とソリューションを実装することが重要であるという重要な教訓を学びました。

bastionサーバーのセットアップ前に、異なるSSH設定オプションを理解し、セキュリティと利便性のニーズを満たす最も適したものを選択することは非常に重要です。パスワードなしSSHは、SSHキー認証によりセキュリティと利便性を向上させますが、各サーバーでの公開鍵設定が必要となり、大規模な環境では煩雑になることがあります。

一方で、SSH Agentはプライベートキーのセキュリティと管理を改善し、複数の接続間でメモリに保持しますが、ローカルでSSH Agentを実行し、キーを読み込む必要があるため、セットアップに追加の複雑さをもたらします。

最終的にProxyJumpを使用することに決めました。これはbastionサーバーを通じてマルチホップ接続を中央管理し、内部サーバーへの安全なアクセスを提供するため、セキュリティと利便性が強化されます。ProxyJumpはbastionサーバーとターゲットサーバーの両方で中程度の設定が必要ですが、マルチホップ接続をサポートし、内部サーバーへの安全なアクセスを確保します。

これらの詳細をBastion Container Creationで確定した後、AnsibleとDockerを統合する最良のアプローチを探求しました。手動でのプロビジョニングアプローチを維持し、3つの主要な統合戦略に焦点を当てました。

オプション1では、AnsibleがDockerネットワークを通じてコンテナを直接管理します。すべてのサービス（bastion、ansible、web、db）は同一のネットワーク内で動作し、AnsibleはウェブとDBコンテナをそのコンテナ名またはIPを使用して管理します。必要に応じてbastionサーバーがジャンプホストとして機能します。

オプション2では、community.docker.docker_container_execモジュールを使用して、Ansibleプレイブックを通じてDockerコンテナ内でコマンドを実行します。この方法は、アプリケーションのインストールと設定タスクを直接コンテナ内に実施するため、柔軟性とポータビリティが向上します。

オプション3では、bastionとansibleサービスのみをDockerで実行し、Ansibleを使用してwebとdbサービスをプロビジョニングします。Ansibleはbastionサーバーを通じてこれらのコンテナに接続し、外部リソースとしてウェブとDBを管理および設定します。

これらのオプションを比較した結果、オプション1はアプリケーションレイヤでコンテナ内のアプリケーションを管理し、統一された環境でのセットアップを簡素化するための細かいコントロールを提供します。オプション2はDockerレイヤで動作し、迅速なデプロイに理想的です。オプション3はサービス間の最良の分離を提供し、強化されたセキュリティによりプロダクション環境をシミュレートしますが、より複雑なセットアップが必要となります。

慎重に検討した結果、設定タスクの大半をDockerfileからAnsibleプレイブックに移行するオプション1を選択しました。この投稿を書いている現在、これらのプレイブックの実装を行い、コンテナを設定しています。開発状況はこのリポジトリで追跡できます。

謝辞：この経験を通じて、実世界のDevOpsプロジェクトを実装するための実践的なスキルを得ることができました。日常業務以外でこのような知識を学び、個人の時間を有意義に使うことは学校ではあまりカバーされていませんが、それが非常に楽しいです。

このプロジェクトが証明概念として成功すれば、ユーザーからのフィードバックを集め、特にオープンソース開発者からフィードバックを得て、この設定を改善することができます。以前のブログ投稿で言及しましたが、Shafiya、Timid Robot、Saraへの指導とGoogle Summer of Codeによるオープンソースへの貢献機会を与えてくれたことに感謝しています。

オンライン上でさまざまなオープンコンテンツを作成し、楽しんでいるコンテンツクリエイターとして、CCに技術的な専門知識を提供することができることに非常に興奮し、光栄に思います。CCの社会に対する影響により、私は技術スキルを継続的に向上させ、この組織を長期的にサポートすることにコミットしています。

オープンソースコミュニティでのさらなる関与を楽しみにしています！]]></description>
            <content:encoded><![CDATA[6週間かけてカスタムDockerfileとdocker-compose.ymlを作成し、ウェブ、データベース、およびansible用に設定を完了しました。しかし、プロダクション環境をより正確に再現するために、SSHアクセスが不要なAWS RDSインスタンスを使用しているため、データベースのカスタムDockerfileを削除することに決めました。

週ごとの進捗：初期アーキテクチャ設計後、bastionサーバーの構築を始めました。このプロセスで学んだ重要な教訓はシンプルさの価値です。たとえば、カスタムDockerfileを作成するか、コミュニティによって維持されている既存のイメージを使用するか評価する必要がありました。

DevOpsでは、いくつかの用語が曖昧に定義されることがあります。例えば、bastionサーバーに関する調査中に、MFA統合やログ記録などのセキュリティ機能を含むさまざまなユースケースを見つけることができましたが、これらは現在のプロジェクトの範囲外でした。

このプロジェクトでは、bastionサーバーを内部サーバーへの管理アクセス用の安全なゲートウェイとして構築します。この特定の要件により、より単純な実装が必要となりました。「YAGNI」（You Aren’t Gonna Need It）という概念もここで出会いました。これは、必要になるまで不要な機能を追加しないように私たちに思い出させるものです。

Creative Commons (CC)と作業を行う中で、多くのツールやソフトウェア、技術が利用可能であるため、環境と要件に合わせてカスタマイズされた設定とソリューションを実装することが重要であるという重要な教訓を学びました。

bastionサーバーのセットアップ前に、異なるSSH設定オプションを理解し、セキュリティと利便性のニーズを満たす最も適したものを選択することは非常に重要です。パスワードなしSSHは、SSHキー認証によりセキュリティと利便性を向上させますが、各サーバーでの公開鍵設定が必要となり、大規模な環境では煩雑になることがあります。

一方で、SSH Agentはプライベートキーのセキュリティと管理を改善し、複数の接続間でメモリに保持しますが、ローカルでSSH Agentを実行し、キーを読み込む必要があるため、セットアップに追加の複雑さをもたらします。

最終的にProxyJumpを使用することに決めました。これはbastionサーバーを通じてマルチホップ接続を中央管理し、内部サーバーへの安全なアクセスを提供するため、セキュリティと利便性が強化されます。ProxyJumpはbastionサーバーとターゲットサーバーの両方で中程度の設定が必要ですが、マルチホップ接続をサポートし、内部サーバーへの安全なアクセスを確保します。

これらの詳細をBastion Container Creationで確定した後、AnsibleとDockerを統合する最良のアプローチを探求しました。手動でのプロビジョニングアプローチを維持し、3つの主要な統合戦略に焦点を当てました。

オプション1では、AnsibleがDockerネットワークを通じてコンテナを直接管理します。すべてのサービス（bastion、ansible、web、db）は同一のネットワーク内で動作し、AnsibleはウェブとDBコンテナをそのコンテナ名またはIPを使用して管理します。必要に応じてbastionサーバーがジャンプホストとして機能します。

オプション2では、community.docker.docker_container_execモジュールを使用して、Ansibleプレイブックを通じてDockerコンテナ内でコマンドを実行します。この方法は、アプリケーションのインストールと設定タスクを直接コンテナ内に実施するため、柔軟性とポータビリティが向上します。

オプション3では、bastionとansibleサービスのみをDockerで実行し、Ansibleを使用してwebとdbサービスをプロビジョニングします。Ansibleはbastionサーバーを通じてこれらのコンテナに接続し、外部リソースとしてウェブとDBを管理および設定します。

これらのオプションを比較した結果、オプション1はアプリケーションレイヤでコンテナ内のアプリケーションを管理し、統一された環境でのセットアップを簡素化するための細かいコントロールを提供します。オプション2はDockerレイヤで動作し、迅速なデプロイに理想的です。オプション3はサービス間の最良の分離を提供し、強化されたセキュリティによりプロダクション環境をシミュレートしますが、より複雑なセットアップが必要となります。

慎重に検討した結果、設定タスクの大半をDockerfileからAnsibleプレイブックに移行するオプション1を選択しました。この投稿を書いている現在、これらのプレイブックの実装を行い、コンテナを設定しています。開発状況はこのリポジトリで追跡できます。

謝辞：この経験を通じて、実世界のDevOpsプロジェクトを実装するための実践的なスキルを得ることができました。日常業務以外でこのような知識を学び、個人の時間を有意義に使うことは学校ではあまりカバーされていませんが、それが非常に楽しいです。

このプロジェクトが証明概念として成功すれば、ユーザーからのフィードバックを集め、特にオープンソース開発者からフィードバックを得て、この設定を改善することができます。以前のブログ投稿で言及しましたが、Shafiya、Timid Robot、Saraへの指導とGoogle Summer of Codeによるオープンソースへの貢献機会を与えてくれたことに感謝しています。

オンライン上でさまざまなオープンコンテンツを作成し、楽しんでいるコンテンツクリエイターとして、CCに技術的な専門知識を提供することができることに非常に興奮し、光栄に思います。CCの社会に対する影響により、私は技術スキルを継続的に向上させ、この組織を長期的にサポートすることにコミットしています。

オープンソースコミュニティでのさらなる関与を楽しみにしています！]]></content:encoded>
            <author>['amandayclee']</author>
        </item>
        <item>
            <title><![CDATA[オープンコラボレーションの継続: Creative Commonsと2024年のGSoC]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/continuing-open-collaboration-gsoc-2024-with-creative-commons/</link>
            <guid isPermaLink="false">urn:uuid:e0361bd0-acff-36a8-879f-49a99ba31e29</guid>
            <pubDate>Thu, 22 Aug 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[Creative Commonsリソースアーカイブプロジェクトにおける私の作業最終フェーズに達した今、プロジェクトが始まった頃からどれだけ進展したかを振り返っています。当初はリソースアーカイブサイトの現代化を目指していましたが、安全性とアクセス性を向上させる機能を構築してきました。この旅には課題もありましたが、非常にやりがいのある経験でした。最初の投稿ではプロジェクトの初期段階について述べました。現在最終週を迎え、リソースアーカイブをコミュニティにとって価値あるツールに変える進捗を共有する準備ができています。新しい機能、乗り越えた障害、そして完成した製品について詳しくお話しします。ミッドターム以降の取り組みでは、ミッドタームのマイルストーンを達成後、これまでの経験と学びを活かしてタイムラインに掲載されたタスクを効率的に完了するための作業を行いました。メンターからのアドバイスを受け、余裕を持って取り組むことで伸ばし目標の実現を目指しました。ミッドタームレビューから得たフィードバックは次のステップを導く役割を果たしました。UI関連のタスクでは、提出ページや新規ユーザー向けガイドを作成し、フィルター機能を改善しました。タイムラインタスク完了後の週では、伸ばし目標としてARIAアクセシビリティとLUNR.js検索機能の実装に取り組みました。プロジェクトの範囲と複雑さを考え、これらの目標を選択しました。今後は、LUNR.js検索機能の開発を進めるとともに、ARIAアクセシビリティへの貢献も歓迎します。また、Creative CommonsやCC-Resource-Archiveに対する継続的な貢献を目指しています。このプログラムを通じてプロフェッショナルな経験を得ることができ、メンターからの励ましは非常に価値がありました。オープンソースへの貢献は履歴書の充実だけでなく、コミュニティから得られるサポートとつながりを大切にしましょう。]]></description>
            <content:encoded><![CDATA[Creative Commonsリソースアーカイブプロジェクトにおける私の作業最終フェーズに達した今、プロジェクトが始まった頃からどれだけ進展したかを振り返っています。当初はリソースアーカイブサイトの現代化を目指していましたが、安全性とアクセス性を向上させる機能を構築してきました。この旅には課題もありましたが、非常にやりがいのある経験でした。最初の投稿ではプロジェクトの初期段階について述べました。現在最終週を迎え、リソースアーカイブをコミュニティにとって価値あるツールに変える進捗を共有する準備ができています。新しい機能、乗り越えた障害、そして完成した製品について詳しくお話しします。ミッドターム以降の取り組みでは、ミッドタームのマイルストーンを達成後、これまでの経験と学びを活かしてタイムラインに掲載されたタスクを効率的に完了するための作業を行いました。メンターからのアドバイスを受け、余裕を持って取り組むことで伸ばし目標の実現を目指しました。ミッドタームレビューから得たフィードバックは次のステップを導く役割を果たしました。UI関連のタスクでは、提出ページや新規ユーザー向けガイドを作成し、フィルター機能を改善しました。タイムラインタスク完了後の週では、伸ばし目標としてARIAアクセシビリティとLUNR.js検索機能の実装に取り組みました。プロジェクトの範囲と複雑さを考え、これらの目標を選択しました。今後は、LUNR.js検索機能の開発を進めるとともに、ARIAアクセシビリティへの貢献も歓迎します。また、Creative CommonsやCC-Resource-Archiveに対する継続的な貢献を目指しています。このプログラムを通じてプロフェッショナルな経験を得ることができ、メンターからの励ましは非常に価値がありました。オープンソースへの貢献は履歴書の充実だけでなく、コミュニティから得られるサポートとつながりを大切にしましょう。]]></content:encoded>
            <author>['Murdock9803']</author>
        </item>
        <item>
            <title><![CDATA[自動化公共領域量化：第2部分]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2024-08-22-automating-quantifying/</link>
            <guid isPermaLink="false">urn:uuid:a984b2ae-b334-3c7e-9b5c-54769d5d09b5</guid>
            <pubDate>Thu, 22 Aug 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[導言：期中回顧
本文作為開發過程技術日誌，記錄了2024年Google夏季碼王計劃中的「自動化公共領域量化」項目最後階段的開發進程。如果您尚未閱讀，請訪問第一部分以獲取更多背景信息。
在期中考評時，我成功完成了Google自定義搜索（GCS）數據源的第1、2和3階段（抓取、處理和報告），每個季度都有運作良好的報告README生成。我的目標是在第二階段完成所有數據源的基線自動化軟件開發。
開發過程
I. 中點評估
如果您閱讀過我之前的帖子，可能會看到接下來的步驟是完成剩餘數據源的各個階段。然而，很快我就意識到GCS階段以及來自數據發現計劃的基本分析和可視化代碼已經成為這些任務的標準參考。考慮到這個項目的主要目標是開發這些階段的自動化軟件，我的導師建議將最後一段時間的焦點轉向編程Git功能以實現自動化。
這種方法需要更多時間和精力，但可以確保任何處理剩餘數據源的人都能輕鬆地使用現有代碼作為參考進行集成。
II. GitHub Actions開發
我們定義了GitHub Actions來托管CI/CD工作流程，由於我之前從未使用過YAML，因此需要學習並熟悉這種新技術。學習YAML帶來了一些挑戰，特別是在開發Git自動化方面。我的導師強調要專注於Git編程以應對這些挑戰。
例如，在工作流運行期間遇到了錯誤但沒有明確的debug方法。在我之前的帖子中，我分享了三種策略，幫助我在夏季前半段熟悉新技術。這裡我將分享兩種特別有用的GitHub Actions編程策略：
1. GitHub Actions VSCode擴展
由於我使用VSCode進行開發，在工作流運行期間遇到了難以debug的問題。發現GitHub Actions VSCode擴展是一個轉折點，該擴展可以突出顯示工作流中的問題，使診斷和修復問題變得容易得多。
2. 創建微型任務進行實驗
我設置了自己的GitHub存儲庫，使用最小且功能完整的代碼在低風險環境中實驗GitHub Actions。這種方法有助於更輕鬆地debug和比較，幫助我理解為什麼某些事情不起作用。
III. 自定義錯誤處理和異常系統的設計
這個項目的一個關鍵創新是創建了一個專門為數據管道需求定制的QuantifyingException類。與通用異常不同，這種特殊的異常類旨在捕獲並處理特定於量化過程的錯誤，例如數據不一致、API速率限制和文件處理錯誤。
通過將這些異常集中到QuantifyingException中，確保所有三個階段可以以一致且結構化的方式管理錯誤。在整個系統測試期間，我故意在提交時包含“邊緣情況”錯誤，以確保系統能夠處理所有這些錯誤。
IV. 系統和數據的最終流程
在第一部分中，我分享了初始數據流圖（DFD）來安排代碼庫。然而，在項目結束時，DFD和整個系統已經演變為不同的東西。以下是最終的數據流圖，確立了一個官方框架以供未來使用。
V. 最終結論
I. 所有交付成果完成
雖然這個12週期間允許量化代碼庫的顯著擴展，但我們仍需考慮時間和資源限制；主要是在此期間可以收集到的數據量有限。然而，正如之前提到的，通過戰略性實施，我仍然能夠完成夏季目標，即開發基線自動化軟件以實現數據收集、流動和報告生成，確保腳本每季度運行一次。
130多個提交、7615多行代碼添加以及360多小時的工作後，我在整個夏季期間完成了以下十項關鍵交付成果：
1. 第一階段：抓取數據
2. 第二階段：處理數據（概述）
3. 第三階段：生成報告
4. 共享模塊
5. 目錄序列（OS）
6. 使用GitHub Actions CI/CD自動化
7. 自定義錯誤和異常處理系統
8. 項目目錄樹
9. 數據流+系統設計最終化
10. 總體文檔
II. 致謝、影響及下一步計劃
這個項目沒有我的導師們的持續指導和支持是不可能完成的：Timid Robot Zehta（負責人）、Shafiya Heena（支持）和Sara Lovell（支持）。我非常感謝他們從一開始就為我創造了一個安全的工作空間，讓我能夠隨時提出問題並感到自在。
此外，我也很榮幸能為這個組織做出重大貢獻，並且期待未來與其他CC開源開發者一起促進更多貢獻。對於下一步計劃，我正在量化存儲庫中開放一些GSoC後的問題，這些問題可以由任何開源貢獻者來解決。
如果您對參與感興趣，請訪問方便提供的Issue頁面。您的貢獻將在繼續增強和擴展這個項目時無價之寶，我期待著未來幾年內看到創新性的解決方案和改進！]]></description>
            <content:encoded><![CDATA[導言：期中回顧
本文作為開發過程技術日誌，記錄了2024年Google夏季碼王計劃中的「自動化公共領域量化」項目最後階段的開發進程。如果您尚未閱讀，請訪問第一部分以獲取更多背景信息。
在期中考評時，我成功完成了Google自定義搜索（GCS）數據源的第1、2和3階段（抓取、處理和報告），每個季度都有運作良好的報告README生成。我的目標是在第二階段完成所有數據源的基線自動化軟件開發。
開發過程
I. 中點評估
如果您閱讀過我之前的帖子，可能會看到接下來的步驟是完成剩餘數據源的各個階段。然而，很快我就意識到GCS階段以及來自數據發現計劃的基本分析和可視化代碼已經成為這些任務的標準參考。考慮到這個項目的主要目標是開發這些階段的自動化軟件，我的導師建議將最後一段時間的焦點轉向編程Git功能以實現自動化。
這種方法需要更多時間和精力，但可以確保任何處理剩餘數據源的人都能輕鬆地使用現有代碼作為參考進行集成。
II. GitHub Actions開發
我們定義了GitHub Actions來托管CI/CD工作流程，由於我之前從未使用過YAML，因此需要學習並熟悉這種新技術。學習YAML帶來了一些挑戰，特別是在開發Git自動化方面。我的導師強調要專注於Git編程以應對這些挑戰。
例如，在工作流運行期間遇到了錯誤但沒有明確的debug方法。在我之前的帖子中，我分享了三種策略，幫助我在夏季前半段熟悉新技術。這裡我將分享兩種特別有用的GitHub Actions編程策略：
1. GitHub Actions VSCode擴展
由於我使用VSCode進行開發，在工作流運行期間遇到了難以debug的問題。發現GitHub Actions VSCode擴展是一個轉折點，該擴展可以突出顯示工作流中的問題，使診斷和修復問題變得容易得多。
2. 創建微型任務進行實驗
我設置了自己的GitHub存儲庫，使用最小且功能完整的代碼在低風險環境中實驗GitHub Actions。這種方法有助於更輕鬆地debug和比較，幫助我理解為什麼某些事情不起作用。
III. 自定義錯誤處理和異常系統的設計
這個項目的一個關鍵創新是創建了一個專門為數據管道需求定制的QuantifyingException類。與通用異常不同，這種特殊的異常類旨在捕獲並處理特定於量化過程的錯誤，例如數據不一致、API速率限制和文件處理錯誤。
通過將這些異常集中到QuantifyingException中，確保所有三個階段可以以一致且結構化的方式管理錯誤。在整個系統測試期間，我故意在提交時包含“邊緣情況”錯誤，以確保系統能夠處理所有這些錯誤。
IV. 系統和數據的最終流程
在第一部分中，我分享了初始數據流圖（DFD）來安排代碼庫。然而，在項目結束時，DFD和整個系統已經演變為不同的東西。以下是最終的數據流圖，確立了一個官方框架以供未來使用。
V. 最終結論
I. 所有交付成果完成
雖然這個12週期間允許量化代碼庫的顯著擴展，但我們仍需考慮時間和資源限制；主要是在此期間可以收集到的數據量有限。然而，正如之前提到的，通過戰略性實施，我仍然能夠完成夏季目標，即開發基線自動化軟件以實現數據收集、流動和報告生成，確保腳本每季度運行一次。
130多個提交、7615多行代碼添加以及360多小時的工作後，我在整個夏季期間完成了以下十項關鍵交付成果：
1. 第一階段：抓取數據
2. 第二階段：處理數據（概述）
3. 第三階段：生成報告
4. 共享模塊
5. 目錄序列（OS）
6. 使用GitHub Actions CI/CD自動化
7. 自定義錯誤和異常處理系統
8. 項目目錄樹
9. 數據流+系統設計最終化
10. 總體文檔
II. 致謝、影響及下一步計劃
這個項目沒有我的導師們的持續指導和支持是不可能完成的：Timid Robot Zehta（負責人）、Shafiya Heena（支持）和Sara Lovell（支持）。我非常感謝他們從一開始就為我創造了一個安全的工作空間，讓我能夠隨時提出問題並感到自在。
此外，我也很榮幸能為這個組織做出重大貢獻，並且期待未來與其他CC開源開發者一起促進更多貢獻。對於下一步計劃，我正在量化存儲庫中開放一些GSoC後的問題，這些問題可以由任何開源貢獻者來解決。
如果您對參與感興趣，請訪問方便提供的Issue頁面。您的貢獻將在繼續增強和擴展這個項目時無價之寶，我期待著未來幾年內看到創新性的解決方案和改進！]]></content:encoded>
            <author>['NaishaSinha']</author>
        </item>
        <item>
            <title><![CDATA[AnsibleとDockerを使用したローカル環境の作成：パート1]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2024-07-19-create-local-ansible-dev-env/</link>
            <guid isPermaLink="false">urn:uuid:6b1318ac-36d5-3881-a3fb-235ad3557944</guid>
            <pubDate>Thu, 18 Jul 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[このプロジェクトでは、クリエイティブコモンズ（CC）がシステム管理ツールであるAnsibleを用いて、ローカル開発環境を構築する方法について探求します。これは2024年のGoogle Summer of Code (GSoC)の一環です。

プロジェクトの目的と背景：
このプロジェクトでは、CCの生産環境に近いローカル開発環境を確立することを目指しています。現在、CCはSalt Stackを使用して構成管理を行っていますが、さまざまな理由から他のツールも評価しています。本プロジェクトでは、シンプルさと強力な自動化機能で知られるAnsibleの使用を検討しました。また、Dockerコンテナと組み合わせることで、開発プロセスを効率的かつ安全にし、アプリケーションを実行するための軽量で隔離された環境を作成しました。

課題と学びの機会：
このプロジェクトが始まる前には、プロフェッショナルなDevOpsの慣行についての経験がありませんでしたので、これは大きな学習体験となりました。特にデプロイメント段階におけるDevOpsライフサイクルの設定（サーバーのセットアップ）と構成管理（ソフトウェアや設定の管理）に焦点を当てています。

週ごとの進捗：
私は最初に公式ドキュメンテーションからDockerとAnsibleのセットアップガイドに従い、初期ansibleコンテナをデプロイしました。これは、コンテナ化された環境内でAnsibleの基本的な機能と設定に対する理解を得るための重要なステップでした。

2週目には、現在のCreativeCommons.orgのローカル開発環境であるindex-devリポジトリをウェブサーバーとデータベースサーバーに分割し、Bastionサーバーのセットアップと統合も検討しました。これにより、プライベートネットワークへのアクセス制御を強化するセキュアなアプローチが可能になりました。

3週目には、メンターShafiyaの指導のもとでローカルマシンとウェブ、データベース、ansibleサーバー間でのSSHアクセスを確立しました。これにより、Ansibleコンテナから他のコンテナを安全に自動管理することが可能になりました。

4週目には、Ansibleプレイブックの作成を始め、元々web Dockerfileにあった設定をプレイブックに移行しました。DockerfilesとAnsibleプレイブックの組み合わせは一般的なベストプラクティスで、前者がOSや基本ツールを含むベースイメージを作り、後者がアプリケーションやサービスの構成を行います。

オープンソースでのコミュニケーションとコラボレーション：
CCチーム（メンターShafiya、Timid Robot、Saraなど）はシステム設計や全体的なアーキテクチャに関する貴重な洞察を提供しました。週次シンクミーティングと1対1のセッションの柔軟性によりスムーズに進行できました。

結論と次のステップ：
今後は、Ansibleプレイブックの改善、バグや問題への対応、セキュリティとスケーラビリティに関する課題を解決することを目指します。生産環境に近いローカル開発環境を提供するためには、強力で効率的なものが必要です。]]></description>
            <content:encoded><![CDATA[このプロジェクトでは、クリエイティブコモンズ（CC）がシステム管理ツールであるAnsibleを用いて、ローカル開発環境を構築する方法について探求します。これは2024年のGoogle Summer of Code (GSoC)の一環です。

プロジェクトの目的と背景：
このプロジェクトでは、CCの生産環境に近いローカル開発環境を確立することを目指しています。現在、CCはSalt Stackを使用して構成管理を行っていますが、さまざまな理由から他のツールも評価しています。本プロジェクトでは、シンプルさと強力な自動化機能で知られるAnsibleの使用を検討しました。また、Dockerコンテナと組み合わせることで、開発プロセスを効率的かつ安全にし、アプリケーションを実行するための軽量で隔離された環境を作成しました。

課題と学びの機会：
このプロジェクトが始まる前には、プロフェッショナルなDevOpsの慣行についての経験がありませんでしたので、これは大きな学習体験となりました。特にデプロイメント段階におけるDevOpsライフサイクルの設定（サーバーのセットアップ）と構成管理（ソフトウェアや設定の管理）に焦点を当てています。

週ごとの進捗：
私は最初に公式ドキュメンテーションからDockerとAnsibleのセットアップガイドに従い、初期ansibleコンテナをデプロイしました。これは、コンテナ化された環境内でAnsibleの基本的な機能と設定に対する理解を得るための重要なステップでした。

2週目には、現在のCreativeCommons.orgのローカル開発環境であるindex-devリポジトリをウェブサーバーとデータベースサーバーに分割し、Bastionサーバーのセットアップと統合も検討しました。これにより、プライベートネットワークへのアクセス制御を強化するセキュアなアプローチが可能になりました。

3週目には、メンターShafiyaの指導のもとでローカルマシンとウェブ、データベース、ansibleサーバー間でのSSHアクセスを確立しました。これにより、Ansibleコンテナから他のコンテナを安全に自動管理することが可能になりました。

4週目には、Ansibleプレイブックの作成を始め、元々web Dockerfileにあった設定をプレイブックに移行しました。DockerfilesとAnsibleプレイブックの組み合わせは一般的なベストプラクティスで、前者がOSや基本ツールを含むベースイメージを作り、後者がアプリケーションやサービスの構成を行います。

オープンソースでのコミュニケーションとコラボレーション：
CCチーム（メンターShafiya、Timid Robot、Saraなど）はシステム設計や全体的なアーキテクチャに関する貴重な洞察を提供しました。週次シンクミーティングと1対1のセッションの柔軟性によりスムーズに進行できました。

結論と次のステップ：
今後は、Ansibleプレイブックの改善、バグや問題への対応、セキュリティとスケーラビリティに関する課題を解決することを目指します。生産環境に近いローカル開発環境を提供するためには、強力で効率的なものが必要です。]]></content:encoded>
            <author>['amandayclee']</author>
        </item>
        <item>
            <title><![CDATA[オープン知識を強化する: Creative CommonsとのGSoC 2024]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/empowering-open-knowledge-gsoc-2024-with-creative-commons/</link>
            <guid isPermaLink="false">urn:uuid:e31bd330-2d85-340b-b501-7fe07a81290d</guid>
            <pubDate>Wed, 10 Jul 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは、皆さん！私の名前はAyush Sahuで、この夏、Google Summer of Code (2024) プログラムを通じてCreative Commonsに参加することになりました。オープン知識の熱心な擁護者であり、協働的なイノベーションの力に対する確信を持つ私にとって、情報と創造性の自由な交換を長年にわたって主導してきた組織に貢献できることを感謝しています。Creative Commonsとのコラボレーションを志願したのは、個人的に大きな影響を与えたからです。YouTubeチャンネルで動画を作成していた子供時代には、Creative Commonsが提供するリソースに非常に感謝していました。彼らの自由でオープンな知識の推進により、伝統的なライセンス制限なしに高品質なコンテンツにアクセスでき、創造性と情報共有への情熱を育てることができました。この経験は私の中に組織とそのミッションに対する深い敬意を植え付けました。

私が取り組むプロジェクト

プロジェクト - CCリソースアーカイブの現代化では、CCの現在の美学や機能基準に合わせた包括的なビジュアルオーバーホールを実装することを目指しています。内部デザインシステム（Vocabulary）を使用して、視覚設計のアップグレード、意味的でアクセシブルで標準準拠のHTML、CSS、JavaScriptの実装、リソース提出時のユーザーエクスペリエンス（UX）の改善を行い、GitHub Pagesでのサイト安定性を確保します。これらの努力と充実したドキュメンテーションを通じて、刷新されたリソースアーカイブは現代の基準に適合し、ユーザーと開発者の両方にとって使いやすさと維持可能性が向上します。

コミュニティ絆期間

コミュニティ絆期間は非常に豊かな体験でした。この期間中、私はメンターと会い、プロジェクトを理解し、Creative Commonsの活気あるコミュニティに参加する機会がありました。ミーティングやディスカッションに参加することで、組織の価値観やコードベースに対する理解が深まりました。コミュニティから提供された暖かい歓迎と豊富な知識は本当にインスピレーションを提供しました。

環境、コード、アイデア - 週1〜3

プロジェクトの最初の数週間では、開発環境のテスト、将来のUI変更の計画、作業プロセスへの慣れを行いました。まず、私のプロジェクトメンターであるSaraが私を初めてのコード貢献に導いてくれました。私はCreative Commons OrganizationでGitHubメンバーとしてステータスを与えられ、これは私にとって新しくて興奮する経験でした。主な達成点は：PR#266 - docker-compose.ymlファイルを現在の仕様に更新しました。メンターの助けを得て、このコード期間での最初のプルリクエストを開きました。docker-compose.ymlファイルの上部にあるバージョン要素は情報提供のみであり、ファイルが仕様から外れていました。

Docker設定のテスト：メンターのSaraとTimid Robotの大きな助けを得て、開発用のDocker環境を整えました。Jekyllについて学び、Vocabularyコードを読みました。vocabulary.css内のクラスやlibrary-vars.css内のカスタムCSS変数に慣れました。

アクセシビリティ改善：キーボードナビゲーションとsemantic HTMLおよび適切なCSSプロパティを使用したウェブサイトのアクセシビリティ向上について学びました。

課題リスト：意味的なコードやUI変更に関連する問題を特定し、リストにしました。また、メンターからの提案でいくつかのタスクをTODOリストに追加しました。現在のファイル構造をレビューし、理解性と類似ファイルのグループ化を改善するアイデアを考えました。

これらの最初の数週間の終わりには、コードや計画に対する十分な時間を費やしたことを認識しましたが、メンターからの提案で実際に作業を行うことでスムーズになることがわかりました。そのため、今後の週に計画されたタスクを実行するペースを上げることに決めました。

実行、更新、再設計 - 週4〜6

中間評価が近づくにつれて、我々は毎週のレビュー会議を開き、変更と貢献を計画しました。5週目と6週目のペースが上がり、UI変更やコードリファクタリングに焦点を当てた多くのプルリクエストが提出されました。

ファイル構造改善：メンターとの話し合いで、理解性と維持可能性を向上させるためにファイル構造を改善しました。構造を更新した後、変更されたすべてのファイルへのパスを修正しました。これにより、問題に対応する一連のプルリクエストが作成されました。

リストページUI変更：listing.htmlページはindex.htmlとall.htmlページでリソースカードを表示します。これらのリソースカードには古いビジュアル設定があり、Creative Commonsの内部デザインシステムであるVocabularyに合わせる必要がありました。PR#298を通じて以下のタスクを行いました。

HTML構造の再設計：IMAGE - TITLE - BLURBの形式にリソースカードのHTML構造を再設計しました。listing.htmlでthumbnailリストのスタイルを強化しました。style.cssでのグリッド構造の作業を行い、thumbnailボックス、thumbnailタイトル、thumbnail画像、thumbnailブリーフィングのスタイル改善を行いました。

フォント、背景色などにVocabularyに基づいて調整を行い、vocabularyから--underline-background-colorなどのプロパティをstyle.cssに割り当てました。style.cssとlisting.htmlファイルをprettierで整形し、レスポンシブネスを修正しました。style.cssに理解性のためのドキュメンテーションを追加しました。

リストページ（全）JavaScript変更：listing.htmlファイル内のjavascriptコードはページセクション内にありました。このコードは古く、ES6 JavaScript概念が不足していました。例えば、varキーワードやdocument.write()メソッドの使用がありました。このコードはリソース表示に関連する多くのタスクを担当しており、URLからユーザー選択されたカテゴリを抽出し、それらを変数として返す機能もありました。

PR#300を通じて以下のタスクが完了しました：ES6 JavaScript概念に従って関数とコードを更新。document.write()メソッドを使用した代わりに、ES6の新しいメソッドを使用してコードを再設計しました。style.cssファイルに理解性のためのドキュメンテーションを追加しました。

PR#298を通じて以下のタスクが完了しました：ES6 JavaScript概念に従って関数とコードを更新。document.write()メソッドを使用した代わりに、ES6の新しいメソッドを使用してコードを再設計しました。

感謝と謝辞

メンターおよびCreative Commonsコミュニティ全員にこの素晴らしい機会を与えてくれたことに心からの感謝を表したいと思います。あなたのサポートと指導は非常に価値がありました。特に私のメンターであるSara Lovell（Possumbilities）には、技術的な助けだけでなく、モチベーション、サポート、励ましも提供していただき、本当に感謝しています。

またTimid RobotとShafiya Heenaも常に必要なときに支援してくれました。週次レビュー会議や開発環境に関する疑問など、どんなことでも一人で取り組むことはありませんでした。

今後もあなたの指導のもとでさらに貢献していきたいと思います。

参加方法

プロジェクトに参加するさまざまな方法があります。フィードバックの提供、コードベースへの貢献、またはオープン知識について広めるなど、あなたの参加が強く求められています。GitHubリポジトリをチェックアウトして、コードベースとディスカッションに参加することができます。]]></description>
            <content:encoded><![CDATA[こんにちは、皆さん！私の名前はAyush Sahuで、この夏、Google Summer of Code (2024) プログラムを通じてCreative Commonsに参加することになりました。オープン知識の熱心な擁護者であり、協働的なイノベーションの力に対する確信を持つ私にとって、情報と創造性の自由な交換を長年にわたって主導してきた組織に貢献できることを感謝しています。Creative Commonsとのコラボレーションを志願したのは、個人的に大きな影響を与えたからです。YouTubeチャンネルで動画を作成していた子供時代には、Creative Commonsが提供するリソースに非常に感謝していました。彼らの自由でオープンな知識の推進により、伝統的なライセンス制限なしに高品質なコンテンツにアクセスでき、創造性と情報共有への情熱を育てることができました。この経験は私の中に組織とそのミッションに対する深い敬意を植え付けました。

私が取り組むプロジェクト

プロジェクト - CCリソースアーカイブの現代化では、CCの現在の美学や機能基準に合わせた包括的なビジュアルオーバーホールを実装することを目指しています。内部デザインシステム（Vocabulary）を使用して、視覚設計のアップグレード、意味的でアクセシブルで標準準拠のHTML、CSS、JavaScriptの実装、リソース提出時のユーザーエクスペリエンス（UX）の改善を行い、GitHub Pagesでのサイト安定性を確保します。これらの努力と充実したドキュメンテーションを通じて、刷新されたリソースアーカイブは現代の基準に適合し、ユーザーと開発者の両方にとって使いやすさと維持可能性が向上します。

コミュニティ絆期間

コミュニティ絆期間は非常に豊かな体験でした。この期間中、私はメンターと会い、プロジェクトを理解し、Creative Commonsの活気あるコミュニティに参加する機会がありました。ミーティングやディスカッションに参加することで、組織の価値観やコードベースに対する理解が深まりました。コミュニティから提供された暖かい歓迎と豊富な知識は本当にインスピレーションを提供しました。

環境、コード、アイデア - 週1〜3

プロジェクトの最初の数週間では、開発環境のテスト、将来のUI変更の計画、作業プロセスへの慣れを行いました。まず、私のプロジェクトメンターであるSaraが私を初めてのコード貢献に導いてくれました。私はCreative Commons OrganizationでGitHubメンバーとしてステータスを与えられ、これは私にとって新しくて興奮する経験でした。主な達成点は：PR#266 - docker-compose.ymlファイルを現在の仕様に更新しました。メンターの助けを得て、このコード期間での最初のプルリクエストを開きました。docker-compose.ymlファイルの上部にあるバージョン要素は情報提供のみであり、ファイルが仕様から外れていました。

Docker設定のテスト：メンターのSaraとTimid Robotの大きな助けを得て、開発用のDocker環境を整えました。Jekyllについて学び、Vocabularyコードを読みました。vocabulary.css内のクラスやlibrary-vars.css内のカスタムCSS変数に慣れました。

アクセシビリティ改善：キーボードナビゲーションとsemantic HTMLおよび適切なCSSプロパティを使用したウェブサイトのアクセシビリティ向上について学びました。

課題リスト：意味的なコードやUI変更に関連する問題を特定し、リストにしました。また、メンターからの提案でいくつかのタスクをTODOリストに追加しました。現在のファイル構造をレビューし、理解性と類似ファイルのグループ化を改善するアイデアを考えました。

これらの最初の数週間の終わりには、コードや計画に対する十分な時間を費やしたことを認識しましたが、メンターからの提案で実際に作業を行うことでスムーズになることがわかりました。そのため、今後の週に計画されたタスクを実行するペースを上げることに決めました。

実行、更新、再設計 - 週4〜6

中間評価が近づくにつれて、我々は毎週のレビュー会議を開き、変更と貢献を計画しました。5週目と6週目のペースが上がり、UI変更やコードリファクタリングに焦点を当てた多くのプルリクエストが提出されました。

ファイル構造改善：メンターとの話し合いで、理解性と維持可能性を向上させるためにファイル構造を改善しました。構造を更新した後、変更されたすべてのファイルへのパスを修正しました。これにより、問題に対応する一連のプルリクエストが作成されました。

リストページUI変更：listing.htmlページはindex.htmlとall.htmlページでリソースカードを表示します。これらのリソースカードには古いビジュアル設定があり、Creative Commonsの内部デザインシステムであるVocabularyに合わせる必要がありました。PR#298を通じて以下のタスクを行いました。

HTML構造の再設計：IMAGE - TITLE - BLURBの形式にリソースカードのHTML構造を再設計しました。listing.htmlでthumbnailリストのスタイルを強化しました。style.cssでのグリッド構造の作業を行い、thumbnailボックス、thumbnailタイトル、thumbnail画像、thumbnailブリーフィングのスタイル改善を行いました。

フォント、背景色などにVocabularyに基づいて調整を行い、vocabularyから--underline-background-colorなどのプロパティをstyle.cssに割り当てました。style.cssとlisting.htmlファイルをprettierで整形し、レスポンシブネスを修正しました。style.cssに理解性のためのドキュメンテーションを追加しました。

リストページ（全）JavaScript変更：listing.htmlファイル内のjavascriptコードはページセクション内にありました。このコードは古く、ES6 JavaScript概念が不足していました。例えば、varキーワードやdocument.write()メソッドの使用がありました。このコードはリソース表示に関連する多くのタスクを担当しており、URLからユーザー選択されたカテゴリを抽出し、それらを変数として返す機能もありました。

PR#300を通じて以下のタスクが完了しました：ES6 JavaScript概念に従って関数とコードを更新。document.write()メソッドを使用した代わりに、ES6の新しいメソッドを使用してコードを再設計しました。style.cssファイルに理解性のためのドキュメンテーションを追加しました。

PR#298を通じて以下のタスクが完了しました：ES6 JavaScript概念に従って関数とコードを更新。document.write()メソッドを使用した代わりに、ES6の新しいメソッドを使用してコードを再設計しました。

感謝と謝辞

メンターおよびCreative Commonsコミュニティ全員にこの素晴らしい機会を与えてくれたことに心からの感謝を表したいと思います。あなたのサポートと指導は非常に価値がありました。特に私のメンターであるSara Lovell（Possumbilities）には、技術的な助けだけでなく、モチベーション、サポート、励ましも提供していただき、本当に感謝しています。

またTimid RobotとShafiya Heenaも常に必要なときに支援してくれました。週次レビュー会議や開発環境に関する疑問など、どんなことでも一人で取り組むことはありませんでした。

今後もあなたの指導のもとでさらに貢献していきたいと思います。

参加方法

プロジェクトに参加するさまざまな方法があります。フィードバックの提供、コードベースへの貢献、またはオープン知識について広めるなど、あなたの参加が強く求められています。GitHubリポジトリをチェックアウトして、コードベースとディスカッションに参加することができます。]]></content:encoded>
            <author>['Murdock9803']</author>
        </item>
        <item>
            <title><![CDATA[共通領域の量化を自動化：第1部]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2024-07-10-automating-quantifying/</link>
            <guid isPermaLink="false">urn:uuid:b2a3d487-e31e-3090-8a53-296e27ced5f7</guid>
            <pubDate>Wed, 10 Jul 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[UCバークレー大学データサイエンスディスカバリープログラムから生まれた「共通領域の量化」イニシアチブは、将来のアクセスと分析のためにオープンドメインやCCライセンスの使用頻度を定量的に評価することを目指しています（詳細については、初期のCC記事をご覧ください）。これまでのプロジェクトの進捗では、自動化や統合レポート作成が含まれていませんでした。これは人間のエラーを最小限に抑え、特に大量のデータと対話するシステムにおいてタイムリーな更新を可能にするために必要です。2024年のGoogle Summer of Codeで選ばれた開発者として、この夏の目標はデータ収集、フロー、レポート作成の自動化ソフトウェアを開発し、レポートが常に3ヶ月以内に更新されるようにすることです。このブログ記事は、中間評価期までの中間的な技術日誌となります。「共通領域の量化を自動化：第2部」は、夏プログラム全体が成功した後に投稿されます。

プロジェクト開始前の知識と関連する課題：私はまだコードベースに慣れておらず、これまで最も複雑なソフトウェア開発経験としては中程度の複雑さを持つフルスタックアプリケーションでした。Quantifyingへの私の前GSoC貢献では、Pythonファイル全体でログを実装しました（PR #97）。しかし、他のモジュールについてはよく理解していませんでした。

開発プロセス：データフローダイアグラムの作成から始めて、Googleカスタムサーチデータソースのソフトウェア開発に取り組みました。次にディレクトリ設定とコード実装を行い、データ取得、処理、レポート生成の各フェーズを順序立てて進めた。

中期プログラムの結論と今後のタスク：Googleカスタムサーチのすべてのフェーズを完了したことで、スキルセットが大幅に向上しました。次期は他のデータソースについて効率的に開発を進めます。最終目標は、2024年のGSoC終了時にすべてのデータソースに対するフェーズ1から3までの機能を備えた自動化システムを開発することです。]]></description>
            <content:encoded><![CDATA[UCバークレー大学データサイエンスディスカバリープログラムから生まれた「共通領域の量化」イニシアチブは、将来のアクセスと分析のためにオープンドメインやCCライセンスの使用頻度を定量的に評価することを目指しています（詳細については、初期のCC記事をご覧ください）。これまでのプロジェクトの進捗では、自動化や統合レポート作成が含まれていませんでした。これは人間のエラーを最小限に抑え、特に大量のデータと対話するシステムにおいてタイムリーな更新を可能にするために必要です。2024年のGoogle Summer of Codeで選ばれた開発者として、この夏の目標はデータ収集、フロー、レポート作成の自動化ソフトウェアを開発し、レポートが常に3ヶ月以内に更新されるようにすることです。このブログ記事は、中間評価期までの中間的な技術日誌となります。「共通領域の量化を自動化：第2部」は、夏プログラム全体が成功した後に投稿されます。

プロジェクト開始前の知識と関連する課題：私はまだコードベースに慣れておらず、これまで最も複雑なソフトウェア開発経験としては中程度の複雑さを持つフルスタックアプリケーションでした。Quantifyingへの私の前GSoC貢献では、Pythonファイル全体でログを実装しました（PR #97）。しかし、他のモジュールについてはよく理解していませんでした。

開発プロセス：データフローダイアグラムの作成から始めて、Googleカスタムサーチデータソースのソフトウェア開発に取り組みました。次にディレクトリ設定とコード実装を行い、データ取得、処理、レポート生成の各フェーズを順序立てて進めた。

中期プログラムの結論と今後のタスク：Googleカスタムサーチのすべてのフェーズを完了したことで、スキルセットが大幅に向上しました。次期は他のデータソースについて効率的に開発を進めます。最終目標は、2024年のGSoC終了時にすべてのデータソースに対するフェーズ1から3までの機能を備えた自動化システムを開発することです。]]></content:encoded>
            <author>['NaishaSinha']</author>
        </item>
        <item>
            <title><![CDATA[CreativeCommons.org、2023年9月にリニューアルオープン]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2024-05-28-creativecommons-org/</link>
            <guid isPermaLink="false">urn:uuid:195af2a0-2a00-31c2-864b-ab98b3cb2433</guid>
            <pubDate>Tue, 28 May 2024 00:00:00 GMT</pubDate>
            <description><![CDATA[クリエイティブコモンズ（CC）は、2023年9月27日に新しいCreativeCommons.orgウェブサイトを公開しました。このリニューアルでは、ウェブサイトだけでなく、技術スタック全体（プラットフォーム、サーバー、およびウェブサイトのコンポーネント）も刷新されました。

改善されたプラットフォーム：新しくなったウェブサイトはAWSでホストされています。これにより、サービス間のより安全なネットワークアーキテクチャを設計し、インフラスケジュールとしてコードを使用してサービスをデプロイおよび管理できるようになりました。

改善されたサービス：ウェブサイトを動かすためのサービスが簡素化され更新されました。サーバーの数は6つから2つに削減されました。以前は、ホームページを読み込むにはHAProxy、Varnish、Apache2、PHP+FPM、MariaDBという5つのサービスが必要でした。古いサービスの複雑さによりトラブルシューティングが難しくなりました。これらはCloudflareがProject Galileoを通じて私たちをサポートする前から設計されていました。

新ウェブサイトでは、Apache2とMariaDBという2つのサービスのみで動作します。

改善されたウェブサイトのコンポーネント：語彙（creativecommons/vocabulary）を使用して一貫したユーザーエクスペリエンスを提供するさまざまなコンポーネントから構成されています。このリニューアルは新しい語彙の最初の実装であり、ウェブの基本原則に立ち返り、意味的なHTMLと適切な範囲のCSSスタイルを使用しています。

WordPress：プロジェクトには新しい語彙デザインシステムを実装するカスタムWordPressテーマ（creativecommons/vocabulary-theme）が使用されています。このテーマは長期的な安定性とより安定したユーザーエクスペリエンスのために、WordPressクラシックエディタを利用しています。Gutenbergはまだ十分なアクセシビリティアプローチを遵守しておらず、機能の完全性も不確定です。

CCライセンスツール：新しいウェブサイトのデプロイとともに、旧来のccEngineを新しくしたCC Legal Toolsに置き換えました。現在の法律ツールの風景はシンプルで、7つのツール（CC BY 4.0、CC BY-NC 4.0など）のみです。

新しいCC Legal Toolsアプリは3万以上のドキュメントを管理します！2020年にリクエストフォーム（RFP: License Infrastructure - Google Docs）からプロジェクトが始まりました。Caktus GroupがDjango Pythonウェブフレームワークを使用して新しくしたCC Legal Toolsの作業は、Timid Robotによって継続されました。

新しいCC Legal Toolsには以下の利点があります：現在サポートされているソフトウェア（Python 3、Django 4.2など）、簡素化されたデータモデル、改善された翻訳処理、改善されたRDF/XML生成/管理等。特に新しくなったCC Legal Toolsが静的資産を生成することに注目してください。

開発の改善：インフラスケジュールとしてコードを使用することで、より堅牢なステージング環境を持っています。これにより、生産環境へのデプロイ時にリスクを最小限に抑えるために大きな変更をプレビューできます。また、ローカル開発環境とコンテンツ同期ツールも改善しました。

新しいウェブサイトの成功に直接貢献してくれた人々に感謝します！]]></description>
            <content:encoded><![CDATA[クリエイティブコモンズ（CC）は、2023年9月27日に新しいCreativeCommons.orgウェブサイトを公開しました。このリニューアルでは、ウェブサイトだけでなく、技術スタック全体（プラットフォーム、サーバー、およびウェブサイトのコンポーネント）も刷新されました。

改善されたプラットフォーム：新しくなったウェブサイトはAWSでホストされています。これにより、サービス間のより安全なネットワークアーキテクチャを設計し、インフラスケジュールとしてコードを使用してサービスをデプロイおよび管理できるようになりました。

改善されたサービス：ウェブサイトを動かすためのサービスが簡素化され更新されました。サーバーの数は6つから2つに削減されました。以前は、ホームページを読み込むにはHAProxy、Varnish、Apache2、PHP+FPM、MariaDBという5つのサービスが必要でした。古いサービスの複雑さによりトラブルシューティングが難しくなりました。これらはCloudflareがProject Galileoを通じて私たちをサポートする前から設計されていました。

新ウェブサイトでは、Apache2とMariaDBという2つのサービスのみで動作します。

改善されたウェブサイトのコンポーネント：語彙（creativecommons/vocabulary）を使用して一貫したユーザーエクスペリエンスを提供するさまざまなコンポーネントから構成されています。このリニューアルは新しい語彙の最初の実装であり、ウェブの基本原則に立ち返り、意味的なHTMLと適切な範囲のCSSスタイルを使用しています。

WordPress：プロジェクトには新しい語彙デザインシステムを実装するカスタムWordPressテーマ（creativecommons/vocabulary-theme）が使用されています。このテーマは長期的な安定性とより安定したユーザーエクスペリエンスのために、WordPressクラシックエディタを利用しています。Gutenbergはまだ十分なアクセシビリティアプローチを遵守しておらず、機能の完全性も不確定です。

CCライセンスツール：新しいウェブサイトのデプロイとともに、旧来のccEngineを新しくしたCC Legal Toolsに置き換えました。現在の法律ツールの風景はシンプルで、7つのツール（CC BY 4.0、CC BY-NC 4.0など）のみです。

新しいCC Legal Toolsアプリは3万以上のドキュメントを管理します！2020年にリクエストフォーム（RFP: License Infrastructure - Google Docs）からプロジェクトが始まりました。Caktus GroupがDjango Pythonウェブフレームワークを使用して新しくしたCC Legal Toolsの作業は、Timid Robotによって継続されました。

新しいCC Legal Toolsには以下の利点があります：現在サポートされているソフトウェア（Python 3、Django 4.2など）、簡素化されたデータモデル、改善された翻訳処理、改善されたRDF/XML生成/管理等。特に新しくなったCC Legal Toolsが静的資産を生成することに注目してください。

開発の改善：インフラスケジュールとしてコードを使用することで、より堅牢なステージング環境を持っています。これにより、生産環境へのデプロイ時にリスクを最小限に抑えるために大きな変更をプレビューできます。また、ローカル開発環境とコンテンツ同期ツールも改善しました。

新しいウェブサイトの成功に直接貢献してくれた人々に感謝します！]]></content:encoded>
            <author>['sara', 'shafiya', 'TimidRobot']</author>
        </item>
        <item>
            <title><![CDATA[CC Legal Tools: Machine-Readable Layer]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2023-08-25-machine-layer/</link>
            <guid isPermaLink="false">urn:uuid:4405215a-c845-3736-9382-8f4e7426f4fb</guid>
            <pubDate>Mon, 28 Aug 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは、読者の皆様！🌟 Google Summer of Code (GSoC) 2023の一環として、興奮を抑えられないプロジェクト「CC Legal Tools: Machine-Readable Layer」に貢献する素晴らしい機会を得ました。この旅は学び、コーディング、そしてコラボレーションの組み合わせで、皆さんとそのハイライトをお伝えするのが楽しみです。

プロジェクト概要：
このプロジェクトの核心的な焦点は、Creative Commons (CC) Legal Toolsアプリに強力な機械可読層を導入することでした。機械可読層はコンピュータがCCライセンスの詳細を理解できるようにし、法的専門家、開発者、そして愛好家のためのプログラム可能なCCライセンス作業を容易にします。

始まり：
私の旅は既存のコードベースへの没頭とプロジェクト要件の理解から始まりました。つまり、アプリのアーキテクチャ、そのコンポーネント、そして現在どのようにCCライセンスを処理しているかを理解することは、これから何が待っているのかにとって不可欠でした。RDF（リソース記述フレームワーク）はプロジェクトで重要な役割を果たしました。RDFの複雑さとライセンス表現におけるその役割を理解することは、この旅での必要なステップでした。

課題と学びの機会：
私の早期の挑戦の一つは、レガシーファイルであるRDF/XMLファイルの複雑性を解き明かすことにありました。それらが私たちが生成しようとしている新しいRDF/XMLファイルとはどのように異なるのでしょうか？この探求を通じて、構造の改善、ライセンス情報の更新、追加のメタデータを見つける機会がありました。さまざまなライセンスとバージョンに対してRDFファイルを生成することは、解き明かすパズルとなりました。RDFトリプルを作成し、ライセンシングのニュアンスを理解し、このロジックをアプリのビューに組み込むことは、学びの機会であり、報われた挑戦でした。

貢献と作業：
プロジェクトが進むにつれて、私は動的にRDF/XMLファイルを生成するための作業を行い、これによりアプリはオンデマンドで機械可読なライセンスを生成できるようになりました。整理されたアプローチを維持するために、生成されたRDFファイルがソートされることを確認しました。これはTimid Robotによるものです。新たに生成されたRDF/XMLは、Creative Commonsライセンスの表現における明確性、正確性、互換性、標準化を向上させることが目的です。これらの改善により、機械可読性とセマンティック理解が促進され、デジタルシステムでのシームレスな統合と解釈が可能になります。

変更の概要：
構造と一貫性の改善：新しいRDF/XMLはより組織化された標準化された構造を特徴としており、RDF標準に準拠しています。これにより、機械の理解と正確なデータ処理が向上します。
ライセンス情報の更新：ライセンス情報は最新の権限と制限を反映するように更新されています。これにより、ユーザーとシステムが正確に情報を得ることができます。
RDFベストプラクティスへの準拠：変更はRDFベストプラクティスとの準拠を強化します。標準化されたネームスペース、一貫した命名法、適切な関係定義のおかげで、相互運用性と互換性が向上します。

旅の過程で、私はメンターと共に密接に働き、協力的な議論を行い、洞察深いコードレビューを受けました。GSoCの旅が終わりを迎えようとしている今、CC Legal Toolsアプリの基礎を築いたことに興奮しています。機械可読層はスマートで自動化された法的手続きの未来を開く門となり、GSoCでの改善はCC Legal Toolsアプリ全体に波及し、ユーザーと広範なオープンソースコミュニティに恩恵をもたらします。

メンターとサポート：
この素晴らしい旅を通じて私を導いてくれたTimid Robotに心からの感謝を伝えます。あなたの不動の支援、知恵、フィードバック、知識共有への情熱は本当に価値がありました。あなたのもとで学び成長する機会を得られたことに深く感謝しています。

GSoCが新しいスキルを習得し、複雑な概念に取り組み、視野を広げるためのプラットフォームとなったことを強調します。この学習体験は没頭的で変革的でした。オープンソースコミュニティの一員になることは驚きでした。志を同じくする人々と交流し、共有目標に貢献し、協力の真髄を経験することはハイライトとなりました。

私のGSoCの旅は探求、発見、成長の素晴らしい冒険であり、CC Legal Toolsプロジェクトのミッションである機械可読層を作成するという目標は開発者としての私の旅に不可欠な印を残しました。この冒険に皆さんと一緒に参加できたことに感謝します。オープンソースへの貢献とそれが持つ無限の可能性へ乾杯しましょう。

Saurabh Kumar]]></description>
            <content:encoded><![CDATA[こんにちは、読者の皆様！🌟 Google Summer of Code (GSoC) 2023の一環として、興奮を抑えられないプロジェクト「CC Legal Tools: Machine-Readable Layer」に貢献する素晴らしい機会を得ました。この旅は学び、コーディング、そしてコラボレーションの組み合わせで、皆さんとそのハイライトをお伝えするのが楽しみです。

プロジェクト概要：
このプロジェクトの核心的な焦点は、Creative Commons (CC) Legal Toolsアプリに強力な機械可読層を導入することでした。機械可読層はコンピュータがCCライセンスの詳細を理解できるようにし、法的専門家、開発者、そして愛好家のためのプログラム可能なCCライセンス作業を容易にします。

始まり：
私の旅は既存のコードベースへの没頭とプロジェクト要件の理解から始まりました。つまり、アプリのアーキテクチャ、そのコンポーネント、そして現在どのようにCCライセンスを処理しているかを理解することは、これから何が待っているのかにとって不可欠でした。RDF（リソース記述フレームワーク）はプロジェクトで重要な役割を果たしました。RDFの複雑さとライセンス表現におけるその役割を理解することは、この旅での必要なステップでした。

課題と学びの機会：
私の早期の挑戦の一つは、レガシーファイルであるRDF/XMLファイルの複雑性を解き明かすことにありました。それらが私たちが生成しようとしている新しいRDF/XMLファイルとはどのように異なるのでしょうか？この探求を通じて、構造の改善、ライセンス情報の更新、追加のメタデータを見つける機会がありました。さまざまなライセンスとバージョンに対してRDFファイルを生成することは、解き明かすパズルとなりました。RDFトリプルを作成し、ライセンシングのニュアンスを理解し、このロジックをアプリのビューに組み込むことは、学びの機会であり、報われた挑戦でした。

貢献と作業：
プロジェクトが進むにつれて、私は動的にRDF/XMLファイルを生成するための作業を行い、これによりアプリはオンデマンドで機械可読なライセンスを生成できるようになりました。整理されたアプローチを維持するために、生成されたRDFファイルがソートされることを確認しました。これはTimid Robotによるものです。新たに生成されたRDF/XMLは、Creative Commonsライセンスの表現における明確性、正確性、互換性、標準化を向上させることが目的です。これらの改善により、機械可読性とセマンティック理解が促進され、デジタルシステムでのシームレスな統合と解釈が可能になります。

変更の概要：
構造と一貫性の改善：新しいRDF/XMLはより組織化された標準化された構造を特徴としており、RDF標準に準拠しています。これにより、機械の理解と正確なデータ処理が向上します。
ライセンス情報の更新：ライセンス情報は最新の権限と制限を反映するように更新されています。これにより、ユーザーとシステムが正確に情報を得ることができます。
RDFベストプラクティスへの準拠：変更はRDFベストプラクティスとの準拠を強化します。標準化されたネームスペース、一貫した命名法、適切な関係定義のおかげで、相互運用性と互換性が向上します。

旅の過程で、私はメンターと共に密接に働き、協力的な議論を行い、洞察深いコードレビューを受けました。GSoCの旅が終わりを迎えようとしている今、CC Legal Toolsアプリの基礎を築いたことに興奮しています。機械可読層はスマートで自動化された法的手続きの未来を開く門となり、GSoCでの改善はCC Legal Toolsアプリ全体に波及し、ユーザーと広範なオープンソースコミュニティに恩恵をもたらします。

メンターとサポート：
この素晴らしい旅を通じて私を導いてくれたTimid Robotに心からの感謝を伝えます。あなたの不動の支援、知恵、フィードバック、知識共有への情熱は本当に価値がありました。あなたのもとで学び成長する機会を得られたことに深く感謝しています。

GSoCが新しいスキルを習得し、複雑な概念に取り組み、視野を広げるためのプラットフォームとなったことを強調します。この学習体験は没頭的で変革的でした。オープンソースコミュニティの一員になることは驚きでした。志を同じくする人々と交流し、共有目標に貢献し、協力の真髄を経験することはハイライトとなりました。

私のGSoCの旅は探求、発見、成長の素晴らしい冒険であり、CC Legal Toolsプロジェクトのミッションである機械可読層を作成するという目標は開発者としての私の旅に不可欠な印を残しました。この冒険に皆さんと一緒に参加できたことに感謝します。オープンソースへの貢献とそれが持つ無限の可能性へ乾杯しましょう。

Saurabh Kumar]]></content:encoded>
            <author>['saurabh']</author>
        </item>
        <item>
            <title><![CDATA[私のプロフェッショナルな人生の新しい章]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2023-06-16-new-chapter-of-my-professional-life/</link>
            <guid isPermaLink="false">urn:uuid:5c9435ea-4249-39be-8631-a8beb37f9607</guid>
            <pubDate>Tue, 20 Jun 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは、読者の皆さん！インドハイデラバード出身のシャフィア・ヒーナです。現在はカナダの活気あるトロント市に身を置いているところです。DevOpsエンジニアとして6年間過ごした後、最近私は非営利団体であるCreative Commonsで新たな職業生活を始めました。今日は、この2つの組織間の文化的な違いについての経験と感想をお伝えし、最近参加したInTown Week（ITW）というイベントとの出会いについても触れたいと思います。

Creative Commonsに加わる前は、オープンソースイニシアチブや非営利団体への関与が限られていました。しかし、Creative Commonsに入社してみると、その独特な文化に引き込まれました。協力の重視、透明性、スタッフ間での責任感の醸成など、組織のコミットメントはオープンソースとその理念を支えています。

ITWというイベントについても耳にしていたものの、その重要性についてはあまり知らされていませんでした。しかし、この1週間の集まりは私にとって啓発的で変革的な経験となりました。5日間にわたる自己探求とチームメンバーとの深い交流を通じて、Creative Commonsという組織についてもより深く理解することができました。

ITWでは、スタッフ間での知識や平等感が特に印象に残りました。誰もが自分の意見を発表し、それが既存の決定と矛盾してもよいという環境は、包摂性と集団的な成長を促進しています。また、私の性格特性やチーム内での貢献方法について洞察を与える発見テストにも参加しました。

情報の嵐にたびたび翻弄されましたが、幸いなことに優秀なメンターがいて、私を適切な道へと導き、周囲の出来事の詳細を理解する手助けをしてくれました。このメンターシップを通じて、エネルギーを高め、チームにさらに貢献できるようになる方法を見つけました。

ITWは豊かな経験でしたが、ビザの問題により現地参加できなかったため、週を通して延々と続くオンライン会議が大変でした。しかし、全員からの積極的な参加があったことで、その価値を十分に感じることができました。特に感動的だったのは、最後に全員が並んでスクリーン上で私一人ひとりに別れの言葉を告げてくれた瞬間です。

Creative Commonsでの経験では、CEOの活気と親しみやすさにも驚きました。以前の組織では、CEOとのコミュニケーションは主に変更や決定に関する公式メールに限られていましたが、ここではCEOの温かみと従業員との個人的な関わりを大切にする姿勢が印象的でした。

オープンソース文化について一言で表現すると、「魅力的」となります。特に私のメンターは、期待と目標を明確に示す3ヶ月間のオンボーディング文書を作成し、透明性を確保する役割を果たしました。ここではインフラが小さくても、ワークフローは効率化され、ウェブサイトへのアクセスを制限したりハードウェアセキュリティを優先するITチームはありません。

代わりにCreative Commonsでは、従業員が自分のハードウェアの所有権を持つ文化があり、信頼と自己主導性を育む環境となっています。]]></description>
            <content:encoded><![CDATA[こんにちは、読者の皆さん！インドハイデラバード出身のシャフィア・ヒーナです。現在はカナダの活気あるトロント市に身を置いているところです。DevOpsエンジニアとして6年間過ごした後、最近私は非営利団体であるCreative Commonsで新たな職業生活を始めました。今日は、この2つの組織間の文化的な違いについての経験と感想をお伝えし、最近参加したInTown Week（ITW）というイベントとの出会いについても触れたいと思います。

Creative Commonsに加わる前は、オープンソースイニシアチブや非営利団体への関与が限られていました。しかし、Creative Commonsに入社してみると、その独特な文化に引き込まれました。協力の重視、透明性、スタッフ間での責任感の醸成など、組織のコミットメントはオープンソースとその理念を支えています。

ITWというイベントについても耳にしていたものの、その重要性についてはあまり知らされていませんでした。しかし、この1週間の集まりは私にとって啓発的で変革的な経験となりました。5日間にわたる自己探求とチームメンバーとの深い交流を通じて、Creative Commonsという組織についてもより深く理解することができました。

ITWでは、スタッフ間での知識や平等感が特に印象に残りました。誰もが自分の意見を発表し、それが既存の決定と矛盾してもよいという環境は、包摂性と集団的な成長を促進しています。また、私の性格特性やチーム内での貢献方法について洞察を与える発見テストにも参加しました。

情報の嵐にたびたび翻弄されましたが、幸いなことに優秀なメンターがいて、私を適切な道へと導き、周囲の出来事の詳細を理解する手助けをしてくれました。このメンターシップを通じて、エネルギーを高め、チームにさらに貢献できるようになる方法を見つけました。

ITWは豊かな経験でしたが、ビザの問題により現地参加できなかったため、週を通して延々と続くオンライン会議が大変でした。しかし、全員からの積極的な参加があったことで、その価値を十分に感じることができました。特に感動的だったのは、最後に全員が並んでスクリーン上で私一人ひとりに別れの言葉を告げてくれた瞬間です。

Creative Commonsでの経験では、CEOの活気と親しみやすさにも驚きました。以前の組織では、CEOとのコミュニケーションは主に変更や決定に関する公式メールに限られていましたが、ここではCEOの温かみと従業員との個人的な関わりを大切にする姿勢が印象的でした。

オープンソース文化について一言で表現すると、「魅力的」となります。特に私のメンターは、期待と目標を明確に示す3ヶ月間のオンボーディング文書を作成し、透明性を確保する役割を果たしました。ここではインフラが小さくても、ワークフローは効率化され、ウェブサイトへのアクセスを制限したりハードウェアセキュリティを優先するITチームはありません。

代わりにCreative Commonsでは、従業員が自分のハードウェアの所有権を持つ文化があり、信頼と自己主導性を育む環境となっています。]]></content:encoded>
            <author>['shafiya']</author>
        </item>
        <item>
            <title><![CDATA[多くのモナリザ？芸術的データの量化と評価]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2023-04-26-umsi-how-many-mona-lisas/</link>
            <guid isPermaLink="false">urn:uuid:3239bad8-c9da-3fd2-ba08-00e63dad99de</guid>
            <pubDate>Wed, 26 Apr 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[クレジット共有（CC）は、ライセンスされた作品が10億件を超える。しかし、これらの作品を中央で管理する組織やデータがないため、作品の数を正確に把握したり、どのライセンスが有用であるかまたは廃止すべきかを分析することが難しい。このプロジェクトの目標は、CCスタッフが冗長なライセンスを特定し、その影響力を定量的なデータを使ってマーケティングする手助けをするものだ。特にオープン教育リソース（OER）に焦点を当てている。

データ収集では、CCのプラットフォームであるOER Commonsからデジタル教育リソースを集めた。このプロセスは、各ライセンスが使用されている数と種類を特定し、APIを用いてライセンスごとに最大50件ずつ作品を取得するという形で行われた。

収集したデータの解析では、言語分布やライセンスタイプ別のアイテム分布、OER Commons APIへの追加日時などを調査した。これにより、分析をより詳細に進めることができた。

視覚化では、主要ユーザー別とライセンスタイプ別のアイテム分布（図6）、科目別のライセンス分布（図9）、教育レベル別の素材種類の分布（図10）などを示した。

これらの洞察はCCのマーケティング活動に役立つ。また、長期的な保存に向けてCCがコラボレーターのコンテンツをデータベースシステムに統合する方向性も明確になった。

今後のステップとしては、Pythonライブラリを使用してデータベースクエリーを容易にするなど、プロジェクトの継続的な発展を目指す。]]></description>
            <content:encoded><![CDATA[クレジット共有（CC）は、ライセンスされた作品が10億件を超える。しかし、これらの作品を中央で管理する組織やデータがないため、作品の数を正確に把握したり、どのライセンスが有用であるかまたは廃止すべきかを分析することが難しい。このプロジェクトの目標は、CCスタッフが冗長なライセンスを特定し、その影響力を定量的なデータを使ってマーケティングする手助けをするものだ。特にオープン教育リソース（OER）に焦点を当てている。

データ収集では、CCのプラットフォームであるOER Commonsからデジタル教育リソースを集めた。このプロセスは、各ライセンスが使用されている数と種類を特定し、APIを用いてライセンスごとに最大50件ずつ作品を取得するという形で行われた。

収集したデータの解析では、言語分布やライセンスタイプ別のアイテム分布、OER Commons APIへの追加日時などを調査した。これにより、分析をより詳細に進めることができた。

視覚化では、主要ユーザー別とライセンスタイプ別のアイテム分布（図6）、科目別のライセンス分布（図9）、教育レベル別の素材種類の分布（図10）などを示した。

これらの洞察はCCのマーケティング活動に役立つ。また、長期的な保存に向けてCCがコラボレーターのコンテンツをデータベースシステムに統合する方向性も明確になった。

今後のステップとしては、Pythonライブラリを使用してデータベースクエリーを容易にするなど、プロジェクトの継続的な発展を目指す。]]></content:encoded>
            <author>['grace_coleman', 'anthony_ho', 'tyler_phillips', 'claire_wan']</author>
        </item>
        <item>
            <title><![CDATA[Creative Commonsにおけるコミュニティの貢献について]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2023-03-24-community-contributions/</link>
            <guid isPermaLink="false">urn:uuid:3b841b4a-e07a-36e0-8a2b-eeca42fd2ba5</guid>
            <pubDate>Fri, 24 Mar 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[異なるオープンソースコミュニティはそれぞれ独自の働き方をしており、そのため各人がCreative Commonsのプロジェクトに参加する際には個々の期待を持ってくることがあります。ある人はプルリクエストを直接提出することを期待し、別の人はイシューを提出してすぐに関連するプルリクエストを作成することがあります。Creative Commonsでは、考慮やコミュニティの参加、議論を通じて協力的で文書化がよく行き届き、情報に基づいた作業を行うためのプロセスを希望しています。

通常は新しい機能、ドキュメンテーションの新規または改訂版、もしくは遭遇したエラーなどのアイデアから始まります。そのアイデアやエラーはGitHubイシューとして詳細が記述されます。これは実装前の要旨と考えてください。

既存のすべてのイシュー（クローズされたものも含む）を確認し、重複するイシューがないか調べることが重要です。重複がある場合は、新たな情報を追加するコメントをそのイシューに記載するのが最良です。

エラーは検証され、再現可能な場合があります。スクリーンショットや再現手順、ビデオ、環境詳細などは他の人がエラーを確認する際に非常に役立ちます。

これらの情報は関連リポジトリに簡潔かつ詳細なイシューとして記載されます。この文書化されたイシュー自体も重要な貢献であり、解決または実装を行う人々にとってガイドとドキュメンテーションを提供します。

機能や特徴の提案はより複雑になることがあります。エラーはコードベースの期待値や機能に対する逸脱ですが、新規または変更された機能や特徴は全体的な計画に大きな影響を与えます。現在の状態と導入しようとする将来の状態を考慮する必要があります。

コミュニケーションと説明が最も重要であり、詳細な記述、ワイヤーフレーム、モックアップ、提案を支持する証拠は成功のために不可欠です。

エラーの場合とは異なり、新規機能や特徴の導入には予期しない副作用があり、コードベースの複数部分が変更または修正される可能性があります。これらの大規模な考慮事項はイシュー内で対処する必要があります。

機能イシューは通常、適切に文書化するためにより長い時間がかかることが予想されます。

ドキュメンテーションの改善も重要な貢献であり、コードコメントやプロジェクトREADME.md、関連ドキュメントなど常に向上させる余地があります。これらは技術的には「機能イシュー」となりますが、エラー修正やコードベースレベルの機能追加と同様に重要です。

提出されたイシューは寄稿ガイドラインに従って「トリージ待ち」ステータスになります。これはコアコードベース貢献者のレビューを待っている状態であり、この間は実装作業を行わない（プルリクエストを作成しない）ことが重要です。

コア貢献者はイシューの詳細が適切に記述されているか確認し、その目的がコードベース全体のパターンや目標と一致しているか評価します。提案された機能がプロジェクトの目標と合致しない場合でもそれは問題ではなく、コミュニティにとって重要な文書となります。

イシューは進展するか否かに関わらず貢献であり、適切に記述されている限りです。

イシューが実装可能であると判断されると「作業待ち」ステータスになります。この時点でプルリクエストを提出し、貢献者がその問題に対処することができます。

プロセスを通じてさまざまな種類の貢献があります。例えば：
イシュー自体は貢献です
コミュニティからのコメントでイシューが改善されるたびにそれは貢献となります
エラー発生理由を他人が理解する手助けをするコメントも貢献です
関連する他のイシューを見つけ、それが関連しているとリンクするのも貢献です。
これらの貢献はプルリクエストの開始前に行われます。

イシューが「作業待ち」ステータスになると興味を示した人が割り当てられ、フォークしてブランチを作成し、最終的にプルリクエストを提出します。このプロセスはさらに多くの貢献を伴うことがあります。

プルリクエストがレビューを通じて承認されるとコードベースにマージされ、関連イシューが完了としてクローズされます。これによりエラー修正や機能がプロジェクトに完全に実装されます。

ここまでのプロセスは異なるコミュニティメンバーからの複数の貢献によって成り立っています。これがオープンソースの力です！]]></description>
            <content:encoded><![CDATA[異なるオープンソースコミュニティはそれぞれ独自の働き方をしており、そのため各人がCreative Commonsのプロジェクトに参加する際には個々の期待を持ってくることがあります。ある人はプルリクエストを直接提出することを期待し、別の人はイシューを提出してすぐに関連するプルリクエストを作成することがあります。Creative Commonsでは、考慮やコミュニティの参加、議論を通じて協力的で文書化がよく行き届き、情報に基づいた作業を行うためのプロセスを希望しています。

通常は新しい機能、ドキュメンテーションの新規または改訂版、もしくは遭遇したエラーなどのアイデアから始まります。そのアイデアやエラーはGitHubイシューとして詳細が記述されます。これは実装前の要旨と考えてください。

既存のすべてのイシュー（クローズされたものも含む）を確認し、重複するイシューがないか調べることが重要です。重複がある場合は、新たな情報を追加するコメントをそのイシューに記載するのが最良です。

エラーは検証され、再現可能な場合があります。スクリーンショットや再現手順、ビデオ、環境詳細などは他の人がエラーを確認する際に非常に役立ちます。

これらの情報は関連リポジトリに簡潔かつ詳細なイシューとして記載されます。この文書化されたイシュー自体も重要な貢献であり、解決または実装を行う人々にとってガイドとドキュメンテーションを提供します。

機能や特徴の提案はより複雑になることがあります。エラーはコードベースの期待値や機能に対する逸脱ですが、新規または変更された機能や特徴は全体的な計画に大きな影響を与えます。現在の状態と導入しようとする将来の状態を考慮する必要があります。

コミュニケーションと説明が最も重要であり、詳細な記述、ワイヤーフレーム、モックアップ、提案を支持する証拠は成功のために不可欠です。

エラーの場合とは異なり、新規機能や特徴の導入には予期しない副作用があり、コードベースの複数部分が変更または修正される可能性があります。これらの大規模な考慮事項はイシュー内で対処する必要があります。

機能イシューは通常、適切に文書化するためにより長い時間がかかることが予想されます。

ドキュメンテーションの改善も重要な貢献であり、コードコメントやプロジェクトREADME.md、関連ドキュメントなど常に向上させる余地があります。これらは技術的には「機能イシュー」となりますが、エラー修正やコードベースレベルの機能追加と同様に重要です。

提出されたイシューは寄稿ガイドラインに従って「トリージ待ち」ステータスになります。これはコアコードベース貢献者のレビューを待っている状態であり、この間は実装作業を行わない（プルリクエストを作成しない）ことが重要です。

コア貢献者はイシューの詳細が適切に記述されているか確認し、その目的がコードベース全体のパターンや目標と一致しているか評価します。提案された機能がプロジェクトの目標と合致しない場合でもそれは問題ではなく、コミュニティにとって重要な文書となります。

イシューは進展するか否かに関わらず貢献であり、適切に記述されている限りです。

イシューが実装可能であると判断されると「作業待ち」ステータスになります。この時点でプルリクエストを提出し、貢献者がその問題に対処することができます。

プロセスを通じてさまざまな種類の貢献があります。例えば：
イシュー自体は貢献です
コミュニティからのコメントでイシューが改善されるたびにそれは貢献となります
エラー発生理由を他人が理解する手助けをするコメントも貢献です
関連する他のイシューを見つけ、それが関連しているとリンクするのも貢献です。
これらの貢献はプルリクエストの開始前に行われます。

イシューが「作業待ち」ステータスになると興味を示した人が割り当てられ、フォークしてブランチを作成し、最終的にプルリクエストを提出します。このプロセスはさらに多くの貢献を伴うことがあります。

プルリクエストがレビューを通じて承認されるとコードベースにマージされ、関連イシューが完了としてクローズされます。これによりエラー修正や機能がプロジェクトに完全に実装されます。

ここまでのプロセスは異なるコミュニティメンバーからの複数の貢献によって成り立っています。これがオープンソースの力です！]]></content:encoded>
            <author>['sara']</author>
        </item>
        <item>
            <title><![CDATA[Outreachyインターンシップの中間進捗報告]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2023-02-01-outreachy-mid-point/</link>
            <guid isPermaLink="false">urn:uuid:5a72ea28-c9b9-3a83-9064-35601dbc63e8</guid>
            <pubDate>Wed, 01 Feb 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[Creative Commonsでのインターンシップ - CC Meta Searchの再設計 - 中間進捗報告
Creative Commonsでインターンとして、私の元々のプロジェクトスケジュールは、古いCC検索サイトを意味論的で現代的なHTMLとCSSを使用するようにリファクタリングすることでした。このプロジェクトは、ユーザー体験を改善し、より広い層の人々にウェブサイトを利用できるようにすることを目指していました。古いCC Meta SearchウェブサイトはPHPとJavaScriptで構築されています。
私のインターンシップの主な目標は、PHPを意味論的なHTMLと現代的なCSSに変換しつつ、必要なすべての機能が維持されることです。
インターンシップの最初の半分ではいくつかの目標を達成しました。現在までに、ウェブサイトのHTMLを意味論的要素を使用するようにリファクタリングし、ウェブサイトのアクセシビリティとユーザーによるコンテンツ理解を向上させました。これには新しいindex.htmlファイルを作成して意味論的なHTMLでサイトを再構築しました。
また、現代的なCSS技術を実装して、ウェブサイトの視覚的デザインを改善し、さまざまなデバイスでのレスポンシブ性も向上させました。これらは現在、メンターからのフィードバックを得るためにレビューされています。
しかし、いくつかのプロジェクト目標が予想よりも長くかかりました。その主な理由の一つは、ウェブサイトのコードベースが整理されておらず、ナビゲートや理解するのが難しかったことです。また、新しいサイトを構築する際に従うか組み込むべき既存のCSSファイルがありましたが、これが非常に複雑で、多くのスタイルが期待通りの結果を出しませんでした。
この問題を理解しナビゲートするために時間を費やしましたが、最終的にはメンターに相談し、自分でCSSスタイルを作成することを提案しました。これにより、CC Vocabulary CSSファイルを組み込むという元々の目標は修正されました。
また、他のタスクよりも優先順位をつけ、計画を必要に応じて調整する必要がありました。現在までに書いた新しいCSSは既にウェブサイトのレイアウトをレスポンシブにしています。また、新しいscript.jsファイルを作成し、ウェブサイトの必要な機能について作業を開始しました。
メンターからのフィードバックに基づいて改善を行い、残りの問題をデバッグする計画です。さらに、必要に応じて最適化技術を実装して、ウェブサイト全体のパフォーマンスを向上させる予定です。
最終的には、すべてのユーザーにとって完全に機能的でユーザーフレンドリーなウェブサイトを目指します。]]></description>
            <content:encoded><![CDATA[Creative Commonsでのインターンシップ - CC Meta Searchの再設計 - 中間進捗報告
Creative Commonsでインターンとして、私の元々のプロジェクトスケジュールは、古いCC検索サイトを意味論的で現代的なHTMLとCSSを使用するようにリファクタリングすることでした。このプロジェクトは、ユーザー体験を改善し、より広い層の人々にウェブサイトを利用できるようにすることを目指していました。古いCC Meta SearchウェブサイトはPHPとJavaScriptで構築されています。
私のインターンシップの主な目標は、PHPを意味論的なHTMLと現代的なCSSに変換しつつ、必要なすべての機能が維持されることです。
インターンシップの最初の半分ではいくつかの目標を達成しました。現在までに、ウェブサイトのHTMLを意味論的要素を使用するようにリファクタリングし、ウェブサイトのアクセシビリティとユーザーによるコンテンツ理解を向上させました。これには新しいindex.htmlファイルを作成して意味論的なHTMLでサイトを再構築しました。
また、現代的なCSS技術を実装して、ウェブサイトの視覚的デザインを改善し、さまざまなデバイスでのレスポンシブ性も向上させました。これらは現在、メンターからのフィードバックを得るためにレビューされています。
しかし、いくつかのプロジェクト目標が予想よりも長くかかりました。その主な理由の一つは、ウェブサイトのコードベースが整理されておらず、ナビゲートや理解するのが難しかったことです。また、新しいサイトを構築する際に従うか組み込むべき既存のCSSファイルがありましたが、これが非常に複雑で、多くのスタイルが期待通りの結果を出しませんでした。
この問題を理解しナビゲートするために時間を費やしましたが、最終的にはメンターに相談し、自分でCSSスタイルを作成することを提案しました。これにより、CC Vocabulary CSSファイルを組み込むという元々の目標は修正されました。
また、他のタスクよりも優先順位をつけ、計画を必要に応じて調整する必要がありました。現在までに書いた新しいCSSは既にウェブサイトのレイアウトをレスポンシブにしています。また、新しいscript.jsファイルを作成し、ウェブサイトの必要な機能について作業を開始しました。
メンターからのフィードバックに基づいて改善を行い、残りの問題をデバッグする計画です。さらに、必要に応じて最適化技術を実装して、ウェブサイト全体のパフォーマンスを向上させる予定です。
最終的には、すべてのユーザーにとって完全に機能的でユーザーフレンドリーなウェブサイトを目指します。]]></content:encoded>
            <author>['precious']</author>
        </item>
        <item>
            <title><![CDATA[Outreachyでの最初のインターンシップを獲得するまでの経緯]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2023-01-04-how-i-landed-my-first-internship/</link>
            <guid isPermaLink="false">urn:uuid:5e40a203-7f1e-3406-b46e-156b060ce85b</guid>
            <pubDate>Wed, 04 Jan 2023 00:00:00 GMT</pubDate>
            <description><![CDATA[上記の言葉に共感してみてください。これは私が常に人生で守っている原則です。「怖がらずにやってみる」

自己紹介をさせていただきます。私の名前はPrecious Oritsedere、ナイジェリア人です。私は技術に対する強い好奇心を持ち、ソフトウェアエンジニアとして知られています。仕事への献身と強固な価値観で知られています。

愛、貢献、共感の力に信頼を置いており、これらは私の個人的および職業的な生活におけるガイドとなっています。

子供の頃から私は技術、ガジェット、ゲームに興味がありました。しかし、大学では技術関連のコースを学びませんでした。国際関係と外交で学位を取得しましたが、これは私がテクノロジーに対する好奇心を止めることはありませんでした。

2022年1月、友人からAltSchool Africaについて話題になり、これが私のテックキャリアの始まりとなりました。その後、フロントエンドエンジニアリングについて学び始め、オープンソースにも触れました。

Outreachyに応募した理由：

ソフトウェアエンジニアとして、私は自分のスキルを使って世界にポジティブな影響を与えることにコミットしています。協力とチームワークの力を信じており、同僚を助けることを常に喜んでいます。これがオープンソースの概念が私の性格に合っている理由です。

コミュニティへの貢献をしたいという欲求が私を動かします。違いをつくることに情熱を持ち、それがOutreachyインターンシップに応募した理由です。

Outreachyはオープンソースとオープンサイエンスで支給されたインターンシップを提供するプログラムです。技術業界で体系的な偏見や表現不足を受けている人々に対してインターンシップを提供します。インターンは3ヶ月間、7,000ドルの手当が支給されます。

Outreachyの応募プロセスは3つの段階からなります：初期申請、貢献期間、最終申請です。私は各ステージで成功し、ついにインターンシップを獲得することを目指しました。

最初のステージでは、要求事項を慎重に確認して全てを満たすように努めました。3つのエッセイを書くことが求められ、それらは私が技術業界で表現不足だったことについてでした。私はそれを深く考え、エッセイを書き上げて期限内に提出しました。

数週間後、Outreachyのオーガナイザーから次のステージである貢献期間に進むことが通知されました。このステージではオープンソースプロジェクトへの貢献が求められます。私はCreative Commonsの「Refactor CC Meta Search」プロジェクトを選択しました。

このプロジェクトに対する高品質な貢献を心から望み、新しいツールや技術を学びました。また、他のOutreachy申請者たちに手助けをしたり、プロジェクトメンターからの指導を求めたりもしました。

私の努力は報われ、期限内に貢献を提出することができました。最終ステージではCreative Commonsとのインターンシップのための最終申請を行いました。数週間後、インターンシップが選ばれたと通知を受けました。

Outreachyの応募プロセスでの成功は私の献身と努力によるものです。要求事項を満たすために時間を費やし、プロジェクトに価値ある貢献を行いました。

私の情熱と忍耐が報われて貴重なインターンシップの機会を得ることができました。

結論として、Precious Oritsedereは愛、貢献、共感という価値観に基づいて仕事に取り組む才能あるソフトウェアエンジニアです。情熱とコミットメントが彼女の職業生活とOutreachyインターンシップへの参加から明らかになっています。]]></description>
            <content:encoded><![CDATA[上記の言葉に共感してみてください。これは私が常に人生で守っている原則です。「怖がらずにやってみる」

自己紹介をさせていただきます。私の名前はPrecious Oritsedere、ナイジェリア人です。私は技術に対する強い好奇心を持ち、ソフトウェアエンジニアとして知られています。仕事への献身と強固な価値観で知られています。

愛、貢献、共感の力に信頼を置いており、これらは私の個人的および職業的な生活におけるガイドとなっています。

子供の頃から私は技術、ガジェット、ゲームに興味がありました。しかし、大学では技術関連のコースを学びませんでした。国際関係と外交で学位を取得しましたが、これは私がテクノロジーに対する好奇心を止めることはありませんでした。

2022年1月、友人からAltSchool Africaについて話題になり、これが私のテックキャリアの始まりとなりました。その後、フロントエンドエンジニアリングについて学び始め、オープンソースにも触れました。

Outreachyに応募した理由：

ソフトウェアエンジニアとして、私は自分のスキルを使って世界にポジティブな影響を与えることにコミットしています。協力とチームワークの力を信じており、同僚を助けることを常に喜んでいます。これがオープンソースの概念が私の性格に合っている理由です。

コミュニティへの貢献をしたいという欲求が私を動かします。違いをつくることに情熱を持ち、それがOutreachyインターンシップに応募した理由です。

Outreachyはオープンソースとオープンサイエンスで支給されたインターンシップを提供するプログラムです。技術業界で体系的な偏見や表現不足を受けている人々に対してインターンシップを提供します。インターンは3ヶ月間、7,000ドルの手当が支給されます。

Outreachyの応募プロセスは3つの段階からなります：初期申請、貢献期間、最終申請です。私は各ステージで成功し、ついにインターンシップを獲得することを目指しました。

最初のステージでは、要求事項を慎重に確認して全てを満たすように努めました。3つのエッセイを書くことが求められ、それらは私が技術業界で表現不足だったことについてでした。私はそれを深く考え、エッセイを書き上げて期限内に提出しました。

数週間後、Outreachyのオーガナイザーから次のステージである貢献期間に進むことが通知されました。このステージではオープンソースプロジェクトへの貢献が求められます。私はCreative Commonsの「Refactor CC Meta Search」プロジェクトを選択しました。

このプロジェクトに対する高品質な貢献を心から望み、新しいツールや技術を学びました。また、他のOutreachy申請者たちに手助けをしたり、プロジェクトメンターからの指導を求めたりもしました。

私の努力は報われ、期限内に貢献を提出することができました。最終ステージではCreative Commonsとのインターンシップのための最終申請を行いました。数週間後、インターンシップが選ばれたと通知を受けました。

Outreachyの応募プロセスでの成功は私の献身と努力によるものです。要求事項を満たすために時間を費やし、プロジェクトに価値ある貢献を行いました。

私の情熱と忍耐が報われて貴重なインターンシップの機会を得ることができました。

結論として、Precious Oritsedereは愛、貢献、共感という価値観に基づいて仕事に取り組む才能あるソフトウェアエンジニアです。情熱とコミットメントが彼女の職業生活とOutreachyインターンシップへの参加から明らかになっています。]]></content:encoded>
            <author>['precious']</author>
        </item>
        <item>
            <title><![CDATA[オープンな環境で働くことについてより開かれた考え方を持つ]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2022-12-16-new-to-working-in-open/</link>
            <guid isPermaLink="false">urn:uuid:65123e14-a63f-300e-890b-de6fa0ceef60</guid>
            <pubDate>Fri, 16 Dec 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[今年、Creative Commons (CC) のフルスタックエンジニアとして働き始め、CCでのオープンな環境での仕事は素晴らしい経験だと思っています。しかし、長年閉じた内部ソースの環境で働いてきた私にとって、これは間違いなく学びのプロセスであり、視点の変革でもありました。数年にわたり、オープンソースの世界から恩恵を受け、その中で個人的な仕事も提供してきましたが、他のプロジェクトに深く関わることはできず、職場での日々の仕事をオープンソースの世界に戻すこともできませんでした（それにもかかわらず、毎日の仕事にはオープンソースが大きな役割を果たしていました）。これは私の希望であり、私が提唱したことでありましたが、結局は実現しませんでした。しかし今、CCでようやくオープンなプロジェクトに参加し、世界中の貢献者コミュニティの一員になることができました。それはリフレッシュと報酬を感じさせる一方で、啓発的でもあります。多くのことが変わっています。オープンな環境での仕事は、コードのライセンス条件を変えるだけでなく、アプローチやプロセスにも大きな変化をもたらします。たとえば、オープンな環境ではコミュニティメンバーが貢献したいと思っていても、プロジェクトに詳しい人ほど長い時間をかけて蓄積する文脈的理解が欠けていることがあります。そのため、新しい貢献者に対して理解しやすい情報提供を行うためには、ドキュメンテーションを優先した戦略が必要です。また、問題の詳細な情報を記録することは、将来的に自分自身やコミュニティの貢献者がその問題を理解し解決する上で極めて価値があります。セットアップ手順、コードベースに関する文脈ドキュメンテーション、既知の問題、ロードマップなど、すべてがドキュメント化され記録される必要があります。これはコミュニティの貢献者だけでなく、プロジェクト全体にとっても有益です。重要な情報は、それを支えるコードと共にオープンな場所に存在するべきです。これはまさにウィンウィンの状況と言えます。プロセス自体も変更が必要で、単に取り組みたいタスクリストを作成して作業を始めるだけでは足りません。各アイテムが個々の人々によって小さな部分と反復的なプルリクエストとしてスムーズに採用されるように考慮する必要があります。この状況での仕事の分割や範囲設定に対する配慮は、内部チームの場合よりも重要です。オープンな環境での開発は単なるコードの公開だけでなく、計画も公開することを意味し、プロジェクトが目指す全体的なロードマップと目標についてより明確な視点を持つことが求められます。コードベースの管理者としてタスクリストを作成したり問題を特定したとしても、それはあなた一人のためにあるわけではありません。単独で作業している場合でも、そのアイテムに取り組む時間を見つける必要があります。オープンソースの文脈では、貢献者コミュニティと協力する中で、課題を作成することはコードを書くことと同じくらい重要であり、多くの場合、実際にはそれ以上に重要です。なぜなら、課題は貢献者が最初に手助けや洞察を提供する方法であり、プロジェクトとの最初の接触点だからです。さらに、あなた以外の人々が完成させる可能性があるため、作成した課題はリストで放置されるわけではありません。これはコードベースでの仕事の計画と分解について考える方法における小さながらくだが重要な変化と言えます。それは確かに新しい経験ですが、非常に報酬を感じさせます。一日中プルリクエストを提出したり重大なバグを修正できなくても、より良いドキュメンテーションを作成し、誰かの質問に答えたり、プロセスを見直したり、他の人の献身的な貢献をレビューすることで、コミュニティやコードベースに対して有意義な貢献を感じることができます。オープンソースとは、貢献の定義を広げることであり、それは私が思っていたよりもはるかに広範で意味深いものです。]]></description>
            <content:encoded><![CDATA[今年、Creative Commons (CC) のフルスタックエンジニアとして働き始め、CCでのオープンな環境での仕事は素晴らしい経験だと思っています。しかし、長年閉じた内部ソースの環境で働いてきた私にとって、これは間違いなく学びのプロセスであり、視点の変革でもありました。数年にわたり、オープンソースの世界から恩恵を受け、その中で個人的な仕事も提供してきましたが、他のプロジェクトに深く関わることはできず、職場での日々の仕事をオープンソースの世界に戻すこともできませんでした（それにもかかわらず、毎日の仕事にはオープンソースが大きな役割を果たしていました）。これは私の希望であり、私が提唱したことでありましたが、結局は実現しませんでした。しかし今、CCでようやくオープンなプロジェクトに参加し、世界中の貢献者コミュニティの一員になることができました。それはリフレッシュと報酬を感じさせる一方で、啓発的でもあります。多くのことが変わっています。オープンな環境での仕事は、コードのライセンス条件を変えるだけでなく、アプローチやプロセスにも大きな変化をもたらします。たとえば、オープンな環境ではコミュニティメンバーが貢献したいと思っていても、プロジェクトに詳しい人ほど長い時間をかけて蓄積する文脈的理解が欠けていることがあります。そのため、新しい貢献者に対して理解しやすい情報提供を行うためには、ドキュメンテーションを優先した戦略が必要です。また、問題の詳細な情報を記録することは、将来的に自分自身やコミュニティの貢献者がその問題を理解し解決する上で極めて価値があります。セットアップ手順、コードベースに関する文脈ドキュメンテーション、既知の問題、ロードマップなど、すべてがドキュメント化され記録される必要があります。これはコミュニティの貢献者だけでなく、プロジェクト全体にとっても有益です。重要な情報は、それを支えるコードと共にオープンな場所に存在するべきです。これはまさにウィンウィンの状況と言えます。プロセス自体も変更が必要で、単に取り組みたいタスクリストを作成して作業を始めるだけでは足りません。各アイテムが個々の人々によって小さな部分と反復的なプルリクエストとしてスムーズに採用されるように考慮する必要があります。この状況での仕事の分割や範囲設定に対する配慮は、内部チームの場合よりも重要です。オープンな環境での開発は単なるコードの公開だけでなく、計画も公開することを意味し、プロジェクトが目指す全体的なロードマップと目標についてより明確な視点を持つことが求められます。コードベースの管理者としてタスクリストを作成したり問題を特定したとしても、それはあなた一人のためにあるわけではありません。単独で作業している場合でも、そのアイテムに取り組む時間を見つける必要があります。オープンソースの文脈では、貢献者コミュニティと協力する中で、課題を作成することはコードを書くことと同じくらい重要であり、多くの場合、実際にはそれ以上に重要です。なぜなら、課題は貢献者が最初に手助けや洞察を提供する方法であり、プロジェクトとの最初の接触点だからです。さらに、あなた以外の人々が完成させる可能性があるため、作成した課題はリストで放置されるわけではありません。これはコードベースでの仕事の計画と分解について考える方法における小さながらくだが重要な変化と言えます。それは確かに新しい経験ですが、非常に報酬を感じさせます。一日中プルリクエストを提出したり重大なバグを修正できなくても、より良いドキュメンテーションを作成し、誰かの質問に答えたり、プロセスを見直したり、他の人の献身的な貢献をレビューすることで、コミュニティやコードベースに対して有意義な貢献を感じることができます。オープンソースとは、貢献の定義を広げることであり、それは私が思っていたよりもはるかに広範で意味深いものです。]]></content:encoded>
            <author>['sara']</author>
        </item>
        <item>
            <title><![CDATA[データサイエンスの発見：共有財産の量化]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2022-12-07-berkeley-quantifying/</link>
            <guid isPermaLink="false">urn:uuid:96d2ba10-db41-319e-8ab9-e1385d2b0c4a</guid>
            <pubDate>Wed, 07 Dec 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[カリフォルニア大学バークレー校のデータサイエンスディスカバリープログラム、2022年秋期プロジェクトの目的と問題提起。過去数年間、2014年から2017年にかけて、クリエイティブコモンズ（CC）は、CCの成長、規模、利用状況を詳細に記した公開レポートを発表し、CCの重要性と影響力を示していました。しかし、その努力はその後の年で停止しました。これが現在のオープンソースプロジェクト「共有財産の量化」の前身です。

2017年の以前の報告書からの視覚化の一例：

以前の取り組みがデータ取得方法に頼りすぎており、ウェブサイトアーキテクチャの更新により機能不全を起こす可能性があったため、これらのデータ抽出手法は現在の手法と比較して性能面で非常に低い（1時間対5営業日）でした。

学生研究者は、過去の報告書で使用されたCCデータに対する信頼性のあるデータ取得プロセスを設計し、実装することで、CC製品状態の量化作業を継続する役割を与えられています。これにより、インターネット上のCC製品利用の規模と多様性を量ることができます。

データ抽出：

CCライセンス付きドキュメントの国をどのように検出しますか？オンラインドキュメントがCCツールを使用して保護されている場合、そのツールのライセンスとしてラベル付けされるか、またはライセンスのルール（デード）を説明するcreativecommons.orgウェブページへのハイパーリンクを含む可能性があります。したがって、以下のアプローチを使用してCCライセンス付きドキュメントを識別およびカウントできます：

提供されたCCツールのリストを選択します。
オンラインプラットフォームのAPIを使用して、プラットフォームによってライセンスとしてラベル付けされているか、またはCCライセンスウェブページへのハイパーリンクを含むドキュメントを検出し、カウントします。
これらのデータをテーブル形式で保存し、各タイプのCCツールによる保護を受けているドキュメント数を記録します。

プラットフォームからのカウント収集：

このプロジェクトにおけるプラットフォームのデータ収集、可視化、モデリングの委任の一覧です：

ウェブページを含むプラットフォーム：Google（Dun-Ming Huang）、DeviantArt（Dun-Ming Huang）
写真を含むプラットフォーム：Flickr（Shuran Yang）
ビデオを含むプラットフォーム：Vimeo（Dun-Ming Huang）、YouTube（Dun-Ming Huang）

探査的データ分析（EDA）：

サンプルされたプラットフォームのデータセットで発見された重要な欠陥の一覧です。
Flickr：このデータセットからのサンプリングドキュメント数は、CC製品（ライセンス）ごとの公式統計と35,000％～100,000％の偏差があります。サンプリングフレームは各ライセンスで4,000件の検索可能な写真に固定されています。重大な重複問題（解決済み）。
Google Custom Search API：プログラム可能検索エンジンは、Googleのウェブサイトのサブセットのみを対象としています。影響は限定的です（その後、PSEでのサンプリングフレーム調整により解決）。過時化したオペレーターとパラメータを使用したことによる信頼性問題（解決済み）。
YouTube Data API：APIには、YouTubeビデオの総数に対する最大応答値があり、深刻な低評価を引き起こします。データにカスタム粒度を導入して正確な応答を可能にするため、視覚化における補完を導入し、開発コストを節約しました。

データセットの拡張：

データ収集プラットフォームでのデータセット拡張の理由と努力の一覧です。
Google Custom Search API：EDAで発見された不正確さを解決するためのデータサンプリングプロセスの修正。過去の境界を超えてCC製品利用分析の範囲を広げるために、視覚化はクロス製品パフォーマンス比較のみを行っていましたが、時間軸と地理的デモグラフィックにおけるCC製品利用データを追加しました。
YouTube Data API：EDAで発見された不正確さを解決するためのデータサンプリングプロセスの修正。メディア固有の時間経過によるCCオプションの開発に関する前例のない分析を行うために、2か月ごとの期間におけるYouTubeのCCライセンス付きビデオ数を追跡しました。

視覚化の哲学と原則：

「共有財産の量化」の視覚化はコミュニケーションと展示に焦点を当てています。新しい美学と原則として採用したものは以下の通りです（以前の努力の向上に対する応答）：長さを使用して可読性を向上させる、ライセンスごとの比較を超えて製品開発を分析する、Pandas、Seaborn、NumPy、Geopandas、SpaCyを使用してデータ傾向を表示するための色を使用する。

視覚化の一覧：

図1C：Googleで保護されたクリエイティブコモンズの使用トレンドチャート。現在、Googleがインデックスに登録しているクリエイティブコモンズで保護されているウェブページは27億を超えています！

図2：国ごとのCCライセンス付きGoogleインデックスウェブページの視覚化。

図3：Flickrからのデータ抽出方法とその結果についての詳細な説明。

モデルの生産：機械学習製品を超えて、製品利用に関する推論を行う可能性を期待しています。これらの努力は、「共有財産の量化」の長期的な再生への短いスタートアップです。

未来のチームに対する提案：現在のチームは、自動化とバッチデータ抽出方法を通じて、オープンソースデータ抽出メソッドの利用性とユーザーエクスペリエンスを向上させるよう将来のチームに奨励しています。また、モデルについては、Logistic Regressionモデル用のELI5を使用した推論パイプラインを作成することや、Gradient Boosting Classifierの損失関数オプションを試すことを提案しています。

追加リーディング：
Dun-Ming Huangのブログ記事一覧とShuran Yangのブログ記事が提供されています。]]></description>
            <content:encoded><![CDATA[カリフォルニア大学バークレー校のデータサイエンスディスカバリープログラム、2022年秋期プロジェクトの目的と問題提起。過去数年間、2014年から2017年にかけて、クリエイティブコモンズ（CC）は、CCの成長、規模、利用状況を詳細に記した公開レポートを発表し、CCの重要性と影響力を示していました。しかし、その努力はその後の年で停止しました。これが現在のオープンソースプロジェクト「共有財産の量化」の前身です。

2017年の以前の報告書からの視覚化の一例：

以前の取り組みがデータ取得方法に頼りすぎており、ウェブサイトアーキテクチャの更新により機能不全を起こす可能性があったため、これらのデータ抽出手法は現在の手法と比較して性能面で非常に低い（1時間対5営業日）でした。

学生研究者は、過去の報告書で使用されたCCデータに対する信頼性のあるデータ取得プロセスを設計し、実装することで、CC製品状態の量化作業を継続する役割を与えられています。これにより、インターネット上のCC製品利用の規模と多様性を量ることができます。

データ抽出：

CCライセンス付きドキュメントの国をどのように検出しますか？オンラインドキュメントがCCツールを使用して保護されている場合、そのツールのライセンスとしてラベル付けされるか、またはライセンスのルール（デード）を説明するcreativecommons.orgウェブページへのハイパーリンクを含む可能性があります。したがって、以下のアプローチを使用してCCライセンス付きドキュメントを識別およびカウントできます：

提供されたCCツールのリストを選択します。
オンラインプラットフォームのAPIを使用して、プラットフォームによってライセンスとしてラベル付けされているか、またはCCライセンスウェブページへのハイパーリンクを含むドキュメントを検出し、カウントします。
これらのデータをテーブル形式で保存し、各タイプのCCツールによる保護を受けているドキュメント数を記録します。

プラットフォームからのカウント収集：

このプロジェクトにおけるプラットフォームのデータ収集、可視化、モデリングの委任の一覧です：

ウェブページを含むプラットフォーム：Google（Dun-Ming Huang）、DeviantArt（Dun-Ming Huang）
写真を含むプラットフォーム：Flickr（Shuran Yang）
ビデオを含むプラットフォーム：Vimeo（Dun-Ming Huang）、YouTube（Dun-Ming Huang）

探査的データ分析（EDA）：

サンプルされたプラットフォームのデータセットで発見された重要な欠陥の一覧です。
Flickr：このデータセットからのサンプリングドキュメント数は、CC製品（ライセンス）ごとの公式統計と35,000％～100,000％の偏差があります。サンプリングフレームは各ライセンスで4,000件の検索可能な写真に固定されています。重大な重複問題（解決済み）。
Google Custom Search API：プログラム可能検索エンジンは、Googleのウェブサイトのサブセットのみを対象としています。影響は限定的です（その後、PSEでのサンプリングフレーム調整により解決）。過時化したオペレーターとパラメータを使用したことによる信頼性問題（解決済み）。
YouTube Data API：APIには、YouTubeビデオの総数に対する最大応答値があり、深刻な低評価を引き起こします。データにカスタム粒度を導入して正確な応答を可能にするため、視覚化における補完を導入し、開発コストを節約しました。

データセットの拡張：

データ収集プラットフォームでのデータセット拡張の理由と努力の一覧です。
Google Custom Search API：EDAで発見された不正確さを解決するためのデータサンプリングプロセスの修正。過去の境界を超えてCC製品利用分析の範囲を広げるために、視覚化はクロス製品パフォーマンス比較のみを行っていましたが、時間軸と地理的デモグラフィックにおけるCC製品利用データを追加しました。
YouTube Data API：EDAで発見された不正確さを解決するためのデータサンプリングプロセスの修正。メディア固有の時間経過によるCCオプションの開発に関する前例のない分析を行うために、2か月ごとの期間におけるYouTubeのCCライセンス付きビデオ数を追跡しました。

視覚化の哲学と原則：

「共有財産の量化」の視覚化はコミュニケーションと展示に焦点を当てています。新しい美学と原則として採用したものは以下の通りです（以前の努力の向上に対する応答）：長さを使用して可読性を向上させる、ライセンスごとの比較を超えて製品開発を分析する、Pandas、Seaborn、NumPy、Geopandas、SpaCyを使用してデータ傾向を表示するための色を使用する。

視覚化の一覧：

図1C：Googleで保護されたクリエイティブコモンズの使用トレンドチャート。現在、Googleがインデックスに登録しているクリエイティブコモンズで保護されているウェブページは27億を超えています！

図2：国ごとのCCライセンス付きGoogleインデックスウェブページの視覚化。

図3：Flickrからのデータ抽出方法とその結果についての詳細な説明。

モデルの生産：機械学習製品を超えて、製品利用に関する推論を行う可能性を期待しています。これらの努力は、「共有財産の量化」の長期的な再生への短いスタートアップです。

未来のチームに対する提案：現在のチームは、自動化とバッチデータ抽出方法を通じて、オープンソースデータ抽出メソッドの利用性とユーザーエクスペリエンスを向上させるよう将来のチームに奨励しています。また、モデルについては、Logistic Regressionモデル用のELI5を使用した推論パイプラインを作成することや、Gradient Boosting Classifierの損失関数オプションを試すことを提案しています。

追加リーディング：
Dun-Ming Huangのブログ記事一覧とShuran Yangのブログ記事が提供されています。]]></content:encoded>
            <author>['Dun-MingHuang', 'ShuranYang']</author>
        </item>
        <item>
            <title><![CDATA[CalVer to SemVer]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2022-11-11-calver-to-semver/</link>
            <guid isPermaLink="false">urn:uuid:77f93cff-41ad-3d49-978e-b02fce3099fa</guid>
            <pubDate>Fri, 11 Nov 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[クリエイティブ コモンズ（CC）は、CalVer（カレンダーバージョニング）を使用しようとしましたが、多くの問題に直面し、SemVer（セマンティックバージョニング）に切り替えることを決定しました。なぜCalVerを選んだのか 数年前、CCの技術チームは、バージョン管理スキームとしてCalVerを標準化しました。具体的には、YYYY.0M.MICROを選択しました。 CalVer: YYYY - 全年齢 - 2006, 2016, 2106 0M - パディングされた月 - 01, 02 ... 11, 12 Micro - バージョンの3番目で通常最終的な数字。時々「パッチ」セグメントと呼ばれます。 CalVerの使用は、Ubuntu、pip、SaltStackなどからインスピレーションを得ました。 CalVerがユーザーに潜在的なリスクを伝える点でSemVerと同じであるだけでなく、追加の時間的コンテキストも提供すると考えられました。また、多くの人々は、SemVerのMAJOR.MINOR.PATCHの約束がしばしば果たされないため、意味を失い、MINOR/PATCHの違いが不明確であると主張しています（後で詳しく説明します）。 CalVerで遭遇した問題 時間/期間は主要な関心事ではない CalVerは、時間/期間が主要な関心事であるプロジェクトにしばしば好まれます（例：サポートウィンドウが限定されているUbuntuリリース）。しかし、CCのどのプロジェクトも時間/期間を主要な関心事としていません。 MAJORの期待と遅いイテレーション SemVerは長年の慣習を形式化しています。多くのユーザー、特に開発者は、バージョニングスキームの最初の数字が変更の深刻度を示すことを期待します。YYYYが現在のリリース年を示している場合、YYYY.0M.MICROのバージョン管理スキームは、変更内容が軽微であっても重大な変更や改善（例：2021.09.1から2022.02.1）があると期待させる可能性があります。YYYYが元々のリリース年を示している場合、ゆっくりとした進展だが安定していて機能的なリリースは放置されているか、または脆弱であると思われることがあります（例：2019.03.2が2022年に）。 CalVerに対するサポート不足 また、ソフトウェアやシステムでCalVerのサポートが不十分であることもありました。例えば、NPMは現在、リーディングゼロを削除し、CDN統合を壊します（CalVerとCDN互換性 · Issue #588 · creativecommons/vocabulary）。 SemVerを使用する CalVerの実験は科学的方法にとって成功です。今日、SemVerがCCソフトウェアの開発者やユーザーに対してCalVerよりも良い対応を提供することに自信を持てます。 SemVerの約束 承諾 CC技術チームは、SemVerをCCオープンソースソフトウェアのユーザーと開発者に対する私たちの約束セットとして見ています。私たちはその約束を完全に果たすことはないかもしれませんが、それらが期待を示しており、誤りがあれば問題を開くことを望みます。 CC SemVerの詳細 今後はSemVer（セマンティックバージョニング）を使用します。明確さを追加するために、機能変更とバグ修正をリリースに混在させないようにします： MAJORバージョンで互換性のないAPI変更を行う場合 MINORバージョンで後方互換性のある方法で機能を追加する場合 MINORバージョンを増やすリリースには、バグ修正は含まれてはなりません PATCHバージョンで後方互換性のあるバグ修正を行う場合 PATCHバージョンを増やすリリースには、機能追加は含まれてはなりません バグ修正が技術的に機能変更となる場合、私たちは機能変更（PATCHバージョンのみをインクリメント）としてバグ修正をリリースし、その変更が意図された機能を維持することを確認します。]]></description>
            <content:encoded><![CDATA[クリエイティブ コモンズ（CC）は、CalVer（カレンダーバージョニング）を使用しようとしましたが、多くの問題に直面し、SemVer（セマンティックバージョニング）に切り替えることを決定しました。なぜCalVerを選んだのか 数年前、CCの技術チームは、バージョン管理スキームとしてCalVerを標準化しました。具体的には、YYYY.0M.MICROを選択しました。 CalVer: YYYY - 全年齢 - 2006, 2016, 2106 0M - パディングされた月 - 01, 02 ... 11, 12 Micro - バージョンの3番目で通常最終的な数字。時々「パッチ」セグメントと呼ばれます。 CalVerの使用は、Ubuntu、pip、SaltStackなどからインスピレーションを得ました。 CalVerがユーザーに潜在的なリスクを伝える点でSemVerと同じであるだけでなく、追加の時間的コンテキストも提供すると考えられました。また、多くの人々は、SemVerのMAJOR.MINOR.PATCHの約束がしばしば果たされないため、意味を失い、MINOR/PATCHの違いが不明確であると主張しています（後で詳しく説明します）。 CalVerで遭遇した問題 時間/期間は主要な関心事ではない CalVerは、時間/期間が主要な関心事であるプロジェクトにしばしば好まれます（例：サポートウィンドウが限定されているUbuntuリリース）。しかし、CCのどのプロジェクトも時間/期間を主要な関心事としていません。 MAJORの期待と遅いイテレーション SemVerは長年の慣習を形式化しています。多くのユーザー、特に開発者は、バージョニングスキームの最初の数字が変更の深刻度を示すことを期待します。YYYYが現在のリリース年を示している場合、YYYY.0M.MICROのバージョン管理スキームは、変更内容が軽微であっても重大な変更や改善（例：2021.09.1から2022.02.1）があると期待させる可能性があります。YYYYが元々のリリース年を示している場合、ゆっくりとした進展だが安定していて機能的なリリースは放置されているか、または脆弱であると思われることがあります（例：2019.03.2が2022年に）。 CalVerに対するサポート不足 また、ソフトウェアやシステムでCalVerのサポートが不十分であることもありました。例えば、NPMは現在、リーディングゼロを削除し、CDN統合を壊します（CalVerとCDN互換性 · Issue #588 · creativecommons/vocabulary）。 SemVerを使用する CalVerの実験は科学的方法にとって成功です。今日、SemVerがCCソフトウェアの開発者やユーザーに対してCalVerよりも良い対応を提供することに自信を持てます。 SemVerの約束 承諾 CC技術チームは、SemVerをCCオープンソースソフトウェアのユーザーと開発者に対する私たちの約束セットとして見ています。私たちはその約束を完全に果たすことはないかもしれませんが、それらが期待を示しており、誤りがあれば問題を開くことを望みます。 CC SemVerの詳細 今後はSemVer（セマンティックバージョニング）を使用します。明確さを追加するために、機能変更とバグ修正をリリースに混在させないようにします： MAJORバージョンで互換性のないAPI変更を行う場合 MINORバージョンで後方互換性のある方法で機能を追加する場合 MINORバージョンを増やすリリースには、バグ修正は含まれてはなりません PATCHバージョンで後方互換性のあるバグ修正を行う場合 PATCHバージョンを増やすリリースには、機能追加は含まれてはなりません バグ修正が技術的に機能変更となる場合、私たちは機能変更（PATCHバージョンのみをインクリメント）としてバグ修正をリリースし、その変更が意図された機能を維持することを確認します。]]></content:encoded>
            <author>['TimidRobot']</author>
        </item>
        <item>
            <title><![CDATA[CC Global Components Libraryの構築]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/building-the-cc-global-components-library/</link>
            <guid isPermaLink="false">urn:uuid:66c3e40a-0e23-35b4-ad3b-aa3943c91242</guid>
            <pubDate>Thu, 17 Mar 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[導入 Outreachyインターンシップ中にCreative Commonsでいくつかのクールなプロジェクトに取り組み、その一つがmentorのBrylie Christopher Oxleyによって監督されたCC Global Componentsライブラリでした。異なるCCウェブサイト間で統一したデザインテーマや経験を持つことは、これらのウェブサイトを開発する際の重要な要素です。このことを念頭に置いて、多くのCCウェブプロパティが共有しているいくつかのコンポーネントがあります。特に以下の3つのコンポーネントがあります：- グローバルナビゲーションメニュー：creativecommons.orgのサブパス（例：/licenses）で表示される - グローバルフッター：多くのCreative Commonsプロパティで表示される - Explore CCコンポーネント：Global SummitなどのすべてのCCウェブプロパティで表示される 各プロジェクトがこれらのコンポーネントを実装することによるコードの重複やメンテナンス上の問題を避けるため、これらのコンポーネント用の別々のライブラリを持つことが望ましいと判断し、最終的にCC Global Componentsプロジェクトが始まりました。 技術選定 グローバルコンポーネントライブラリの目標は、CDN経由で配信可能なカスタムウェブコンポーネントを構築することでした。計画段階では、使用する技術を選択する必要がありました。一般的に、ReactやVueなどの多くのWebフレームワークを使用できますが、シンプルな実装と少ない依存関係を望んでいました。探していた技術の理想的な特性は以下の通りです： Web標準に基づく HTML、CSS、JavaScript（構造、美観、機能）の明確な分離 軽量/小さなバンドルサイズ 松結合（緊密または無関係な依存関係がない） 主に考慮した2つの主要技術はVue JSとLightning Web Componentsでしたが、既存のプロジェクト（Chooserプロジェクトなど）でVueを使用しているため、最終的にVue JSを選択しました。 コンポーネントの構築 プロジェクトをスクラッチから始めるために、Vue SFC rollupというCLIテンプレートユーティリティを使用し、複数のVue SFC（Single File Components）ライブラリをコンパイルするための最小限のセットアップを設定しました。これにより、テンプレートに集中して作成できました。 コンポーネントには、私たち独自のCCデザインパッケージであるVocabulary CSSを使用してスタイル付けを行いました。 1) CC Global Footer CC Global Footerコンポーネントは、主に静的なHTMLであるため最も簡単でした。このコンポーネントは2つの属性を取ります：logo-url：使用するウェブサイトのロゴを指すURL donation-url：寄付ボタン用のURL CDNスクリプトをインポートすると、以下のコードで任意のページでCC Global Footerを使用できます： そして以下のようにレンダリングされます。 2) CC Explore CC Exploreコンポーネントは、すべてのCC Webプロパティへのリンクが含まれる展開可能なバナーです。このコンポーネントにはクリックリスナーがあり、クリックされたときに展開可能バナーを表示または非表示にします。CC Global Footerコンポーネントと同様に、CC Exploreコンポーネントも2つの属性を取ります： そして以下のようにレンダリングされます。 3) CC Global Header CC Global Headerは重要なコンポーネントでした。ダウンストリームプロジェクト（ライセンスやツールなど）のメニュー項目を表示するためにはAPI呼び出しが必要です。Axiosライブラリを使用して、親プロジェクトProjec_creativecommons.orgのWordpressバックエンドに対してAPI呼び出しを行いました。CC Global Headerは3つの必須属性を取ります：base-url、donation-url、logo-url（それぞれAPI呼び出し用、寄付ボタン用、ロゴ用のURL）。追加でuse-menu-placeholdersという属性を設定すると、開発環境ではプレースホルダーメニュー項目が表示されます。ただし、ステージング/プロダクションセットアップではこの属性を使用しません： そして以下のようにレンダリングされます。 結論 このライブラリの最初のバージョン（0.1.1）は2021年12月10日にNPMに公開されました。現在までにコードに対する多くの変更と最適化があり、現在ではバージョン0.5.0です。これは初めてVue JSを使用した経騯で非常に豊かな体験でした。また、Timid Robotによる追加のコードレビューと最適化も行われました。すべての3つのコンポーネントが使用されたCC Global Componentsは以下のように表示されます： CC Global Componentsプロジェクトについては以下の場所で見つけることができます： GitHub: CC Global Components NPM: cc-global-components]]></description>
            <content:encoded><![CDATA[導入 Outreachyインターンシップ中にCreative Commonsでいくつかのクールなプロジェクトに取り組み、その一つがmentorのBrylie Christopher Oxleyによって監督されたCC Global Componentsライブラリでした。異なるCCウェブサイト間で統一したデザインテーマや経験を持つことは、これらのウェブサイトを開発する際の重要な要素です。このことを念頭に置いて、多くのCCウェブプロパティが共有しているいくつかのコンポーネントがあります。特に以下の3つのコンポーネントがあります：- グローバルナビゲーションメニュー：creativecommons.orgのサブパス（例：/licenses）で表示される - グローバルフッター：多くのCreative Commonsプロパティで表示される - Explore CCコンポーネント：Global SummitなどのすべてのCCウェブプロパティで表示される 各プロジェクトがこれらのコンポーネントを実装することによるコードの重複やメンテナンス上の問題を避けるため、これらのコンポーネント用の別々のライブラリを持つことが望ましいと判断し、最終的にCC Global Componentsプロジェクトが始まりました。 技術選定 グローバルコンポーネントライブラリの目標は、CDN経由で配信可能なカスタムウェブコンポーネントを構築することでした。計画段階では、使用する技術を選択する必要がありました。一般的に、ReactやVueなどの多くのWebフレームワークを使用できますが、シンプルな実装と少ない依存関係を望んでいました。探していた技術の理想的な特性は以下の通りです： Web標準に基づく HTML、CSS、JavaScript（構造、美観、機能）の明確な分離 軽量/小さなバンドルサイズ 松結合（緊密または無関係な依存関係がない） 主に考慮した2つの主要技術はVue JSとLightning Web Componentsでしたが、既存のプロジェクト（Chooserプロジェクトなど）でVueを使用しているため、最終的にVue JSを選択しました。 コンポーネントの構築 プロジェクトをスクラッチから始めるために、Vue SFC rollupというCLIテンプレートユーティリティを使用し、複数のVue SFC（Single File Components）ライブラリをコンパイルするための最小限のセットアップを設定しました。これにより、テンプレートに集中して作成できました。 コンポーネントには、私たち独自のCCデザインパッケージであるVocabulary CSSを使用してスタイル付けを行いました。 1) CC Global Footer CC Global Footerコンポーネントは、主に静的なHTMLであるため最も簡単でした。このコンポーネントは2つの属性を取ります：logo-url：使用するウェブサイトのロゴを指すURL donation-url：寄付ボタン用のURL CDNスクリプトをインポートすると、以下のコードで任意のページでCC Global Footerを使用できます： そして以下のようにレンダリングされます。 2) CC Explore CC Exploreコンポーネントは、すべてのCC Webプロパティへのリンクが含まれる展開可能なバナーです。このコンポーネントにはクリックリスナーがあり、クリックされたときに展開可能バナーを表示または非表示にします。CC Global Footerコンポーネントと同様に、CC Exploreコンポーネントも2つの属性を取ります： そして以下のようにレンダリングされます。 3) CC Global Header CC Global Headerは重要なコンポーネントでした。ダウンストリームプロジェクト（ライセンスやツールなど）のメニュー項目を表示するためにはAPI呼び出しが必要です。Axiosライブラリを使用して、親プロジェクトProjec_creativecommons.orgのWordpressバックエンドに対してAPI呼び出しを行いました。CC Global Headerは3つの必須属性を取ります：base-url、donation-url、logo-url（それぞれAPI呼び出し用、寄付ボタン用、ロゴ用のURL）。追加でuse-menu-placeholdersという属性を設定すると、開発環境ではプレースホルダーメニュー項目が表示されます。ただし、ステージング/プロダクションセットアップではこの属性を使用しません： そして以下のようにレンダリングされます。 結論 このライブラリの最初のバージョン（0.1.1）は2021年12月10日にNPMに公開されました。現在までにコードに対する多くの変更と最適化があり、現在ではバージョン0.5.0です。これは初めてVue JSを使用した経騯で非常に豊かな体験でした。また、Timid Robotによる追加のコードレビューと最適化も行われました。すべての3つのコンポーネントが使用されたCC Global Componentsは以下のように表示されます： CC Global Componentsプロジェクトについては以下の場所で見つけることができます： GitHub: CC Global Components NPM: cc-global-components]]></content:encoded>
            <author>['MuluhGodson']</author>
        </item>
        <item>
            <title><![CDATA[2022年第1四半期CCメッセージング更新（IRC廃止）]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2022-01-06-cc-messaging/</link>
            <guid isPermaLink="false">urn:uuid:3dff9668-8e79-342b-aa35-028ff2541416</guid>
            <pubDate>Thu, 06 Jan 2022 00:00:00 GMT</pubDate>
            <description><![CDATA[過去：Slackへの移行（2016年、クリエイティブコモンズ(CC)は主要なメッセージングプラットフォームとしてSlackに移行しました。Slackの優れたサポートに感謝します。SlackはIRCよりも遥かにアクセスしやすく、メッセージングコミュニティが即座かつ持続的に増加しました。現在、Slackワークスペースには10,293人のメンバーがおり、その中で平均して約250人がほぼ70のパブリックチャンネルで毎日活動しています）。しかし、Slackにも有効な批判がありますが、それらは以下の「オープンソース」セクションで扱われます。現在：IRC廃止（CCがSlackに移行した際、Freenode上の3つのIRCチャンネルとブリッジを設置しましたが、これらのチャンネルには年間数人のアクティブユーザーと数十のメッセージしかありません）。2021年のFreenodeの敵対的買収後、フリーソフトウェア/オープンソース(FOSS)コミュニティは主にlibera.chatに移行しましたが、Slack/IRCブリッジをその場所には移行しません。2022年1月24日から、公式にサポートされるメッセージングプラットフォームとしてIRCを廃止します。また、IRCではアクティブユーザーもほとんどいませんし、多くのアクティブなIRCユーザーはSlackアカウントも持っています。IRCの廃止により、技術リソースをコミュニティ全体のためにより効果的に割り当てることができます。未来：オープンソース（数年間、SlackにはパフォーマンスとUXの問題がありました。また、大規模なオープンコミュニティに適合しない設計上の前提もあります）。しかし、これらの問題はSlackが強力で機能的なメッセージングプラットフォームであり続けることを妨げていません。ただし、オープンソースのメッセージングプラットフォームはクリエイティブコモンズコミュニティと私たちが掲げる価値観によりよく適合します。オープンソースとオープンコンテンツのコミュニティは長年にわたり大きな重複と協力を楽しんでいます。メッセージングに関しては、来年か再来年の間にその重複を増やしたいと考えています）。]]></description>
            <content:encoded><![CDATA[過去：Slackへの移行（2016年、クリエイティブコモンズ(CC)は主要なメッセージングプラットフォームとしてSlackに移行しました。Slackの優れたサポートに感謝します。SlackはIRCよりも遥かにアクセスしやすく、メッセージングコミュニティが即座かつ持続的に増加しました。現在、Slackワークスペースには10,293人のメンバーがおり、その中で平均して約250人がほぼ70のパブリックチャンネルで毎日活動しています）。しかし、Slackにも有効な批判がありますが、それらは以下の「オープンソース」セクションで扱われます。現在：IRC廃止（CCがSlackに移行した際、Freenode上の3つのIRCチャンネルとブリッジを設置しましたが、これらのチャンネルには年間数人のアクティブユーザーと数十のメッセージしかありません）。2021年のFreenodeの敵対的買収後、フリーソフトウェア/オープンソース(FOSS)コミュニティは主にlibera.chatに移行しましたが、Slack/IRCブリッジをその場所には移行しません。2022年1月24日から、公式にサポートされるメッセージングプラットフォームとしてIRCを廃止します。また、IRCではアクティブユーザーもほとんどいませんし、多くのアクティブなIRCユーザーはSlackアカウントも持っています。IRCの廃止により、技術リソースをコミュニティ全体のためにより効果的に割り当てることができます。未来：オープンソース（数年間、SlackにはパフォーマンスとUXの問題がありました。また、大規模なオープンコミュニティに適合しない設計上の前提もあります）。しかし、これらの問題はSlackが強力で機能的なメッセージングプラットフォームであり続けることを妨げていません。ただし、オープンソースのメッセージングプラットフォームはクリエイティブコモンズコミュニティと私たちが掲げる価値観によりよく適合します。オープンソースとオープンコンテンツのコミュニティは長年にわたり大きな重複と協力を楽しんでいます。メッセージングに関しては、来年か再来年の間にその重複を増やしたいと考えています）。]]></content:encoded>
            <author>['TimidRobot']</author>
        </item>
        <item>
            <title><![CDATA[CC オープンソースコミュニティにおける近未来的な変更]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/2020-12-07-upcoming-changes-to-community/</link>
            <guid isPermaLink="false">urn:uuid:6ddb1b15-743c-33df-8908-af1a328988d8</guid>
            <pubDate>Mon, 07 Dec 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[クリエイティブコモンズ（CC）は、2021年に新たな組織戦略を採用し、創立20周年に合わせて組織の進化を図ります。この新しい戦略に基づき、アーデン・ページ、ブレント・モラン、フーゴ・ソラール、そして私（クリティ・ゴデイ）は12月末までにクリエイティブコモンズを去ることになります。今後、CC スタッフエンジニアリングチームのティミッド・ロボット・ゼハータとザック・クリダは、より少ない核となるプロジェクトへのサポートに焦点を当てます。過去2年間で築き上げたクリエイティブコモンズの活気あるオープンソースコミュニティに対する私たちの貢献には非常に誇りを感じています。また、すべてのコミュニティメンバーからの素晴らしい貢献にも感謝しています。既存ツールへの重要な改善を行い、新たなプロジェクトを立ち上げました。Vocabularyというクリエイティブコモンズ用のデザインシステムを作成し、そのシステムを使用して6つのサイトを開設しました。CC Searchに数十の新しいソースを追加し、アクセシビリティも向上させました。また、CCライセンスと広く使用されているソフトウェアとの統合を目指したツール（例：CC WordPressプラグインやCC Searchブラウザ拡張）もリリースしました。その他にも多くの成果があります。
コミュニティ変更
CC オープンソースコミュニティは、私たちのエンジニアリング作業において依然として中心的な役割を果たしますが、新たなスタッフ能力に基づき、コミュニティプロセスにいくつかの変更を加えます：コミュニティチームメンバーにはクリエイティブコモンズのAsanaへのアクセス権がなくなります。タスクの大半はGitHubで追跡されており、Asanaの管理はコミュニティチームにとって不要な複雑さをもたらします。すべてのコミュニティチームメンバーに会議やドキュメントへの参加を招待します（役職に関係なく）。"community-team-core" メーリングリストを "community-team" メーリングリストに置き換えます。月次のオープンソースコミュニティミーティングを開催し、既存の2週間に1回のエンジニアリングミーティングは終了します。有給のオープンソースコミュニティコーディネーターを設けなくなり、新規メンバーへの支援やTwitterアカウントの維持などはボランティアに頼ることになります。新たなコミュニティチームメンバーを迎え入れ、Google Summer of Codeなどのインターンシッププログラムにも引き続き参加します。
プロジェクト変更
より小さなエンジニアリングチームでは、サポートするプロジェクトを減らさなければなりません。以下に、少なくとも1人のコミュニティチームメンバーがいるすべてのプロジェクトの現在の状況をご覧ください。
アクティブ開発中
以下のプロジェクトは引き続き積極的に開発されます：
CC Search ブラウザ拡張（メンテナー：メイアンク・ナダー）
CC オープンソースウェブサイト（メンテナー：ザック・クリダ & ティミッド・ロボット・ゼハータ）
CC WordPressベースおよび子テーマ（新メンテナー：ザック・クリダ）
CC 法的データベース（メンテナー：ティミッド・ロボット・ゼハータ）
CC Chooser（メンテナー：ザック・クリダ）
CC リンクチェックツール（メンテナー：ティミッド・ロボット・ゼハータ）
ライセンスボタン（メンテナー：ティミッド・ロボット・ゼハータ）
プラットフォームツールキット（メンテナー：ティミッド・ロボット・ゼハータ）
Vocabulary（メンテナー：ザック・クリダ & ドルフ・バヌシャーリ）
WordPressプラグイン（新メンテナー：ザック・クリダ）
保守モード
以下のプロジェクトは保守モードに入ります。サービスはオンラインで継続しますが、2020年12月15日以降の新しいプルリクエストやコードデプロイは受け付けません。
CC カタログ
CC カタログAPI
CC Search Linked Commonsカタログ、API、Linked Commonsの貢献者は、CC Legal Databaseや新たなCC Licensesプロジェクトなどの他のPythonプロジェクトへの参加を奨励します。もしCC Searchの貢献者であれば、CC ChooserやVocabularyのようなフロントエンドプロジェクトに参加することをお勧めします。
お礼
私たちのコミュニティに対する感謝の言葉は尽きません。皆様と仕事をするのは絶大な喜びであり、今後も長年にわたって協力し続けることを楽しみにしています。]]></description>
            <content:encoded><![CDATA[クリエイティブコモンズ（CC）は、2021年に新たな組織戦略を採用し、創立20周年に合わせて組織の進化を図ります。この新しい戦略に基づき、アーデン・ページ、ブレント・モラン、フーゴ・ソラール、そして私（クリティ・ゴデイ）は12月末までにクリエイティブコモンズを去ることになります。今後、CC スタッフエンジニアリングチームのティミッド・ロボット・ゼハータとザック・クリダは、より少ない核となるプロジェクトへのサポートに焦点を当てます。過去2年間で築き上げたクリエイティブコモンズの活気あるオープンソースコミュニティに対する私たちの貢献には非常に誇りを感じています。また、すべてのコミュニティメンバーからの素晴らしい貢献にも感謝しています。既存ツールへの重要な改善を行い、新たなプロジェクトを立ち上げました。Vocabularyというクリエイティブコモンズ用のデザインシステムを作成し、そのシステムを使用して6つのサイトを開設しました。CC Searchに数十の新しいソースを追加し、アクセシビリティも向上させました。また、CCライセンスと広く使用されているソフトウェアとの統合を目指したツール（例：CC WordPressプラグインやCC Searchブラウザ拡張）もリリースしました。その他にも多くの成果があります。
コミュニティ変更
CC オープンソースコミュニティは、私たちのエンジニアリング作業において依然として中心的な役割を果たしますが、新たなスタッフ能力に基づき、コミュニティプロセスにいくつかの変更を加えます：コミュニティチームメンバーにはクリエイティブコモンズのAsanaへのアクセス権がなくなります。タスクの大半はGitHubで追跡されており、Asanaの管理はコミュニティチームにとって不要な複雑さをもたらします。すべてのコミュニティチームメンバーに会議やドキュメントへの参加を招待します（役職に関係なく）。"community-team-core" メーリングリストを "community-team" メーリングリストに置き換えます。月次のオープンソースコミュニティミーティングを開催し、既存の2週間に1回のエンジニアリングミーティングは終了します。有給のオープンソースコミュニティコーディネーターを設けなくなり、新規メンバーへの支援やTwitterアカウントの維持などはボランティアに頼ることになります。新たなコミュニティチームメンバーを迎え入れ、Google Summer of Codeなどのインターンシッププログラムにも引き続き参加します。
プロジェクト変更
より小さなエンジニアリングチームでは、サポートするプロジェクトを減らさなければなりません。以下に、少なくとも1人のコミュニティチームメンバーがいるすべてのプロジェクトの現在の状況をご覧ください。
アクティブ開発中
以下のプロジェクトは引き続き積極的に開発されます：
CC Search ブラウザ拡張（メンテナー：メイアンク・ナダー）
CC オープンソースウェブサイト（メンテナー：ザック・クリダ & ティミッド・ロボット・ゼハータ）
CC WordPressベースおよび子テーマ（新メンテナー：ザック・クリダ）
CC 法的データベース（メンテナー：ティミッド・ロボット・ゼハータ）
CC Chooser（メンテナー：ザック・クリダ）
CC リンクチェックツール（メンテナー：ティミッド・ロボット・ゼハータ）
ライセンスボタン（メンテナー：ティミッド・ロボット・ゼハータ）
プラットフォームツールキット（メンテナー：ティミッド・ロボット・ゼハータ）
Vocabulary（メンテナー：ザック・クリダ & ドルフ・バヌシャーリ）
WordPressプラグイン（新メンテナー：ザック・クリダ）
保守モード
以下のプロジェクトは保守モードに入ります。サービスはオンラインで継続しますが、2020年12月15日以降の新しいプルリクエストやコードデプロイは受け付けません。
CC カタログ
CC カタログAPI
CC Search Linked Commonsカタログ、API、Linked Commonsの貢献者は、CC Legal Databaseや新たなCC Licensesプロジェクトなどの他のPythonプロジェクトへの参加を奨励します。もしCC Searchの貢献者であれば、CC ChooserやVocabularyのようなフロントエンドプロジェクトに参加することをお勧めします。
お礼
私たちのコミュニティに対する感謝の言葉は尽きません。皆様と仕事をするのは絶大な喜びであり、今後も長年にわたって協力し続けることを楽しみにしています。]]></content:encoded>
            <author>['kgodey']</author>
        </item>
        <item>
            <title><![CDATA[語彙ランディングページおよび使用ガイド最終報告]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-vocabulary-docs-updates-closing/</link>
            <guid isPermaLink="false">urn:uuid:c9d85fac-5e9a-388a-ba75-1e84fee57c64</guid>
            <pubDate>Thu, 03 Dec 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[素晴らしい旅の終わりに到着しました。GSoDインターンシップ期間中のすべての貢献を総括しましょう！

語彙サイト更新（第4版/全4版）：承認後、必要なgithub招待を受け取りました。私はCC語彙コアコミッターとして語彙GitHubリポジトリへの書き込みアクセス権を与えられました。

提案された初期計画：プロジェクト概要：語彙は、ウェブサイト構築のための主要なUIコンポーネントライブラリとして使用される大きな可能性があります。必要なのは、開発者にとって堅牢でありながら初心者フレンドリーなハウツーガイドです。

重要な開発者情報（コンポーネントガイド、使用規格、設定調整など）は、どの文書にも不可欠な部分を形成します。これは、既存のユーザーが語彙がどのように成長し続けているかを感じるだけでなく、比較的新しいプロジェクトでの語彙の使用を促進することも目的としています。

インターンシップ中の私の役割で得られるべき成果は、既存のコンポーネントを使用するための実用的なガイドを書くことだけでなく、語彙、Vue-Vocabulary、フォントそれぞれのホームページ（統合されたドキュメンテーションにつながる）を設計および開発することも含まれます。

提案および改善されたタイムラインと成果物：以下は私が達成したすべての週間目標の一覧です。インターンシップ前：Creative Commonsという組織、その活動、関連する倫理について理解しました。CCのgithubリポジトリを確認し、コード構造を理解しました。

問題を開いたりプルリクエストを作成したりして、リポジトリワークフローに慣れました。メンターとプロジェクトに関する基本的なアイデアを確立しました。プロジェクトの必要性についてさらに調査し、実装後の潜在的影響を考えました。

週1（09/14 - 09/21）：語彙、Vue-Vocabulary、フォントをより深く理解し、既存のコンポーネントを確認しました。Figmaを使用してVocabulary、Vue-Vocabulary、Fonts用の統一されたランディングページのデザインを作成しました。

メンターと他のチームメンバーとのコミュニケーションを通じて信頼関係を築きました。

週2（09/22 - 09/28）：デザイン選択やページ構造に関する質問に対応し、CCのUXデザイナーからの承認を求めました。メインランディングページに必要なコンテンツの作成を開始しました。

週3（09/29 - 10/06）：ランディングサイトおよびドキュメンテーションに必要な見出し、サブヘッダー、セクションを最終化しました。ドキュメンテーションコンテンツを受け入れるためのコードを準備しました。github pages/netlify/surgeを継続的な統合とデプロイのために設定しました。

週4（10/07 - 10/14）：「導入」「開始」および「グリッドコンポーネント」サブヘッダーのドキュメンテーションに書き始めました。Vocabularyコンポーネントを使用してメインランディングページを開発を開始しました。

週5（10/15 - 10/22）：メインページコンテンツに対する完全な承認を得ました。「ダークテーマ」のコーディングを行いました。ハッカートフォス貢献者を支援し、CCOSイベントでスピーチを行いました。

週6（10/23 - 10/30）：インターンシップ中の進行状況と経験についてのブログ記事を書きました。Vocabularyのすべてのコンポーネントのドキュメンテーションガイドを作成し、必要に応じてリニューアルを行いました。

週7（10/31 - 11/07）：メインページコンテンツとランディングページを統合し、稼働させました。

週8（11/08 - 11/15）：語彙使用ガイドの作成が完了し、初期承認を求めました。

週9（11/16 - 11/23）：ガイドとメインページコンテンツを最終化しました。ランディングページからドキュメンテーションへの統合を行いました。視覚検証と調査用にsurgeを使用してサンプルビルドを公開しました。

週10（11/24 - 11/30）：WAVEおよびWebのAccessibility Insightsを使用してアクセシビリティに関する開発ビルドを調査。Chrome Dev Toolsを使用してサイトのレスポンシブネスを調査。Lighthouseレポートを作成しました。

検索エンジン最適化のためにメタタグと外部リンクを使用しました。

週11（11/30 - 12/05）：レポート統計を改善し、目標に達するまで作業を行いました。すべての活動と私のパフォーマンスについてのブログ記事を書きました。

週12（12/06 - 12/12）：最終的な承認を得るまで毎日の承認を求めました。自分の文章やコードに微細なエラーがないか何度も確認しました。

週13（12/13 - 12/19）：コードを整理し、lintingが適切に行われていることを確認しました。インターンシップの締めくくりとなるブログ記事を公開しました。最終的な承認を求めました。

インターンシップ後：CCライセンス付き作品の使用を促進します。メンターと他のチームメンバーとのコミュニケーションを通じて信頼関係を築きました。

語彙サイト：Figmaを使用してVocabulary、Vue-Vocabulary、Fonts用の統一されたランディングページのデザインを作成しました。

インターンシップ中の私の役割で得られるべき成果は、既存のコンポーネントを使用するための実用的なガイドを書くことだけでなく、語彙、Vue-Vocabulary、フォントそれぞれのホームページ（統合されたドキュメンテーションにつながる）を設計および開発することも含まれます。

インターンシップ後：CCライセンス付き作品の使用を促進します。]]></description>
            <content:encoded><![CDATA[素晴らしい旅の終わりに到着しました。GSoDインターンシップ期間中のすべての貢献を総括しましょう！

語彙サイト更新（第4版/全4版）：承認後、必要なgithub招待を受け取りました。私はCC語彙コアコミッターとして語彙GitHubリポジトリへの書き込みアクセス権を与えられました。

提案された初期計画：プロジェクト概要：語彙は、ウェブサイト構築のための主要なUIコンポーネントライブラリとして使用される大きな可能性があります。必要なのは、開発者にとって堅牢でありながら初心者フレンドリーなハウツーガイドです。

重要な開発者情報（コンポーネントガイド、使用規格、設定調整など）は、どの文書にも不可欠な部分を形成します。これは、既存のユーザーが語彙がどのように成長し続けているかを感じるだけでなく、比較的新しいプロジェクトでの語彙の使用を促進することも目的としています。

インターンシップ中の私の役割で得られるべき成果は、既存のコンポーネントを使用するための実用的なガイドを書くことだけでなく、語彙、Vue-Vocabulary、フォントそれぞれのホームページ（統合されたドキュメンテーションにつながる）を設計および開発することも含まれます。

提案および改善されたタイムラインと成果物：以下は私が達成したすべての週間目標の一覧です。インターンシップ前：Creative Commonsという組織、その活動、関連する倫理について理解しました。CCのgithubリポジトリを確認し、コード構造を理解しました。

問題を開いたりプルリクエストを作成したりして、リポジトリワークフローに慣れました。メンターとプロジェクトに関する基本的なアイデアを確立しました。プロジェクトの必要性についてさらに調査し、実装後の潜在的影響を考えました。

週1（09/14 - 09/21）：語彙、Vue-Vocabulary、フォントをより深く理解し、既存のコンポーネントを確認しました。Figmaを使用してVocabulary、Vue-Vocabulary、Fonts用の統一されたランディングページのデザインを作成しました。

メンターと他のチームメンバーとのコミュニケーションを通じて信頼関係を築きました。

週2（09/22 - 09/28）：デザイン選択やページ構造に関する質問に対応し、CCのUXデザイナーからの承認を求めました。メインランディングページに必要なコンテンツの作成を開始しました。

週3（09/29 - 10/06）：ランディングサイトおよびドキュメンテーションに必要な見出し、サブヘッダー、セクションを最終化しました。ドキュメンテーションコンテンツを受け入れるためのコードを準備しました。github pages/netlify/surgeを継続的な統合とデプロイのために設定しました。

週4（10/07 - 10/14）：「導入」「開始」および「グリッドコンポーネント」サブヘッダーのドキュメンテーションに書き始めました。Vocabularyコンポーネントを使用してメインランディングページを開発を開始しました。

週5（10/15 - 10/22）：メインページコンテンツに対する完全な承認を得ました。「ダークテーマ」のコーディングを行いました。ハッカートフォス貢献者を支援し、CCOSイベントでスピーチを行いました。

週6（10/23 - 10/30）：インターンシップ中の進行状況と経験についてのブログ記事を書きました。Vocabularyのすべてのコンポーネントのドキュメンテーションガイドを作成し、必要に応じてリニューアルを行いました。

週7（10/31 - 11/07）：メインページコンテンツとランディングページを統合し、稼働させました。

週8（11/08 - 11/15）：語彙使用ガイドの作成が完了し、初期承認を求めました。

週9（11/16 - 11/23）：ガイドとメインページコンテンツを最終化しました。ランディングページからドキュメンテーションへの統合を行いました。視覚検証と調査用にsurgeを使用してサンプルビルドを公開しました。

週10（11/24 - 11/30）：WAVEおよびWebのAccessibility Insightsを使用してアクセシビリティに関する開発ビルドを調査。Chrome Dev Toolsを使用してサイトのレスポンシブネスを調査。Lighthouseレポートを作成しました。

検索エンジン最適化のためにメタタグと外部リンクを使用しました。

週11（11/30 - 12/05）：レポート統計を改善し、目標に達するまで作業を行いました。すべての活動と私のパフォーマンスについてのブログ記事を書きました。

週12（12/06 - 12/12）：最終的な承認を得るまで毎日の承認を求めました。自分の文章やコードに微細なエラーがないか何度も確認しました。

週13（12/13 - 12/19）：コードを整理し、lintingが適切に行われていることを確認しました。インターンシップの締めくくりとなるブログ記事を公開しました。最終的な承認を求めました。

インターンシップ後：CCライセンス付き作品の使用を促進します。メンターと他のチームメンバーとのコミュニケーションを通じて信頼関係を築きました。

語彙サイト：Figmaを使用してVocabulary、Vue-Vocabulary、Fonts用の統一されたランディングページのデザインを作成しました。

インターンシップ中の私の役割で得られるべき成果は、既存のコンポーネントを使用するための実用的なガイドを書くことだけでなく、語彙、Vue-Vocabulary、フォントそれぞれのホームページ（統合されたドキュメンテーションにつながる）を設計および開発することも含まれます。

インターンシップ後：CCライセンス付き作品の使用を促進します。]]></content:encoded>
            <author>['nimishbongale']</author>
        </item>
        <item>
            <title><![CDATA[私のGSoD 2020の旅]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/summary-my-gsod-2020-journey/</link>
            <guid isPermaLink="false">urn:uuid:6a45214f-1da2-3be9-a913-89e5cf9ed69c</guid>
            <pubDate>Wed, 02 Dec 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[素晴らしい経験をありがとうございました、クリエイティブコモンズ！このブログ記事は、‘CCカタログAPI使用ガイド改善’プロジェクトのレポートとして機能します。私はGoogle Season of Docs (GSOD) 2020期間中にどのような作業を行ったかについて説明しています。このプロジェクトのメンターはクリエイティブコモンズのAlden PageとKriti Godeyです。ドキュメント開発フェーズでは合計12週間があります。2週ごとに、私は進捗状況をメンターや組織に更新するためのブログ記事を公開しています。

第1週：Google Season of Docsの最初の2週間が過ぎました。初週にはcurlコマンドを使用してクエリを行う例を追加しました。Forbiddenエラーで問題が発生したので、アクセスキーが期限切れだったことが分かりました。新しいアクセスキーを取得することで解決しました。

第2週：2週目にはレスポンスサンプルの作成を始めました。drf-yasg（Swaggerジェネレーター）を理解するのが難しかったため、大変でした。drf-yasgはDjango Rest Framework APIからSwagger / OpenAPI 2.0仕様を作成する自動的なSwaggerジェネレーターです。理解を深めるために可能な限り多くの例を探しました。面白いことに、drf-yasgがランダムな文字の組み合わせではなく、DRFがDjango Rest FrameworkでYASGがYet Another Swagger Generatorを意味することに気づくのに時間がかかりました。

第3週：第3週は非常に忙しかったです。第3週には故郷に戻りました。引っ越しと作業スペースの設置のために3日間休みました。月曜日と火曜日の2日間だけプロジェクトに取り組み、ほとんどのAPIエンドポイントに対するレスポンスサンプルを作成しました。この週はKritiとの月次のビデオ通話がありました。

第4週：これまでの作業と未完了のタスクをレビューし、新しい完成予定時間を推定しました。幸いにもGSoDタイムラインにはバッファーウィークがあり、納品物も間に合っています。よって、完成時間については問題ありません。APIエンドポイントに対する説明文を作成し、最初のプルリクエストを提出してブログ記事を公開しました。

第5週：多くの内容をドキュメントに追加しました。クラスへのヘルプテキストの追加方法やシリアライザの作成方法を見つけました。コード例をレスポンスサンプルの下に移動するために、x-code-samplesを追加するための新しいCustomAutoSchemaクラスを作成しました。他のタスクには「登録と認証」や「用語集」などの新セクションの作成が含まれます。

第6週：GitHubで貢献を開始するためのTodoリストを含む新たなセクション「Contribute」を追加しました。また、このブログ記事も書きました。

第7週：CCカタログAPIリポジトリのファイルREADMEを再構成しました。ローカルサーバーを起動する手順をステップバイステップで説明したガイドを追加しました。更新されたローカルサーバーの実行方法についてのガイドにより、新しいユーザーがこのプロジェクトに貢献することに対する恐怖心が和らぐことを願っています。

第8週：ドキュメンテーション作成に関する指針を作成し、CCカタログAPIドキュメンテーションへの貢献方法、ドキュメンテーションスタイル、およびdrf-yasgのショートカット表を提供しました。また、このブログ記事も書きました。

第9週：第9週にはすべてのGSoDタスクを完了しましたので、数日間休んで先週のプルリクエストを修正しました。Kritiから新しいタスクが割り当てられました。それはCCカタログドキュメンテーションを内部WikiからGitHubリポジトリに移行することです。CCカタログの管理者であるBrentは、私が何をする必要があるかについて説明してくれました。

第10週：CCカタログとそのドキュメンテーションを探求し始めました。これはGSoD最初と2週目の頃を思い出させます。新しいことを理解しようと試み、点がつながる「あっ」という瞬間があります。内部WikiからCCカタログのGitHubリポジトリにドキュメンテーションを移行する作業も始めました。

第11週：CCカタログドキュメンテーションの移行作業を完了しました。Kritiは、私がGSoDで何を行ったかについてプレゼンテーションを行う会議があると教えてくれました。その会議が私の時間帯では午前1時なので、Kritiはビデオプレゼンテーションを送るように指示されました。

第12週：Kritiにビデオプレゼンテーションを提出しました。プロジェクトレポートと評価を作成し、GSoDの完了を報告しました。この週には更新内容についてのWeek 11とWeek 12のブログ記事と、このブログ記事を含めて2つのブログ記事を公開しました。最新のCCカタログAPIドキュメンテーションはここからご覧いただけます。]]></description>
            <content:encoded><![CDATA[素晴らしい経験をありがとうございました、クリエイティブコモンズ！このブログ記事は、‘CCカタログAPI使用ガイド改善’プロジェクトのレポートとして機能します。私はGoogle Season of Docs (GSOD) 2020期間中にどのような作業を行ったかについて説明しています。このプロジェクトのメンターはクリエイティブコモンズのAlden PageとKriti Godeyです。ドキュメント開発フェーズでは合計12週間があります。2週ごとに、私は進捗状況をメンターや組織に更新するためのブログ記事を公開しています。

第1週：Google Season of Docsの最初の2週間が過ぎました。初週にはcurlコマンドを使用してクエリを行う例を追加しました。Forbiddenエラーで問題が発生したので、アクセスキーが期限切れだったことが分かりました。新しいアクセスキーを取得することで解決しました。

第2週：2週目にはレスポンスサンプルの作成を始めました。drf-yasg（Swaggerジェネレーター）を理解するのが難しかったため、大変でした。drf-yasgはDjango Rest Framework APIからSwagger / OpenAPI 2.0仕様を作成する自動的なSwaggerジェネレーターです。理解を深めるために可能な限り多くの例を探しました。面白いことに、drf-yasgがランダムな文字の組み合わせではなく、DRFがDjango Rest FrameworkでYASGがYet Another Swagger Generatorを意味することに気づくのに時間がかかりました。

第3週：第3週は非常に忙しかったです。第3週には故郷に戻りました。引っ越しと作業スペースの設置のために3日間休みました。月曜日と火曜日の2日間だけプロジェクトに取り組み、ほとんどのAPIエンドポイントに対するレスポンスサンプルを作成しました。この週はKritiとの月次のビデオ通話がありました。

第4週：これまでの作業と未完了のタスクをレビューし、新しい完成予定時間を推定しました。幸いにもGSoDタイムラインにはバッファーウィークがあり、納品物も間に合っています。よって、完成時間については問題ありません。APIエンドポイントに対する説明文を作成し、最初のプルリクエストを提出してブログ記事を公開しました。

第5週：多くの内容をドキュメントに追加しました。クラスへのヘルプテキストの追加方法やシリアライザの作成方法を見つけました。コード例をレスポンスサンプルの下に移動するために、x-code-samplesを追加するための新しいCustomAutoSchemaクラスを作成しました。他のタスクには「登録と認証」や「用語集」などの新セクションの作成が含まれます。

第6週：GitHubで貢献を開始するためのTodoリストを含む新たなセクション「Contribute」を追加しました。また、このブログ記事も書きました。

第7週：CCカタログAPIリポジトリのファイルREADMEを再構成しました。ローカルサーバーを起動する手順をステップバイステップで説明したガイドを追加しました。更新されたローカルサーバーの実行方法についてのガイドにより、新しいユーザーがこのプロジェクトに貢献することに対する恐怖心が和らぐことを願っています。

第8週：ドキュメンテーション作成に関する指針を作成し、CCカタログAPIドキュメンテーションへの貢献方法、ドキュメンテーションスタイル、およびdrf-yasgのショートカット表を提供しました。また、このブログ記事も書きました。

第9週：第9週にはすべてのGSoDタスクを完了しましたので、数日間休んで先週のプルリクエストを修正しました。Kritiから新しいタスクが割り当てられました。それはCCカタログドキュメンテーションを内部WikiからGitHubリポジトリに移行することです。CCカタログの管理者であるBrentは、私が何をする必要があるかについて説明してくれました。

第10週：CCカタログとそのドキュメンテーションを探求し始めました。これはGSoD最初と2週目の頃を思い出させます。新しいことを理解しようと試み、点がつながる「あっ」という瞬間があります。内部WikiからCCカタログのGitHubリポジトリにドキュメンテーションを移行する作業も始めました。

第11週：CCカタログドキュメンテーションの移行作業を完了しました。Kritiは、私がGSoDで何を行ったかについてプレゼンテーションを行う会議があると教えてくれました。その会議が私の時間帯では午前1時なので、Kritiはビデオプレゼンテーションを送るように指示されました。

第12週：Kritiにビデオプレゼンテーションを提出しました。プロジェクトレポートと評価を作成し、GSoDの完了を報告しました。この週には更新内容についてのWeek 11とWeek 12のブログ記事と、このブログ記事を含めて2つのブログ記事を公開しました。最新のCCカタログAPIドキュメンテーションはここからご覧いただけます。]]></content:encoded>
            <author>['ariessa']</author>
        </item>
        <item>
            <title><![CDATA[ビデオプレゼンテーション、プロジェクトレポートおよび評価フォームの完成]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/finish-video-presentation-project-report-and-evaluation-form/</link>
            <guid isPermaLink="false">urn:uuid:ce71600f-f8a9-3593-b5c6-f0b875ab8014</guid>
            <pubDate>Tue, 01 Dec 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[10週目と11週目に、CCカタログドキュメンテーションの移植を完了し、ビデオプレゼンテーションを提出し、GSoD 2020の旅を締めくくりました。11週目の内容としては、内部WikiからCC CatalogのGitHubリポジトリへのドキュメンテーションの移植作業を終えました。Kritiから、私がGSoDで行ったことをプレゼンするミーティングがあると伝えられました。しかし、そのミーティングが私の現地時間では午前1時に行われるため、Kritiにビデオプレゼンテーションを送るべきだと指示されました。12週目の内容としては、Kritiへビデオプレゼンテーションを提出し、GSoDのプロジェクトレポートと評価を完成させました。また、この週には更新情報として11週目と12週目の内容についてのブログ記事と、私のGSoD 2020の旅の概要（プロジェクトレポートとしても機能する）という2つのブログ記事を公開しました。これで全て終了です。]]></description>
            <content:encoded><![CDATA[10週目と11週目に、CCカタログドキュメンテーションの移植を完了し、ビデオプレゼンテーションを提出し、GSoD 2020の旅を締めくくりました。11週目の内容としては、内部WikiからCC CatalogのGitHubリポジトリへのドキュメンテーションの移植作業を終えました。Kritiから、私がGSoDで行ったことをプレゼンするミーティングがあると伝えられました。しかし、そのミーティングが私の現地時間では午前1時に行われるため、Kritiにビデオプレゼンテーションを送るべきだと指示されました。12週目の内容としては、Kritiへビデオプレゼンテーションを提出し、GSoDのプロジェクトレポートと評価を完成させました。また、この週には更新情報として11週目と12週目の内容についてのブログ記事と、私のGSoD 2020の旅の概要（プロジェクトレポートとしても機能する）という2つのブログ記事を公開しました。これで全て終了です。]]></content:encoded>
            <author>['ariessa']</author>
        </item>
        <item>
            <title><![CDATA[CC Base ドキュメントをご紹介 - CC Base Theme の WordPress 基盤テーマ利用ガイド]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-wp-base-theme-docs-launch/</link>
            <guid isPermaLink="false">urn:uuid:709b01b4-8a76-378d-bda1-a52995e88bb8</guid>
            <pubDate>Fri, 27 Nov 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[お知らせ 🎉 CC Base ドキュメントが公開されました。ドキュメントはこのリンクからアクセスできます。Google Docs からの移行作業も完了しました！テーマの名称変更により、CC WP Theme Base は CC Base に改名されています。しかし、「良いドキュメンテーションとは完璧を期すものではない」という格言通り、今後もクリエイティブ・コモンズ コミュニティと協力し、ユーザビリティテストを行っていきます。収集したフィードバックは CC Base ドキュメントのさらなる改善に活用されます。将来的には以下の機能を追加予定です：説明的なメディアの量を増やしてドキュメンテーションを直感的かつ理解しやすいものにするため、CC Base サーティンフィーチャーを使用する方法を紹介したビデオチュートリアルと、プロジェクト構造における重要なディレクトリやファイルの階層関係を説明する図表の追加。また、静的生成サイト向け検索機能を強化するためのソフトウェアツール Algolia の統合も計画しています。さらに、サイトの SEO を向上させることで、ドキュメンテーション全体のユーザーエクスペリエンスとコミュニティメンバーの早期導入を促進します。最後に、クリエイティブ・コモンズ エンジニアリングチーム全員、特に Hugo Solar さんと Kriti Godey さんに感謝申し上げます。技術ドキュメンテーション作成者およびソフトウェア開発者の私の能力に対するご指導と信頼に心より感謝いたします。]]></description>
            <content:encoded><![CDATA[お知らせ 🎉 CC Base ドキュメントが公開されました。ドキュメントはこのリンクからアクセスできます。Google Docs からの移行作業も完了しました！テーマの名称変更により、CC WP Theme Base は CC Base に改名されています。しかし、「良いドキュメンテーションとは完璧を期すものではない」という格言通り、今後もクリエイティブ・コモンズ コミュニティと協力し、ユーザビリティテストを行っていきます。収集したフィードバックは CC Base ドキュメントのさらなる改善に活用されます。将来的には以下の機能を追加予定です：説明的なメディアの量を増やしてドキュメンテーションを直感的かつ理解しやすいものにするため、CC Base サーティンフィーチャーを使用する方法を紹介したビデオチュートリアルと、プロジェクト構造における重要なディレクトリやファイルの階層関係を説明する図表の追加。また、静的生成サイト向け検索機能を強化するためのソフトウェアツール Algolia の統合も計画しています。さらに、サイトの SEO を向上させることで、ドキュメンテーション全体のユーザーエクスペリエンスとコミュニティメンバーの早期導入を促進します。最後に、クリエイティブ・コモンズ エンジニアリングチーム全員、特に Hugo Solar さんと Kriti Godey さんに感謝申し上げます。技術ドキュメンテーション作成者およびソフトウェア開発者の私の能力に対するご指導と信頼に心より感謝いたします。]]></content:encoded>
            <author>['JackieBinya']</author>
        </item>
        <item>
            <title><![CDATA[語彙サイト更新（パート3/n）]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-vocabulary-docs-updates-3/</link>
            <guid isPermaLink="false">urn:uuid:507beaf2-e097-3c39-b06f-9684e44ccf6c</guid>
            <pubDate>Wed, 25 Nov 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[今週の語彙サイト更新についてもっと知りたいですか？詳しく読むために続けてください！

語彙サイト更新（第3版/さらに多くの更新が控えています）

私がこれまでに取り組んできたこと...

不思議な感覚... 合併？はい、合併しました。
私のストーリーを紹介します！

UXデザイナーからOKが出た後、GSoDウェブサイトのPRをレビューのために掲載しました。変更があるだろうと自信を持っていましたが、それを受け入れました。ここで重要なのは、あなたにとって完璧に見えるものが他の人にはそうではない場合があり、経験を通じて正しい判断ができるようになるということです。

スペース、テキストコンテンツ、色に関するいくつかの問題がありました。すぐに解決しました。zackkrida はすべてを指摘してくれました！

エンジニアリングチームからの最終承認を受けた後、私のPRがついに合併されました！語彙サイトの最終版が公開されています！Netlifyで展開されるとすぐに一般公開されます。

読者の皆さんへ、最終版のプレビューを提供します。最適化を試みましたが、何かフィードバックがあればGitHubリポジトリで問題を報告してください。

有名なLighthouseレポートによれば、これは良いスタートです！

アクセシビリティも可能な限り考慮しています。

高めの目標を目指しています！

私が学んだこと...
GSoDはドキュメンテーションだけではなく、本格的なコーディングもあります！コードを長時間書き続ける必要はありません。休憩を取り、戻ってみると解決策が思い浮かびます。

スケジュールは変わるかもしれませんが、プロジェクトの重要な要素である即興性も大切です！

MDXは便利なフォーマットです！コードのドキュメンテーションを書くのがずっと楽になります。

物事が陳腐化し、バージョンが古くなります。そのため、コードの維持は容易ではありません！

他のコミュニティワークの一端...
オープンソース組織の一員であることは、既存の貢献者と初めての貢献者の両方から貢献を引き出すことも意味します。

以下がその一端です：

ダークモードPRはハッカートーフェストの貢献として始まりましたが、今では完成しています！パッケージ間で共通ファイルを格納するための/sharedパッケージを作成しました（Reactドキュメンテーションを参照してダークとライトテーマを作りました）。自動化されたnpm README.mdカスタマイズはすでに稼働中です。（この問題を解決するのが楽しかった！）

スナップショットテストが承認されれば、chromaticで実行されます。

ルーツREADME.mdファイルに複数のバッジを追加するための問題を提起しました。具体的にはLernaで維持されているバッジとパッケージサイズのカスタムバッジ（packagephobiaから）です。

あなたの時間をいただき、ありがとうございます！

最終回をお楽しみに！]]></description>
            <content:encoded><![CDATA[今週の語彙サイト更新についてもっと知りたいですか？詳しく読むために続けてください！

語彙サイト更新（第3版/さらに多くの更新が控えています）

私がこれまでに取り組んできたこと...

不思議な感覚... 合併？はい、合併しました。
私のストーリーを紹介します！

UXデザイナーからOKが出た後、GSoDウェブサイトのPRをレビューのために掲載しました。変更があるだろうと自信を持っていましたが、それを受け入れました。ここで重要なのは、あなたにとって完璧に見えるものが他の人にはそうではない場合があり、経験を通じて正しい判断ができるようになるということです。

スペース、テキストコンテンツ、色に関するいくつかの問題がありました。すぐに解決しました。zackkrida はすべてを指摘してくれました！

エンジニアリングチームからの最終承認を受けた後、私のPRがついに合併されました！語彙サイトの最終版が公開されています！Netlifyで展開されるとすぐに一般公開されます。

読者の皆さんへ、最終版のプレビューを提供します。最適化を試みましたが、何かフィードバックがあればGitHubリポジトリで問題を報告してください。

有名なLighthouseレポートによれば、これは良いスタートです！

アクセシビリティも可能な限り考慮しています。

高めの目標を目指しています！

私が学んだこと...
GSoDはドキュメンテーションだけではなく、本格的なコーディングもあります！コードを長時間書き続ける必要はありません。休憩を取り、戻ってみると解決策が思い浮かびます。

スケジュールは変わるかもしれませんが、プロジェクトの重要な要素である即興性も大切です！

MDXは便利なフォーマットです！コードのドキュメンテーションを書くのがずっと楽になります。

物事が陳腐化し、バージョンが古くなります。そのため、コードの維持は容易ではありません！

他のコミュニティワークの一端...
オープンソース組織の一員であることは、既存の貢献者と初めての貢献者の両方から貢献を引き出すことも意味します。

以下がその一端です：

ダークモードPRはハッカートーフェストの貢献として始まりましたが、今では完成しています！パッケージ間で共通ファイルを格納するための/sharedパッケージを作成しました（Reactドキュメンテーションを参照してダークとライトテーマを作りました）。自動化されたnpm README.mdカスタマイズはすでに稼働中です。（この問題を解決するのが楽しかった！）

スナップショットテストが承認されれば、chromaticで実行されます。

ルーツREADME.mdファイルに複数のバッジを追加するための問題を提起しました。具体的にはLernaで維持されているバッジとパッケージサイズのカスタムバッジ（packagephobiaから）です。

あなたの時間をいただき、ありがとうございます！

最終回をお楽しみに！]]></content:encoded>
            <author>['nimishbongale']</author>
        </item>
        <item>
            <title><![CDATA[GSoDタスクの完了とCCカタログドキュメンテーションの探索]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/finish-gsod-tasks-and-explore-cc-catalog-documentation/</link>
            <guid isPermaLink="false">urn:uuid:cb15a8e1-87d2-37b4-b699-be579f80f08f</guid>
            <pubDate>Fri, 20 Nov 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[今日は、Creative Commonsに関する5回目のブログ記事を書きます。9週目と10週目にかけて、私はCCカタログのドキュメンテーションを探求し、キーの削除や指示の一般化を通じてドキュメンテーションの改善を始めました。9週目にはすべてのGSoDタスクを完了しましたので、数日間休んで先週のPRを修正しました。Kritiから新しいタスクが割り当てられ、それは内部WikiからCCカタログのドキュメンテーションをGitHubリポジトリに移行することでした。CCカタログのメンテナであるBrentは私に何が必要か説明してくれました。10週目には、私はCCカタログとそのドキュメンテーションを探求し始めました。これはGSoDの最初と2週目の頃を思い起こさせます。新しいことを理解しようと試み、点がつながった瞬間の「あっ」という感覚です。私は内部WikiからCCカタログのGitHubリポジトリにドキュメンテーションを移動し始めました。またこのブログ記事も書きました。ブログエントリー終了。]]></description>
            <content:encoded><![CDATA[今日は、Creative Commonsに関する5回目のブログ記事を書きます。9週目と10週目にかけて、私はCCカタログのドキュメンテーションを探求し、キーの削除や指示の一般化を通じてドキュメンテーションの改善を始めました。9週目にはすべてのGSoDタスクを完了しましたので、数日間休んで先週のPRを修正しました。Kritiから新しいタスクが割り当てられ、それは内部WikiからCCカタログのドキュメンテーションをGitHubリポジトリに移行することでした。CCカタログのメンテナであるBrentは私に何が必要か説明してくれました。10週目には、私はCCカタログとそのドキュメンテーションを探求し始めました。これはGSoDの最初と2週目の頃を思い起こさせます。新しいことを理解しようと試み、点がつながった瞬間の「あっ」という感覚です。私は内部WikiからCCカタログのGitHubリポジトリにドキュメンテーションを移動し始めました。またこのブログ記事も書きました。ブログエントリー終了。]]></content:encoded>
            <author>['ariessa']</author>
        </item>
        <item>
            <title><![CDATA[コンテンツ作成フェーズ: WordPressベーステーマの使用ガイド]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-wp-base-theme-docs-content-creation/</link>
            <guid isPermaLink="false">urn:uuid:9ea78ea3-f8df-3d37-a0df-5297eb1c42df</guid>
            <pubDate>Tue, 10 Nov 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[過去数週間、Creative Commons WordPressベーステーマの使用ガイドのコンテンツを作成してきました。現在、ドラフト内容は最終レビュー中で、正式にドキュメンテーションサイトへ移行される前に最終的なチェックが行われています。

私たちの戦略：
主な目標は、技術的で直感的、魅力的で美しく表現されたコミュニティ向けのドキュメントを作成することです。この目標を達成するために、私たちは協力してドキュメンテーションを作成します。CC WordPressチームには、ジャクリーヌ・ビニャ、フーゴ・ソラール、タイムィド・ロボット・ゼータがいます。

私たちのチームは小規模ですが、多様性に富んでおり、技術スキルも多岐にわたります：私は若手開発者で、フーゴとタイムィドは経験豊かなベテランです。また、ネイティブスピーカーと非ネイティブスピーカーが混在しています。

多様性は重要であり、私たちの目標はすべての人々に適した高品質な製品を作成することです。

私の役割：
技術ライター/フロントエンド開発者として、私はドキュメンテーションの作成、ドキュメンテーションサイトの構築、そして全ての解説用メディアの作成を行います。コンテンツ作成フェーズでは、最初にドキュメンテーションサイトの骨組みを作りました。creative-commons/wp-base-theme リポジトリ内に docs という名前の git ブランチを作成し、そのブランチで全てのドキュメンテーション関連の内容を保存しています。

その後、JamDocs（Gridsomeテーマ）を使用してサイトのフレームワークを作りました。私たちのニーズに合わせてテーマを調整する必要がありましたが、スタイルの刷新や一部機能の変更を行いました。

次に、ドキュメンテーションサイト用のドラフトコンテンツを共同で作成するために Google ドキュメントを使用しました。

技術スタック：
Gridsome（Vuejs用の静的ジェネレーター）を選択した理由は以下の通りです：貢献の障壁を低く保つため、Gridsome/Vuejsコミュニティは非常に活発で、助けを求めることはクリック一つで可能です。公式ドキュメンテーションも豊富で維持されています。

コンテンツはMarkdownで書かれていますが、@gridsome/vue-remark（Gridsomeプラグイン）を使用することでJavaScriptをMarkdown内で使用できます。

時間制約：このプロジェクトは3ヶ月間の短期プロジェクトです。JamDocsやGridsomeテンプレートテーマ、各種プラグインを使用することで、開始時の容易さと速さが確保できました。

CC Vocabularyとの統合の容易性：全てのフロントエンドCreative Commonsアプリケーションの一般的な外観は、CC Vocabularyデザインシステムから派生しています。デザインシステムを使用する主なデメリットには、すべてのフロントエンドCC製品における一貫したデザインを確保することが含まれます。

使用ツール：
Figma：テーマ内のアセット（バナー、ロゴ、イラスト）を作成するために使用されました。解説用メディアはアクセシビリティを考慮して作られ、全てのトップグラフィックはCC Vocabularyから派生しています。
VokoScreenNG：ドキュメンテーションサイトで利用可能なすべてのスクリーンキャストデモを録画するためのオープンソースのスクリーンキャストツールです。
ShortCut：オープンソースビデオ編集ツール。

次に何が行われるか？
最終レビューが完了し、全てのフィードバックが反映された後、コンテンツは正式なドキュメンテーションサイトへ移行されます。CC WPベーステーマドキュメンテーションサイトのローンチに関する更新情報をお楽しみにください。]]></description>
            <content:encoded><![CDATA[過去数週間、Creative Commons WordPressベーステーマの使用ガイドのコンテンツを作成してきました。現在、ドラフト内容は最終レビュー中で、正式にドキュメンテーションサイトへ移行される前に最終的なチェックが行われています。

私たちの戦略：
主な目標は、技術的で直感的、魅力的で美しく表現されたコミュニティ向けのドキュメントを作成することです。この目標を達成するために、私たちは協力してドキュメンテーションを作成します。CC WordPressチームには、ジャクリーヌ・ビニャ、フーゴ・ソラール、タイムィド・ロボット・ゼータがいます。

私たちのチームは小規模ですが、多様性に富んでおり、技術スキルも多岐にわたります：私は若手開発者で、フーゴとタイムィドは経験豊かなベテランです。また、ネイティブスピーカーと非ネイティブスピーカーが混在しています。

多様性は重要であり、私たちの目標はすべての人々に適した高品質な製品を作成することです。

私の役割：
技術ライター/フロントエンド開発者として、私はドキュメンテーションの作成、ドキュメンテーションサイトの構築、そして全ての解説用メディアの作成を行います。コンテンツ作成フェーズでは、最初にドキュメンテーションサイトの骨組みを作りました。creative-commons/wp-base-theme リポジトリ内に docs という名前の git ブランチを作成し、そのブランチで全てのドキュメンテーション関連の内容を保存しています。

その後、JamDocs（Gridsomeテーマ）を使用してサイトのフレームワークを作りました。私たちのニーズに合わせてテーマを調整する必要がありましたが、スタイルの刷新や一部機能の変更を行いました。

次に、ドキュメンテーションサイト用のドラフトコンテンツを共同で作成するために Google ドキュメントを使用しました。

技術スタック：
Gridsome（Vuejs用の静的ジェネレーター）を選択した理由は以下の通りです：貢献の障壁を低く保つため、Gridsome/Vuejsコミュニティは非常に活発で、助けを求めることはクリック一つで可能です。公式ドキュメンテーションも豊富で維持されています。

コンテンツはMarkdownで書かれていますが、@gridsome/vue-remark（Gridsomeプラグイン）を使用することでJavaScriptをMarkdown内で使用できます。

時間制約：このプロジェクトは3ヶ月間の短期プロジェクトです。JamDocsやGridsomeテンプレートテーマ、各種プラグインを使用することで、開始時の容易さと速さが確保できました。

CC Vocabularyとの統合の容易性：全てのフロントエンドCreative Commonsアプリケーションの一般的な外観は、CC Vocabularyデザインシステムから派生しています。デザインシステムを使用する主なデメリットには、すべてのフロントエンドCC製品における一貫したデザインを確保することが含まれます。

使用ツール：
Figma：テーマ内のアセット（バナー、ロゴ、イラスト）を作成するために使用されました。解説用メディアはアクセシビリティを考慮して作られ、全てのトップグラフィックはCC Vocabularyから派生しています。
VokoScreenNG：ドキュメンテーションサイトで利用可能なすべてのスクリーンキャストデモを録画するためのオープンソースのスクリーンキャストツールです。
ShortCut：オープンソースビデオ編集ツール。

次に何が行われるか？
最終レビューが完了し、全てのフィードバックが反映された後、コンテンツは正式なドキュメンテーションサイトへ移行されます。CC WPベーステーマドキュメンテーションサイトのローンチに関する更新情報をお楽しみにください。]]></content:encoded>
            <author>['JackieBinya']</author>
        </item>
        <item>
            <title><![CDATA[語彙サイトの中間インターンシップ更新 (v2)]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-vocabulary-docs-updates-2/</link>
            <guid isPermaLink="false">urn:uuid:8222e673-fc0d-31e0-b068-bc802bdb5459</guid>
            <pubDate>Mon, 09 Nov 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[これは中間のブログ記事です。待って、もう？という感じですね。では、進捗を振り返りましょうか？ 語彙サイト更新（第2版/さらに多くの更新が続く予定） ウー！ CC語彙用のランディングページと使用ガイドを作成してから1.5ヶ月が経過しました。前回のブログ記事を投稿したとき以来、多くの変化がありました。たくさんの変化です。 「戻れない点」に到達することはこれほど興奮するものではありませんでした！ サイレンスを上げる時だよ！ 進捗状況： デザイン ⇨ 下書き ⇨ 開発 ⇨ デバッグ ⇨ 配信 このサイクルは続きます。これはすべてをうまくまとめていますね。全称の反復が好きですね？ これまでに達成したことの一覧： デザインを2回改良しました。新しいサイトの見た目には満足しています（デザインチームも同様に満足していることを願っています！）。 Monorepo移行、開始ガイド、語彙概要、そしてこれらのブログ記事に関する5件以上の下書きを作成しました。 語彙リポジトリのブランチには50回以上のコミットと13,000行以上のコードがあります（すべてを書いたわけではありませんが、統計のために）。 語彙サイトの初稿が公開されました！ まだ多くの変更が予想されますが、ここでプレビューしてみてください： https://cc-vocab-draft.surge.sh Github APIを使用してライブリリース履歴、フォーク数、スター数を取得しました。これはサイト全体に非常に良い追加要素だと思います。 surge.shを使用して初稿サイトをデプロイしました。これにより、瞬時にサイトをデプロイできる簡単なツールです！ GitHubの貢献チャートが充実しています！ 学んだこと： バーチャルインターンシップでは学べないという意見がありますが、それを証明します。ここ数週間で学んだことをいくつか挙げます： デザインは主観的でありながら客観的なものであることが驚くほどです。 Vue.jsは素晴らしいです。 今やVue.jsファンかもしれません。 Reactに忠実にすべきか？ 私にはわかりません。 サイトをレスポンシブにするのは簡単ではありませんが、伸縮と圧縮を繰り返すことで可能になります。 コードフォーマットの重要性は過小評価されています。 Monorepoにはそれぞれの利点と欠点があります。しかし、私たちの場合、幸いにも欠点は無視できる程度でした！ 今週はパフォーマンスとアクセシビリティテストを実施する予定です。 メンターがプロジェクトで果たす役割は非常に重要です。メンターの@dhruvkbさんはサポートしてくれて、タイムラインに沿って進めるように助けてくれました！ その他のコミュニティワーク： インターンシップ以外でもコミュニティのPR作業を手伝うべきだと考えています。私にはいつでも参加できると言われているので、それは素晴らしいことです！ CCOSイベントでdhruvkbさんとdhruvi16さんと共にスピーチする機会がありました。DSC-IIT SuratとDSC-RITの若き学生たちとの対話は楽しかったです。 ダークモード（約束通り）は次のブログ記事までにはリリースされる予定です。 Chromaticで語彙ストーリーブックをデプロイし、利点と欠点を比較しました。 今後のスナップショットテストも検討中です。 Hacktoberfestのチャレンジをクリアしました。 ボーナスコンテンツ： このサイトはLektor CMSを使用しています。 Windows 10 OSで当サイトリポジトリのコードを実行するために、システムにインストールする必要がありました。 Lektorは以下のコマンドをpowershellで実行することを推奨します： (new-object net.webclient).DownloadString('https://www.getlektor.com/installer.py') | python これが洗練された方法とは思えませんでした。 chocolatey.orgのファンとして、ここにアップロードする必要がありました！ 現在、Windows PowerShellで以下のコマンドだけでインストールできます： choco install lektor パッケージを確認してください： https://chocolatey.org/packages/lektor お読みいただきありがとうございました！ 次回の語彙サイト更新をお楽しみに！]]></description>
            <content:encoded><![CDATA[これは中間のブログ記事です。待って、もう？という感じですね。では、進捗を振り返りましょうか？ 語彙サイト更新（第2版/さらに多くの更新が続く予定） ウー！ CC語彙用のランディングページと使用ガイドを作成してから1.5ヶ月が経過しました。前回のブログ記事を投稿したとき以来、多くの変化がありました。たくさんの変化です。 「戻れない点」に到達することはこれほど興奮するものではありませんでした！ サイレンスを上げる時だよ！ 進捗状況： デザイン ⇨ 下書き ⇨ 開発 ⇨ デバッグ ⇨ 配信 このサイクルは続きます。これはすべてをうまくまとめていますね。全称の反復が好きですね？ これまでに達成したことの一覧： デザインを2回改良しました。新しいサイトの見た目には満足しています（デザインチームも同様に満足していることを願っています！）。 Monorepo移行、開始ガイド、語彙概要、そしてこれらのブログ記事に関する5件以上の下書きを作成しました。 語彙リポジトリのブランチには50回以上のコミットと13,000行以上のコードがあります（すべてを書いたわけではありませんが、統計のために）。 語彙サイトの初稿が公開されました！ まだ多くの変更が予想されますが、ここでプレビューしてみてください： https://cc-vocab-draft.surge.sh Github APIを使用してライブリリース履歴、フォーク数、スター数を取得しました。これはサイト全体に非常に良い追加要素だと思います。 surge.shを使用して初稿サイトをデプロイしました。これにより、瞬時にサイトをデプロイできる簡単なツールです！ GitHubの貢献チャートが充実しています！ 学んだこと： バーチャルインターンシップでは学べないという意見がありますが、それを証明します。ここ数週間で学んだことをいくつか挙げます： デザインは主観的でありながら客観的なものであることが驚くほどです。 Vue.jsは素晴らしいです。 今やVue.jsファンかもしれません。 Reactに忠実にすべきか？ 私にはわかりません。 サイトをレスポンシブにするのは簡単ではありませんが、伸縮と圧縮を繰り返すことで可能になります。 コードフォーマットの重要性は過小評価されています。 Monorepoにはそれぞれの利点と欠点があります。しかし、私たちの場合、幸いにも欠点は無視できる程度でした！ 今週はパフォーマンスとアクセシビリティテストを実施する予定です。 メンターがプロジェクトで果たす役割は非常に重要です。メンターの@dhruvkbさんはサポートしてくれて、タイムラインに沿って進めるように助けてくれました！ その他のコミュニティワーク： インターンシップ以外でもコミュニティのPR作業を手伝うべきだと考えています。私にはいつでも参加できると言われているので、それは素晴らしいことです！ CCOSイベントでdhruvkbさんとdhruvi16さんと共にスピーチする機会がありました。DSC-IIT SuratとDSC-RITの若き学生たちとの対話は楽しかったです。 ダークモード（約束通り）は次のブログ記事までにはリリースされる予定です。 Chromaticで語彙ストーリーブックをデプロイし、利点と欠点を比較しました。 今後のスナップショットテストも検討中です。 Hacktoberfestのチャレンジをクリアしました。 ボーナスコンテンツ： このサイトはLektor CMSを使用しています。 Windows 10 OSで当サイトリポジトリのコードを実行するために、システムにインストールする必要がありました。 Lektorは以下のコマンドをpowershellで実行することを推奨します： (new-object net.webclient).DownloadString('https://www.getlektor.com/installer.py') | python これが洗練された方法とは思えませんでした。 chocolatey.orgのファンとして、ここにアップロードする必要がありました！ 現在、Windows PowerShellで以下のコマンドだけでインストールできます： choco install lektor パッケージを確認してください： https://chocolatey.org/packages/lektor お読みいただきありがとうございました！ 次回の語彙サイト更新をお楽しみに！]]></content:encoded>
            <author>['nimishbongale']</author>
        </item>
        <item>
            <title><![CDATA[READMEの再構成とドキュメンテーションガイドラインの追加]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/restructure-readme-and-add-documentation-guidelines/</link>
            <guid isPermaLink="false">urn:uuid:9d0c575b-8276-32b1-a4e5-42c2674b4e36</guid>
            <pubDate>Thu, 05 Nov 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[これはCreative Commonsに関する私の4番目のブログ記事です。7週目と8週目に、私はファイルREADMEを新規ユーザーにとってより理解しやすいものに再構成し、CC Catalog APIドキュメンテーション用のドキュメンテーションガイドラインを作成しました。

7週目：この週には、私はCC Catalog APIリポジトリ内のファイルREADMEを再構成しました。ローカルでサーバーを実行する方法に関するステップバイステップガイドを追加しました。更新されたローカルサーバーの実行方法についてのガイドにより、新規ユーザーがこのプロジェクトへの貢献に怯むことが少なくなることを願っています。

8週目：8週目に、私はドキュメンテーションガイドラインを作成し、CC Catalog APIドキュメンテーションへの貢献方法、ドキュメンテーションスタイル、およびdrf-yasgのショートカットシートを提供しました。また、このブログ記事も執筆して公開しました。

以上です。]]></description>
            <content:encoded><![CDATA[これはCreative Commonsに関する私の4番目のブログ記事です。7週目と8週目に、私はファイルREADMEを新規ユーザーにとってより理解しやすいものに再構成し、CC Catalog APIドキュメンテーション用のドキュメンテーションガイドラインを作成しました。

7週目：この週には、私はCC Catalog APIリポジトリ内のファイルREADMEを再構成しました。ローカルでサーバーを実行する方法に関するステップバイステップガイドを追加しました。更新されたローカルサーバーの実行方法についてのガイドにより、新規ユーザーがこのプロジェクトへの貢献に怯むことが少なくなることを願っています。

8週目：8週目に、私はドキュメンテーションガイドラインを作成し、CC Catalog APIドキュメンテーションへの貢献方法、ドキュメンテーションスタイル、およびdrf-yasgのショートカットシートを提供しました。また、このブログ記事も執筆して公開しました。

以上です。]]></content:encoded>
            <author>['ariessa']</author>
        </item>
        <item>
            <title><![CDATA[語彙サイト更新 (v1)]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-vocabulary-docs-updates-1/</link>
            <guid isPermaLink="false">urn:uuid:34777cb0-bbaa-3e90-90e9-72d944d86abf</guid>
            <pubDate>Mon, 26 Oct 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは！少なくとも言うと、最初の数週間は非常に活発な期間でした！私の進捗を測定しましょうか？ 語彙サイト更新（第1版/さらに多くのバージョンが続く予定） 私がこれまでに取り組んできたこと 主に現在のドキュメントの調査に時間を費やし、改善が必要な箇所を見つけています。それらの問題を解決した後、Vocabulary、Vue-vocabulary、Fontsのメインランディングサイトを作り始めました。必要なワークフローを確立するには特に難しくはありませんでした（以前似たようなことをしていたため）。サイトの基本構造を設計する過程で、新しい/改善されたコンポーネントが必要だと感じた場面があり、その点についてはスプリントコールでチームと議論しました。サイトのデザインはほぼ完成しています。私は同時にサイトを作成し、CCデザインチームからの承認を求めています。また、私たちの複数のリポジトリでのコミュニティへの他の貢献にも参加しています。 私が学んだこと 現在のプロジェクトで既に存在するコードを理解することは非常に重要です。扱っているコードのスタイルや構造、活動を理解することが大切です。忍耐力を持つことが重要です！特定のタスクが完了した後でなければ論理的に達成できない場合は、それを遅らせるのも良いでしょう。きれいなコードを書くことの重要性はあまり語られていません（なぜだろうかと不思議に思います）。VueJSがデフォルトでSPAを設定すると思っていたのですが、驚いたことにそれを行うには追加の設定が必要だと分かりました！Storybookは本当に優れたオープンソースプロジェクトであり、素晴らしいコミュニティサポートがあります！ 他のコミュニティワークの要点 ダークモード（少なくとも私にとっては待ち望んでいた機能）を作成しています。これは私たちのストーリーブックで、コミュニティからの一部の支援を受けています。間もなく稼働する予定です！README.mdのフォーマットバグを修正し、npm v7の考慮事項に基づく変更を提案しました。2つの機能のStorybookコンポーネントドキュメントを修正しました。Vocabulary内でマークダウンテキストをレンダリングするためのコンポーネントについてチケットを作成しました。ハッカートフェストへの潜在的な貢献として他のいくつかの問題も作成しました。 あなたの時間をいただき、ありがとうございます！続きます...]]></description>
            <content:encoded><![CDATA[こんにちは！少なくとも言うと、最初の数週間は非常に活発な期間でした！私の進捗を測定しましょうか？ 語彙サイト更新（第1版/さらに多くのバージョンが続く予定） 私がこれまでに取り組んできたこと 主に現在のドキュメントの調査に時間を費やし、改善が必要な箇所を見つけています。それらの問題を解決した後、Vocabulary、Vue-vocabulary、Fontsのメインランディングサイトを作り始めました。必要なワークフローを確立するには特に難しくはありませんでした（以前似たようなことをしていたため）。サイトの基本構造を設計する過程で、新しい/改善されたコンポーネントが必要だと感じた場面があり、その点についてはスプリントコールでチームと議論しました。サイトのデザインはほぼ完成しています。私は同時にサイトを作成し、CCデザインチームからの承認を求めています。また、私たちの複数のリポジトリでのコミュニティへの他の貢献にも参加しています。 私が学んだこと 現在のプロジェクトで既に存在するコードを理解することは非常に重要です。扱っているコードのスタイルや構造、活動を理解することが大切です。忍耐力を持つことが重要です！特定のタスクが完了した後でなければ論理的に達成できない場合は、それを遅らせるのも良いでしょう。きれいなコードを書くことの重要性はあまり語られていません（なぜだろうかと不思議に思います）。VueJSがデフォルトでSPAを設定すると思っていたのですが、驚いたことにそれを行うには追加の設定が必要だと分かりました！Storybookは本当に優れたオープンソースプロジェクトであり、素晴らしいコミュニティサポートがあります！ 他のコミュニティワークの要点 ダークモード（少なくとも私にとっては待ち望んでいた機能）を作成しています。これは私たちのストーリーブックで、コミュニティからの一部の支援を受けています。間もなく稼働する予定です！README.mdのフォーマットバグを修正し、npm v7の考慮事項に基づく変更を提案しました。2つの機能のStorybookコンポーネントドキュメントを修正しました。Vocabulary内でマークダウンテキストをレンダリングするためのコンポーネントについてチケットを作成しました。ハッカートフェストへの潜在的な貢献として他のいくつかの問題も作成しました。 あなたの時間をいただき、ありがとうございます！続きます...]]></content:encoded>
            <author>['nimishbongale']</author>
        </item>
        <item>
            <title><![CDATA[新しいセクション、説明、ヘルプテキスト、コード例、スキーマ、シリアライザの追加]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/add-new-sections-descriptions-help-texts-code-examples-schemas-and-serializers/</link>
            <guid isPermaLink="false">urn:uuid:43320831-236b-305f-8ed1-eec9bb877b09</guid>
            <pubDate>Wed, 21 Oct 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは、私の第3回目のブログ記事をお読みください！5週目と6週目にかけて、新しいセクション、説明、ヘルプテキスト、コード例、スキーマ、シリアライザを追加しました。過去2週間は非常に生産的でした。

5週目：この週にはドキュメンテーションに多くの内容を追加しました。クラスにヘルプテキストを追加する方法とシリアライザを作成する方法を見つけました。また、レスポンスサンプルの下にすべてのコード例を移動することもできました。これを行うために、x-code-samplesを追加するための新しいCustomAutoSchemaクラスを作成しました。他の作業としては、「登録と認証」や「用語集」といった新しいセクションを作成しました。この週で最も難しい部分はリクエストボディ例を追加し、コード例を移動することでした。

6週目：6週目にかけて、GitHubでの貢献を開始するためのTodoリストを含む「Contribute」という新しいセクションを追加しました。また、このブログ記事も執筆して公開しました。すべて完了です！]]></description>
            <content:encoded><![CDATA[こんにちは、私の第3回目のブログ記事をお読みください！5週目と6週目にかけて、新しいセクション、説明、ヘルプテキスト、コード例、スキーマ、シリアライザを追加しました。過去2週間は非常に生産的でした。

5週目：この週にはドキュメンテーションに多くの内容を追加しました。クラスにヘルプテキストを追加する方法とシリアライザを作成する方法を見つけました。また、レスポンスサンプルの下にすべてのコード例を移動することもできました。これを行うために、x-code-samplesを追加するための新しいCustomAutoSchemaクラスを作成しました。他の作業としては、「登録と認証」や「用語集」といった新しいセクションを作成しました。この週で最も難しい部分はリクエストボディ例を追加し、コード例を移動することでした。

6週目：6週目にかけて、GitHubでの貢献を開始するためのTodoリストを含む「Contribute」という新しいセクションを追加しました。また、このブログ記事も執筆して公開しました。すべて完了です！]]></content:encoded>
            <author>['ariessa']</author>
        </item>
        <item>
            <title><![CDATA[APIエンドポイントのレスポンスサンプルと説明を追加]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/add-response-samples-and-descriptions-for-api-endpoints/</link>
            <guid isPermaLink="false">urn:uuid:960bbb95-4421-36be-87c0-9b7972a19ca8</guid>
            <pubDate>Fri, 09 Oct 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは👋！週3と週4には、APIエンドポイントのレスポンスサンプルと説明を追加しました。ドキュメンテーションを作成するのは、drf-yasgについて多くを学び、GitHubやStackoverflowで問題や質問を探して重複する（または愚かな）質問を避ける必要があるため、プログラミングに似た感覚があります。

週3は非常に忙しかったです。週3には故郷に戻り、引っ越しの手続きとワークスペースの設置のために3日間休みました。GSoDプロジェクトについては月曜日と火曜日の2日間だけ作業しましたが、ほとんどのAPIエンドポイントのレスポンスサンプルを作成することができました。この週にはクリティとの月次のビデオ通話がありました。

週4では、これまでに何を達成し、何ができていないかを見直して新しい完了予定時間を見積もりました。GSoDのタイムラインと成果物にバッファー週があることに感謝していますので、完了時間については問題ありません。APIエンドポイントの説明を書き始め、最初のプルリクエストを提出し、ブログ記事も公開しました。それでは、また。]]></description>
            <content:encoded><![CDATA[こんにちは👋！週3と週4には、APIエンドポイントのレスポンスサンプルと説明を追加しました。ドキュメンテーションを作成するのは、drf-yasgについて多くを学び、GitHubやStackoverflowで問題や質問を探して重複する（または愚かな）質問を避ける必要があるため、プログラミングに似た感覚があります。

週3は非常に忙しかったです。週3には故郷に戻り、引っ越しの手続きとワークスペースの設置のために3日間休みました。GSoDプロジェクトについては月曜日と火曜日の2日間だけ作業しましたが、ほとんどのAPIエンドポイントのレスポンスサンプルを作成することができました。この週にはクリティとの月次のビデオ通話がありました。

週4では、これまでに何を達成し、何ができていないかを見直して新しい完了予定時間を見積もりました。GSoDのタイムラインと成果物にバッファー週があることに感謝していますので、完了時間については問題ありません。APIエンドポイントの説明を書き始め、最初のプルリクエストを提出し、ブログ記事も公開しました。それでは、また。]]></content:encoded>
            <author>['ariessa']</author>
        </item>
        <item>
            <title><![CDATA[語彙サイトと使用ガイドの紹介 (GSoD'20)]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-vocabulary-docs-intro/</link>
            <guid isPermaLink="false">urn:uuid:28ffb4e1-b12b-31ab-80dc-ce80b9ab7f68</guid>
            <pubDate>Fri, 02 Oct 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[こんにちは！インド・バンガロールを拠点とするテクニカルライター兼ソフトウェア開発者のNimish Bongaleです。私の他の趣味にはチェスやギターがあります。私は、GSoD'20の一環としてCC語彙サイトと使用ガイドの構築に取り組むことを楽しみにしていますが、GSoDとは何でしょうか？GSoD（Google Season of Docs）は、オープンソースプロジェクトにおけるドキュメンテーションの重要性を強調するプログラムです。世界中の技術ライターに参加しているオープンソース組織から提案されたプロジェクトに基づいてプロポーザルを提出することを求めます。選ばれた技術ライターは、その組織と協力してインターンシップ期間終了までに仕事を完成させることを目指します。詳細についてはこちらをご覧ください。

では、私のプロジェクトについて少しご紹介しましょうか？CC語彙サイトと使用ガイドの紹介 CC Vocabularyは、Creative Commonsのウェブフェイスを統一するための包括的なデザインシステムおよびVueコンポーネントライブラリです。現在、Vocabulary、Vue-Vocabulary、Fontsという3つのパッケージで構成されています。私のプロジェクトへの貢献は主にCC Vocabularyのランディングサイトの作成と、必要に応じてドキュメンテーションを再設計することになります。

ドキュメンテーションが重要である理由 ドキュメンテーションは、特定のオープンソースライブラリが成功するかどうかを決定する主要な要因の一つです。開発者がアプリケーションを構築するために適切な技術スタックを選択する際には、次の質問を考えます：このライブラリは十分にドキュメンテーションされていますか？維持管理されていますか？使用例やエラーハンドリングが充実していますか？これらの質問こそ私がプロジェクトアイデアを進める際に自分自身に問い続けるべきものです。前述の通り、簡潔で統合されたドキュメンテーションが必要です。ドキュメンテーションの欠如はオープンソースアプリケーションの将来性を損なうだけでなく、その重要性と不可欠さは疑いようがありません。

プロジェクトの技術スタック プロジェクトではVuejsを使用してサイトを作成し、既存のVocabulary、Vue-Vocabulary、Fontsのストーリーブックスで作業を継続します。Storybookjsには最近素晴らしい改善があり、新しいアドオンが私の作業を大いにサポートしています。それ以外にもStackEditを使用して私の書き物のMarkdownファイルを書くことと共有することも行います。

進行状況 - 小さな一歩 CCで過去に貢献した経験があります。今ではCC Open Sourceの一員として、特定のプロジェクト内での初めての貢献を行っています。これまでに行いまたは達成できたタスクは以下の通りです：オープンソースドキュメンテーションの規約を調査し、違反がないか確認する。ストーリーブックスに現在存在するドキュメンテーションレベルを理解する。Monorepo移行について話し合い、実装を手伝う。storybookjsを最新バージョンに移行する。addon-controlsの実装を行う。Vocabularyサイトをデザインする。CC Open SourceがHacktoberfest 2020で活躍することを促進する。

学んだこと デザインは単なる色選びやグレー画面へのコンポーネント配置だけではありません。自分の書き物を客観的な視点から読むことは、それがどのように受け取られるかを理解するために重要です。メンターとの定期的なコミュニケーションは絶対に必要です。npmjsへの公開は難しくありません！

貴重な時間をいただきありがとうございます！]]></description>
            <content:encoded><![CDATA[こんにちは！インド・バンガロールを拠点とするテクニカルライター兼ソフトウェア開発者のNimish Bongaleです。私の他の趣味にはチェスやギターがあります。私は、GSoD'20の一環としてCC語彙サイトと使用ガイドの構築に取り組むことを楽しみにしていますが、GSoDとは何でしょうか？GSoD（Google Season of Docs）は、オープンソースプロジェクトにおけるドキュメンテーションの重要性を強調するプログラムです。世界中の技術ライターに参加しているオープンソース組織から提案されたプロジェクトに基づいてプロポーザルを提出することを求めます。選ばれた技術ライターは、その組織と協力してインターンシップ期間終了までに仕事を完成させることを目指します。詳細についてはこちらをご覧ください。

では、私のプロジェクトについて少しご紹介しましょうか？CC語彙サイトと使用ガイドの紹介 CC Vocabularyは、Creative Commonsのウェブフェイスを統一するための包括的なデザインシステムおよびVueコンポーネントライブラリです。現在、Vocabulary、Vue-Vocabulary、Fontsという3つのパッケージで構成されています。私のプロジェクトへの貢献は主にCC Vocabularyのランディングサイトの作成と、必要に応じてドキュメンテーションを再設計することになります。

ドキュメンテーションが重要である理由 ドキュメンテーションは、特定のオープンソースライブラリが成功するかどうかを決定する主要な要因の一つです。開発者がアプリケーションを構築するために適切な技術スタックを選択する際には、次の質問を考えます：このライブラリは十分にドキュメンテーションされていますか？維持管理されていますか？使用例やエラーハンドリングが充実していますか？これらの質問こそ私がプロジェクトアイデアを進める際に自分自身に問い続けるべきものです。前述の通り、簡潔で統合されたドキュメンテーションが必要です。ドキュメンテーションの欠如はオープンソースアプリケーションの将来性を損なうだけでなく、その重要性と不可欠さは疑いようがありません。

プロジェクトの技術スタック プロジェクトではVuejsを使用してサイトを作成し、既存のVocabulary、Vue-Vocabulary、Fontsのストーリーブックスで作業を継続します。Storybookjsには最近素晴らしい改善があり、新しいアドオンが私の作業を大いにサポートしています。それ以外にもStackEditを使用して私の書き物のMarkdownファイルを書くことと共有することも行います。

進行状況 - 小さな一歩 CCで過去に貢献した経験があります。今ではCC Open Sourceの一員として、特定のプロジェクト内での初めての貢献を行っています。これまでに行いまたは達成できたタスクは以下の通りです：オープンソースドキュメンテーションの規約を調査し、違反がないか確認する。ストーリーブックスに現在存在するドキュメンテーションレベルを理解する。Monorepo移行について話し合い、実装を手伝う。storybookjsを最新バージョンに移行する。addon-controlsの実装を行う。Vocabularyサイトをデザインする。CC Open SourceがHacktoberfest 2020で活躍することを促進する。

学んだこと デザインは単なる色選びやグレー画面へのコンポーネント配置だけではありません。自分の書き物を客観的な視点から読むことは、それがどのように受け取られるかを理解するために重要です。メンターとの定期的なコミュニケーションは絶対に必要です。npmjsへの公開は難しくありません！

貴重な時間をいただきありがとうございます！]]></content:encoded>
            <author>['nimishbongale']</author>
        </item>
        <item>
            <title><![CDATA[Creative Commons WordPressプラグイン：画像のクレジット情報]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-wp-plugin-attribution-for-images/</link>
            <guid isPermaLink="false">urn:uuid:49e0ab27-05c5-339a-b5f8-a7bcc2d7548b</guid>
            <pubDate>Thu, 01 Oct 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[Centrum CyfroweのEUIPOからの資金提供を受けた#NoWorriesプロジェクトの一環として、私はCreative Commons Wordpressプラグインを強化する喜びを感じています。新しいバージョンのCC Wordpressプラグインには、「画像のクレジット情報」機能があります。これは次のようになります：Wordpressメディアライブラリに画像をアップロードし、正しいクレジット情報を入力します。次に、Image Gutenbergブロックを使用して画像をページに挿入します。その後、サイト上で画像が表示されるとき、プラグインは画像の下部に半透明のオーバーレイとして作者名、画像タイトル、ソースへのリンク、および使用されたCCライセンス情報を表示します。

この機能はどのように動作するのでしょうか？メディアライブラリから関連情報を取得するために、プラグインはGutenberg Image Blocksによってすでに提供されている情報を再利用しています。Wordpressでは、Imageブロックを使用して画像を挿入すると、wp-image-{id}という特殊なCSSクラスが追加され、その中にはメディアライブラリ内の画像の識別子が含まれます。これにより、特定の画像に個別のスタイルを追加できます - 私たちはこれを使用して関連するメディアライブラリのエントリーを見つけ、個別のクレジット情報を追加します。

このアプローチでは、カスタムマークアップは必要ありません - また、ページ上にある実際のメディアライブラリからの画像を見つけるときだけデータベースを問い合わせます。必要なのは、メディアライブラリにライセンス情報があることを確認し、Imageブロックを使用して画像を挿入することです。

これはCC Wordpressプラグインに類似した機能を追加する最初の試みではありませんでした。前の試みでは、[license]ショートコードで画像を囲んでいました - これは現在のWordpress Gutenbergエディタでは扱いにくいものでした。また、attachment_url_to_postidを使用してメディアライブラリ内で画像を見つけるために複数回データベースクエリを実行していました。

新しいアプローチでは、ユーザーは投稿を変更する必要がありません - プラグインをインストールし、メディアライブラリにクレジット情報を追加するだけで、通常の挿入画像に対して自動的に機能します。プラグインのインストール方法についてはこちらをご覧ください：

画像クレジット機能の使用方法についてはこちらをご覧ください：]]></description>
            <content:encoded><![CDATA[Centrum CyfroweのEUIPOからの資金提供を受けた#NoWorriesプロジェクトの一環として、私はCreative Commons Wordpressプラグインを強化する喜びを感じています。新しいバージョンのCC Wordpressプラグインには、「画像のクレジット情報」機能があります。これは次のようになります：Wordpressメディアライブラリに画像をアップロードし、正しいクレジット情報を入力します。次に、Image Gutenbergブロックを使用して画像をページに挿入します。その後、サイト上で画像が表示されるとき、プラグインは画像の下部に半透明のオーバーレイとして作者名、画像タイトル、ソースへのリンク、および使用されたCCライセンス情報を表示します。

この機能はどのように動作するのでしょうか？メディアライブラリから関連情報を取得するために、プラグインはGutenberg Image Blocksによってすでに提供されている情報を再利用しています。Wordpressでは、Imageブロックを使用して画像を挿入すると、wp-image-{id}という特殊なCSSクラスが追加され、その中にはメディアライブラリ内の画像の識別子が含まれます。これにより、特定の画像に個別のスタイルを追加できます - 私たちはこれを使用して関連するメディアライブラリのエントリーを見つけ、個別のクレジット情報を追加します。

このアプローチでは、カスタムマークアップは必要ありません - また、ページ上にある実際のメディアライブラリからの画像を見つけるときだけデータベースを問い合わせます。必要なのは、メディアライブラリにライセンス情報があることを確認し、Imageブロックを使用して画像を挿入することです。

これはCC Wordpressプラグインに類似した機能を追加する最初の試みではありませんでした。前の試みでは、[license]ショートコードで画像を囲んでいました - これは現在のWordpress Gutenbergエディタでは扱いにくいものでした。また、attachment_url_to_postidを使用してメディアライブラリ内で画像を見つけるために複数回データベースクエリを実行していました。

新しいアプローチでは、ユーザーは投稿を変更する必要がありません - プラグインをインストールし、メディアライブラリにクレジット情報を追加するだけで、通常の挿入画像に対して自動的に機能します。プラグインのインストール方法についてはこちらをご覧ください：

画像クレジット機能の使用方法についてはこちらをご覧ください：]]></content:encoded>
            <author>['rczajka']</author>
        </item>
        <item>
            <title><![CDATA[WordPress Base Theme Usage Guide (GSOD-2020): Hello World!]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-wp-base-theme-docs-intro/</link>
            <guid isPermaLink="false">urn:uuid:e8753062-5d8f-3a0f-a5b8-93d23e48f56d</guid>
            <pubDate>Wed, 30 Sep 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[私の名前はJacqueline Binyaです。私はジンバブエ出身のソフトウェア開発者兼テクニカルライターです。Google Season of Docs（GSOD-2020）の一環として、Creative Commons WordPress Base Theme(CC WP Base Theme)への貢献を通じて得た経験と教訓を記録するブログ記事のシリーズを書きます。Google Season of Docsとは？Google Season of Docsは、オープンソースドキュメンテーションの品質向上とオープンソース、ドキュメンテーション、技術ライティングに対する啓発活動を行う必要性から生まれました。毎年GSOD期間中、テクニカルライターがオープンソースプロジェクトに貢献するための高度なプロセスを通じて招待されます。その適合性が確認された後、GSODは再開します。ドキュメンテーションの作成CC WP Baseテーマは、Creative Commons (CC) サイトを作成するために使用されるWordPressテーマです。私の役割は、エンジニアリングチームと協力して、このテーマに対するコミュニティ向けドキュメンテーションを作成することです。ガイドラインドキュメンテーションは包摂的であるべきで、理解しやすい言葉遣いを心がけ、技術用語の過度な使用を避けること、アクセス可能であること、国際化に対応していることが求められます。ユーザーがドキュメンテーションを使用する際にスムーズで印象的な体験を得られるようにするために、ドキュメンテーションサイトは高速かつ簡単にナビゲートできるべきです。プロジェクトの技術スタック私たちはJamstackを使用してドキュメンテーションを構築することに決めました。具体的にはGridsome（Vuejs用の静的ジェネレーター）を使用しています。Gridsomeを選んだ理由は、パフォーマンスが高く、CC Vocabularyと滑らかに統合できるからです。また、Google AnalyticsやAngoliaなどの重要な機能をデフォルトでサポートしており、将来的なドキュメンテーションのイテレーションにおいて有用であることが予想されます。GridsomeテーマであるJamDocsを使用して、迅速にドキュメンテーションのスケルトンを作成しました。進行状況現在、プロジェクトは順調に進んでいます。私たちが協力してドキュメンテーションを作成していると述べた通りです。ワークフローにおける最初の一歩は、Google Docsでドラフトコンテンツを作成することです。このタスクは私に割り当てられており、多くのリサーチ、読書、そしてテーマのテストを含んでいます。その後、私のメンターであるHugo Solar氏とTimid Robot Zehta氏からドラフトに対するフィードバックを受けます。私はそのフィードバックに基づいて改善を行い続けます。最後の一歩は、承認されたドラフトコンテンツをMarkdown形式でドキュメンテーションプロジェクトに移行することです。これまでの教訓：常に質問をする：正直に言って、良いコンテンツを作成する唯一の方法は、主題についての深い理解を持っていることです。リモートでの作業では特に、コミュニケーションが十分であることが重要であり、ブロッカーに遭遇した場合でもなおさらです。コードをプッシュし、迅速にPRを開き、レビューを求めることで遅延を避けてください。これにより、フィードバックを得て改善を行うことができます。読んでいただきありがとうございます。次回の更新は近日中に投稿されます。]]></description>
            <content:encoded><![CDATA[私の名前はJacqueline Binyaです。私はジンバブエ出身のソフトウェア開発者兼テクニカルライターです。Google Season of Docs（GSOD-2020）の一環として、Creative Commons WordPress Base Theme(CC WP Base Theme)への貢献を通じて得た経験と教訓を記録するブログ記事のシリーズを書きます。Google Season of Docsとは？Google Season of Docsは、オープンソースドキュメンテーションの品質向上とオープンソース、ドキュメンテーション、技術ライティングに対する啓発活動を行う必要性から生まれました。毎年GSOD期間中、テクニカルライターがオープンソースプロジェクトに貢献するための高度なプロセスを通じて招待されます。その適合性が確認された後、GSODは再開します。ドキュメンテーションの作成CC WP Baseテーマは、Creative Commons (CC) サイトを作成するために使用されるWordPressテーマです。私の役割は、エンジニアリングチームと協力して、このテーマに対するコミュニティ向けドキュメンテーションを作成することです。ガイドラインドキュメンテーションは包摂的であるべきで、理解しやすい言葉遣いを心がけ、技術用語の過度な使用を避けること、アクセス可能であること、国際化に対応していることが求められます。ユーザーがドキュメンテーションを使用する際にスムーズで印象的な体験を得られるようにするために、ドキュメンテーションサイトは高速かつ簡単にナビゲートできるべきです。プロジェクトの技術スタック私たちはJamstackを使用してドキュメンテーションを構築することに決めました。具体的にはGridsome（Vuejs用の静的ジェネレーター）を使用しています。Gridsomeを選んだ理由は、パフォーマンスが高く、CC Vocabularyと滑らかに統合できるからです。また、Google AnalyticsやAngoliaなどの重要な機能をデフォルトでサポートしており、将来的なドキュメンテーションのイテレーションにおいて有用であることが予想されます。GridsomeテーマであるJamDocsを使用して、迅速にドキュメンテーションのスケルトンを作成しました。進行状況現在、プロジェクトは順調に進んでいます。私たちが協力してドキュメンテーションを作成していると述べた通りです。ワークフローにおける最初の一歩は、Google Docsでドラフトコンテンツを作成することです。このタスクは私に割り当てられており、多くのリサーチ、読書、そしてテーマのテストを含んでいます。その後、私のメンターであるHugo Solar氏とTimid Robot Zehta氏からドラフトに対するフィードバックを受けます。私はそのフィードバックに基づいて改善を行い続けます。最後の一歩は、承認されたドラフトコンテンツをMarkdown形式でドキュメンテーションプロジェクトに移行することです。これまでの教訓：常に質問をする：正直に言って、良いコンテンツを作成する唯一の方法は、主題についての深い理解を持っていることです。リモートでの作業では特に、コミュニケーションが十分であることが重要であり、ブロッカーに遭遇した場合でもなおさらです。コードをプッシュし、迅速にPRを開き、レビューを求めることで遅延を避けてください。これにより、フィードバックを得て改善を行うことができます。読んでいただきありがとうございます。次回の更新は近日中に投稿されます。]]></content:encoded>
            <author>['JackieBinya']</author>
        </item>
        <item>
            <title><![CDATA[curlコマンドを使用してクエリを追加し、レスポンスサンプルを提供]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/add-query-using-curl-command-and-provide-response-samples/</link>
            <guid isPermaLink="false">urn:uuid:f7441253-e7b7-3e14-86d5-b455887028de</guid>
            <pubDate>Fri, 25 Sep 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[まず最初に、Creative Commonsの下でGoogle Season of Docsの参加者として選ばれたことに感謝します。私のプロジェクト名は「CC Catalog API 使用ガイドの改善」です。このプロジェクトでは、既存のCC Catalog APIドキュメンテーションをより物語的な要素を含め、ユーザーが使いやすいものに改良することを目指しています。このプロジェクトの焦点となる部分は、GSOD期間終了前に提供される予定であり、同時に潜在的な貢献者向けのCC Catalog APIリポジトリドキュメンテーションも改善します。また、ドキュメンテーションへの貢献ガイドラインを作成する予定です。このプロジェクトでは、アドベン・ペイジがメンターを務めています。

第1週目：Google Season of Docsの最初の2週間が過ぎました。初週には、curlコマンドを使用してクエリを行うための例を追加しました。Forbiddenエラーで問題に直面し、アクセスキーが期限切れだったことが分かりました。新しいアクセスキーを取得したことで問題は解決しました。

第2週目：2週目に進み、レスポンスサンプルの作成を始めました。drf-yasg（Django Rest Framework APIからSwagger / OpenAPI 2.0仕様を作成する自動Swaggerジェネレーター）を理解するのが難しく、大変でした。drf-yasgがランダムな文字列ではなく、DRFがDjango Rest Frameworkを、YASGがYet Another Swagger Generatorを意味することに気づくのに時間がかかりました。

以上です！]]></description>
            <content:encoded><![CDATA[まず最初に、Creative Commonsの下でGoogle Season of Docsの参加者として選ばれたことに感謝します。私のプロジェクト名は「CC Catalog API 使用ガイドの改善」です。このプロジェクトでは、既存のCC Catalog APIドキュメンテーションをより物語的な要素を含め、ユーザーが使いやすいものに改良することを目指しています。このプロジェクトの焦点となる部分は、GSOD期間終了前に提供される予定であり、同時に潜在的な貢献者向けのCC Catalog APIリポジトリドキュメンテーションも改善します。また、ドキュメンテーションへの貢献ガイドラインを作成する予定です。このプロジェクトでは、アドベン・ペイジがメンターを務めています。

第1週目：Google Season of Docsの最初の2週間が過ぎました。初週には、curlコマンドを使用してクエリを行うための例を追加しました。Forbiddenエラーで問題に直面し、アクセスキーが期限切れだったことが分かりました。新しいアクセスキーを取得したことで問題は解決しました。

第2週目：2週目に進み、レスポンスサンプルの作成を始めました。drf-yasg（Django Rest Framework APIからSwagger / OpenAPI 2.0仕様を作成する自動Swaggerジェネレーター）を理解するのが難しく、大変でした。drf-yasgがランダムな文字列ではなく、DRFがDjango Rest Frameworkを、YASGがYet Another Swagger Generatorを意味することに気づくのに時間がかかりました。

以上です！]]></content:encoded>
            <author>['ariessa']</author>
        </item>
        <item>
            <title><![CDATA[詳細 - CCOSの刷新]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/the-specifics-revamping-CCOS/</link>
            <guid isPermaLink="false">urn:uuid:9fcf46c8-a613-316f-ab20-15a9292b490b</guid>
            <pubDate>Wed, 02 Sep 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[このブログでは、私たちのオープンソースウェブサイトでVocabulary（Creative Commonsのデザインライブラリ）を効率的に使用する方法について話します。Vocabularyとは何か？Vocabularyは、Web向けのCreative Commons全体を統一するための包括的な設計システムです。本質的には、Bulma CSSライブラリを使用して拡張されたコンポーネントライブラリと言えます。Vocabularyは、Creative Commonsアプリを開発しやすくするとともに、一貫した親しみやすい体験を確保します。このプロジェクトはまだ開発中です。

なぜVocabularyを使うのか？Vocabularyは、私たちのデジタル製品全体の視覚デザインを説明するために使用されます。見た目上では、一貫した視覚的な美学とブランドを持つコンポーネント設計の組み合わせであり、通常、オンラインドキュメント形式で利用ガイドラインが付属しています。しかし、それ以上のものがあります。

大きなソフトウェアコミュニティや製品範囲が広い場合、特定の問題が発生します。その一つは、ネットワーク内のすべての製品における調和レベルを維持することです。そのため、デジタルエコシステムでの調和レベルを高めるための一貫した視覚言語が必要となります。そして私たちの場合、Vocabularyがこの問題を解決しています。

このデザインシステムはよく構築されており、次のような要素を提供します - 認識性 一貫性 正直さ 効率性 そして他にも多くの利点があります。

どのように使用したか？ — 例
私はCCOS Lektorプロジェクトのすべてのテンプレートを更新してVocabularyを追加しました。コンポーネントに関しては、Vocabularyのウェブサイトで提供されているコードスニペットを貼り付けただけです。必要な変更も行いました。

また、Breadcrumb（パンくずリスト）やHeroセクションなどの他の視覚要素も広範に使用しています。このプロジェクトでは、Lektor Flowblocksを使用してサブテンプレートを作成し、それらを用いて単一のページを開発しました。

Vocabularyは非常に使いやすく、直感的で再利用性が高いです。Storybookを使用して各視覚要素が表示されるため、ユーザーがプロジェクトにVocabularyを統合するのがとても便利です。各要素に関連付けられたコードスニペットはそのままコピーして使用できます。

Vocabularyはまだ開発中であり、フィードバックやバグレポートの提供をお待ちしております。改善とパッチも歓迎します。貢献ガイドラインへのリンクを以下に示します。]]></description>
            <content:encoded><![CDATA[このブログでは、私たちのオープンソースウェブサイトでVocabulary（Creative Commonsのデザインライブラリ）を効率的に使用する方法について話します。Vocabularyとは何か？Vocabularyは、Web向けのCreative Commons全体を統一するための包括的な設計システムです。本質的には、Bulma CSSライブラリを使用して拡張されたコンポーネントライブラリと言えます。Vocabularyは、Creative Commonsアプリを開発しやすくするとともに、一貫した親しみやすい体験を確保します。このプロジェクトはまだ開発中です。

なぜVocabularyを使うのか？Vocabularyは、私たちのデジタル製品全体の視覚デザインを説明するために使用されます。見た目上では、一貫した視覚的な美学とブランドを持つコンポーネント設計の組み合わせであり、通常、オンラインドキュメント形式で利用ガイドラインが付属しています。しかし、それ以上のものがあります。

大きなソフトウェアコミュニティや製品範囲が広い場合、特定の問題が発生します。その一つは、ネットワーク内のすべての製品における調和レベルを維持することです。そのため、デジタルエコシステムでの調和レベルを高めるための一貫した視覚言語が必要となります。そして私たちの場合、Vocabularyがこの問題を解決しています。

このデザインシステムはよく構築されており、次のような要素を提供します - 認識性 一貫性 正直さ 効率性 そして他にも多くの利点があります。

どのように使用したか？ — 例
私はCCOS Lektorプロジェクトのすべてのテンプレートを更新してVocabularyを追加しました。コンポーネントに関しては、Vocabularyのウェブサイトで提供されているコードスニペットを貼り付けただけです。必要な変更も行いました。

また、Breadcrumb（パンくずリスト）やHeroセクションなどの他の視覚要素も広範に使用しています。このプロジェクトでは、Lektor Flowblocksを使用してサブテンプレートを作成し、それらを用いて単一のページを開発しました。

Vocabularyは非常に使いやすく、直感的で再利用性が高いです。Storybookを使用して各視覚要素が表示されるため、ユーザーがプロジェクトにVocabularyを統合するのがとても便利です。各要素に関連付けられたコードスニペットはそのままコピーして使用できます。

Vocabularyはまだ開発中であり、フィードバックやバグレポートの提供をお待ちしております。改善とパッチも歓迎します。貢献ガイドラインへのリンクを以下に示します。]]></content:encoded>
            <author>['dhruvi16']</author>
        </item>
        <item>
            <title><![CDATA[アクセシビリティと国際化: GSoC 2020 結果発表]]></title>
            <link>http://opensource.creativecommons.org/blog/entries/cc-search-accessibility-wrapup/</link>
            <guid isPermaLink="false">urn:uuid:850e5432-1654-3940-aec6-1caa4b24c66c</guid>
            <pubDate>Mon, 31 Aug 2020 00:00:00 GMT</pubDate>
            <description><![CDATA[これは私の CC インターンシップの最終ブログ記事です。私は cc-search のアクセシビリティ向上と国際化に取り組んでいます。このブログは、私の仕事の結論を述べています。過去10週間、CCでの経験から多くのことを学びましたし、このような機会を得ることができて本当に感謝しています。経験は素晴らしく、人々も非常に助けになり、彼らと一緒に働くのが楽しかったです。今後 CC チームと引き続き一緒に働きたいと思っています。私の仕事については、これらのブログ記事をご覧ください: CC Search, Proposal Drafting and Community Bonding CC Search, vue-i18n の設定とホームページの国際化 国際化継続: ストア内の文字列の処理 国際化継続: テストの変更 CC Search, 初期アクセシビリティ改善 アクセシビリティ改善: 最終的な変更とモーダルのアクセシビリティ。プロジェクトの進捗状況は cc-search で追跡できます。私の GSoC 2020 プロジェクトは、Zack Krida と Ari Madian（このプロジェクトの主なメンター）の指導のもとで行われました。また、Anna Tumadóttir とエンジニアリングディレクターの Kriti Godey のサポートも非常に大きかったです。]]></description>
            <content:encoded><![CDATA[これは私の CC インターンシップの最終ブログ記事です。私は cc-search のアクセシビリティ向上と国際化に取り組んでいます。このブログは、私の仕事の結論を述べています。過去10週間、CCでの経験から多くのことを学びましたし、このような機会を得ることができて本当に感謝しています。経験は素晴らしく、人々も非常に助けになり、彼らと一緒に働くのが楽しかったです。今後 CC チームと引き続き一緒に働きたいと思っています。私の仕事については、これらのブログ記事をご覧ください: CC Search, Proposal Drafting and Community Bonding CC Search, vue-i18n の設定とホームページの国際化 国際化継続: ストア内の文字列の処理 国際化継続: テストの変更 CC Search, 初期アクセシビリティ改善 アクセシビリティ改善: 最終的な変更とモーダルのアクセシビリティ。プロジェクトの進捗状況は cc-search で追跡できます。私の GSoC 2020 プロジェクトは、Zack Krida と Ari Madian（このプロジェクトの主なメンター）の指導のもとで行われました。また、Anna Tumadóttir とエンジニアリングディレクターの Kriti Godey のサポートも非常に大きかったです。]]></content:encoded>
            <author>['AyanChoudhary']</author>
        </item>
    </channel>
</rss>