From 6ef1fa4618e08426b874529619a66adbd3d1fcf0 Mon Sep 17 00:00:00 2001 From: Florian Merz Date: Thu, 11 Feb 2021 12:07:59 +0100 Subject: unslug ja: move --- files/ja/bugzilla-jp/guide/lifecycle/index.html | 33 ----------- .../bugzilla-jp/guide/lifecycle/mozilla/index.html | 65 ---------------------- .../guide/lifecycle/mozillagumi/index.html | 46 --------------- .../guide/lifecycle/qamozilla/index.html | 40 ------------- .../guide/lifecycle/webstandard/index.html | 56 ------------------- .../guide/lifecycle/webtools/index.html | 31 ----------- 6 files changed, 271 deletions(-) delete mode 100644 files/ja/bugzilla-jp/guide/lifecycle/index.html delete mode 100644 files/ja/bugzilla-jp/guide/lifecycle/mozilla/index.html delete mode 100644 files/ja/bugzilla-jp/guide/lifecycle/mozillagumi/index.html delete mode 100644 files/ja/bugzilla-jp/guide/lifecycle/qamozilla/index.html delete mode 100644 files/ja/bugzilla-jp/guide/lifecycle/webstandard/index.html delete mode 100644 files/ja/bugzilla-jp/guide/lifecycle/webtools/index.html (limited to 'files/ja/bugzilla-jp/guide/lifecycle') diff --git a/files/ja/bugzilla-jp/guide/lifecycle/index.html b/files/ja/bugzilla-jp/guide/lifecycle/index.html deleted file mode 100644 index 6ebe17962e..0000000000 --- a/files/ja/bugzilla-jp/guide/lifecycle/index.html +++ /dev/null @@ -1,33 +0,0 @@ ---- -title: LifeCycle -slug: Bugzilla-jp/Guide/LifeCycle ---- -

バグのライフサイクル

-

各バグはステータスによって状態を管理されています。ステータスには以下のものがあります。

-

UNCONFIRMED

-

通常のアカウントから報告された直後のバグの状態です。つまり、そのバグは未だに関係者によって再現が確認されていません。バグ報告としてはまだ成立していない状態ですので、再現しにくいバグの場合、報告者の助けが重要なウエイトを占めることがあります。もし、報告者の協力が得られない場合は、そのままバグを閉じられてしまうことも多々あります。

-

NEW

-

バグの存在が確認された状態です。UNCONFIRMEDの状態のバグがスタッフによって確認された場合にこの状態に変更されます。

-

また、スタッフや、canconfirm権限のあるアカウントで報告された場合は最初からこの状態になっています。

-

ASSIGNED

-

バグについて担当者が作業を開始した場合にこの状態に変更されます。担当者が行う作業はプロダクトごとに異なっています。詳しくは次ページ以降を参照してください。

-

RESOLVED

-

そのバグに対して何らかの決着がついたことを示す状態です。 一般的には、そのバグに対する作業が終了したことを示しています。 この時、同時に処理方法がFIXED、INVALID、WONTFIX、LATER、REMIND、WORKSFORME、DUPLICATEのいずれかに設定されます。DUPLICATE以外の処理方法の意味は、プロダクトによって異なってきますので、詳細はページ末尾からリンクしているプロダクトごとの解説を参照してください。

-

DUPLICATEとなった場合、そのバグは別の登録されているバグと同じものでした。報告者はこの時、同時に同じ内容だった別のバグへとCCされます。もし、重複が誤りであると思うのであれば、自分が報告した方のバグに何らかのコメントを付けてください。決して、この目的でもうひとつのバグの方にコメントを付けないように注意してください。

-

VERIFIED

-

RESOLVEDとなったバグに対して、 別のスタッフか報告者がその事実を確認した状態です。 この状態になっていれば、そのバグは完全に決着が着いた状態であると言えます。

-

REOPENED

-

VERIFIEDとなったバグが、実はまだ解決していなかったことが分かった場合にこの状態になります。この際に、設定されていた処理方法はリセットされ、空白に戻ります。

-

多くの場合、RESOLVEDになった時に設定された処理方法が適切ではなかった場合に、一度REOPENEDとなり、適切な処理方法を再設定して、RESOLVEDに戻すために利用されます。

-

バグの修正が不十分だった場合にREOPENEDになることもありますが、実際にはそれは希です。大抵、修正が不十分だった場合は別の問題が発覚したということなので、新たにバグが登録されるからです。

-

なお、一度修正されたバグが再発しても、REOPENEDにはなりません。バグの再発は異なる原因で再発していることが大半だからです。また、バグの担当者は既にBugzilla-jpでは作業していないかもしれません。このような場合、REOPENEDは適当な処理とは言えません。この場合も新たにバグを登録しなおすのが適当です。

-
-

ステータスはバグの管理において、最も重要な要素のうちのひとつです。Bugzilla-jpでの運用経験の少ないアカウントはこれを変更してはいけません。もし、ステータスが変更されるべきなのにスタッフ、もしくは開発者のミスで変更が行われない場合、コメントでその旨をスタッフに伝えて、スタッフの判断を待ってください。

-

プロダクトごとのより細かいライフサイクルと、処理方法の意味は以下のドキュメントを参考にしてください。

-
    -
  1. Mozilla関連製品に関するバグのライフサイクル
    2. -
  2. Web標準化プロダクトに関するバグのライフサイクル
    3. -
  3. Webtoolsプロダクトに関するバグのライフサイクル
    4. -
  4. もじら組のコンテンツに関するバグのライフサイクル
    5. -
  5. 談話室ばぐじらに関するバグのライフサイクル
    6. -
diff --git a/files/ja/bugzilla-jp/guide/lifecycle/mozilla/index.html b/files/ja/bugzilla-jp/guide/lifecycle/mozilla/index.html deleted file mode 100644 index 42631b17be..0000000000 --- a/files/ja/bugzilla-jp/guide/lifecycle/mozilla/index.html +++ /dev/null @@ -1,65 +0,0 @@ ---- -title: Mozilla -slug: Bugzilla-jp/Guide/LifeCycle/Mozilla ---- -

-

-

Mozilla関連製品に関するバグのライフサイクル

-

Mozilla関連製品のバグとは、Core、Firefox、Thunderbird、Camino、Mozilla Application Suite、Calendar、L10N(日本語化)プロダクトのバグのことを指します。 -

これらのプロダクトのステータスはTrunkでの開発状況を示します。これはBugzilla-jpで修正済みであるとされたバグであっても、次にリリースされる公式のビルドで修正されているとは限らないことに注意してください。 -

これらのバグで行われる作業とは、報告されたバグの確認とテスト、Bugzilla-orgの該当バグとの関連づけと、その追跡です。担当者はバグを修正するのではなく、そのバグの状態を追跡するのが仕事です。 -

処理方法の各意味は次のように定義されています。 -

-

FIXED

-

このバグはTrunkにおいて修正済みです。 -

-

WORKSFORME

-

このバグはTrunkにおいて再現しません。もしくは、報告者以外の環境で再現しませんでした。 -

-

INVALID

-

このバグはバグではありません(仕様通りです)。または、INCOMPLETE導入前のバグで、何らかの報告内容の不備により、妥当なバグ報告として成立しませんでした。(例えば、スタッフからの問い合わせに報告者が応答しませんでした。) -

-

INCOMPLETE

-

何らかの報告内容の不備により、妥当なバグ報告として成立しませんでした。(例えば、スタッフからの問い合わせに報告者が応答しませんでした。) -

-

WONTFIX

-

このバグはバグですが修正されません。標準仕様がまずい場合や、実装するとパフォーマンスが著しく低下してしまうような場合、修正が著しく困難な場合、要望が受け入れられない場合等に用いられます。 -

-

OBSOLETE

-

このバグは修正された訳ではありませんが、再現不可能になっています。バグが再現していた条件がサポート対象外となった場合や、設計変更等により、そのバグが発生していた要件が揃わなくなった場合に用いられます。 -

-

DUPLICATE

-

このバグは別のバグと同じ内容でした。 -

-

LATER

-

使用しません。 -

-

REMIND

-

使用しません。 -

-<hr> -

これらのプロダクトでは、担当の決定までのプロセスで、 -報告のされ方から三つのパターンが考えられます。 -

一つめは、Trunkの最新のNightly Buildで確認されたバグを報告されたものです。 -このバグは大抵の場合、すぐにスタッフによって確認が行われ、バグが確認されるとNEWになり、スタッフがBugzilla-orgから該当のバグを探す作業に入ります。Bugzilla-orgで該当のバグが発見されると、発見した人か、別のスタッフがバグの担当に就任し、ASSIGNEDとなり、Bugzilla-orgの該当バグの追跡を開始します。 -

もし発見できなかった場合は新たにBugzilla-orgにバグを報告し、報告者が担当に就任してBugzilla-orgの該当バグの追跡を開始します。 -

二つめは、最新のリリースビルドを使って確認されたバグを報告されたものです。このバグの場合、Trunkの最新のNightly Buildで再現確認が行われます。もし、再現した場合は一つめのケースと同様に処理されることになります。しかし、再現しなかった場合は少し面倒です。 -

まず、同じリリースビルドで再現するかどうかが確認されます。もし、ここで確認された場合、Trunkでは修正されているということで、Bugzilla-orgで該当の修正済みのバグを探すことになります。 -

もし、バグが見つかれば、Bugzilla-orgのバグがREOPENEDに戻らないか、監視するために誰かが担当に就任して、そのままRESOLVED FIXEDとなります。見つからなかった場合は、担当者不在のまま、RESOLVED WORKSFORMEとなります。 -

もし、リリースビルドでも再現できなかった場合は報告者とのやりとりによって、再現に努めることになりますが、適当な所で作業が打ち切られて、RESOLVED WORKSFORMEもしくは、RESOLVED INVALIDとなることもあります。 -

三つめは、Bugzilla-orgに報告されていて、再現するバグをBugzilla-orgのバグID付きで報告される場合です。この場合、報告者がそのまま担当に就任するか、スタッフが担当に就任し、ASSIGNEDとなります。 -

担当者によりバグの追跡が開始されると、多くの場合、そのバグの更新は修正されるまで停滞することになります。日本人開発者がそのバグの修正に取りかかった場合、日本人間でのディスカッションが必要ならそのバグで議論が行われますが、それは希です。 -

Bugzilla-orgの関連したバグで何らかの動きがあれば、担当者はその動きを報告してくれるかもしれません。しかし、担当者にその義務はありませんので、担当者次第です。リアルタイムに情報が欲しい場合は関連づけられたBugzilla-orgのバグを自分で追跡する必要があります。 -

Bugzilla-orgの該当バグがRESOLVEDになった場合、その結果によって以下の四つの対処が担当者によって行われます。 -

一つめは、Bugzilla-orgでFIXEDまたは、WORKSFORMEとなった場合です。この場合、担当者はバグのホワイトボードにBug-org [Bugzilla-orgのバグの番号] [FIXED|WORKSFORME]と、関連バグの処理結果をメモします。 -

そして、担当者、またはテストできる人間が、バグの修正、または、再現しないことを確認すると、Bugzilla-orgと同様の処理方法で、RESOLVEDとします。また、同時に、修正されたタイミングを明確化させるために、現在のTrunkのサイクルから適切な値をターゲットマイルストーンに設定します。 -

さらに別のスタッフ、もしくは報告者自身が修正を確認した場合、VERIFIEDとなります。 -

もし、修正を確認できなかった場合、関連づけていたBugzilla-orgとは関係なかった可能性があるので再調査となります。 -

二つめは、Bugzilla-orgでINVALIDまたはWONTFIXとなった場合です。この場合、担当者はバグのホワイトボードにBug-org [Bugzilla-orgのバグの番号] [INVALID|WONTFIX]と、関連バグの処理結果をメモし、その根拠となったコメントを要約(翻訳)して、その理由をBugzilla-jp上でも明記し、Bugzilla-orgと同様の処理方法で、RESOLVEDとします。さらに別のスタッフがその根拠を受け入れた場合、VERIFIEDとなります。 -

もしスタッフ以外でこの結果に納得できない人がいる場合、 -その人はスタッフに事情を説明して説得するか、 -直にBugzilla-orgの担当者と英語でディスカッションする必要があります。 -

三つめは日本人開発者がバグを修正した場合です。この場合、ホワイトボードに一つめの場合と同様の記述を行い、直ちにRESOLVED FIXEDとなります。これは、バグの修正課程において日本人の環境下でその修正がテストされているためです。 -

後に、別のスタッフが修正を確認するとVERIFIEDとなります。 -

四つめは関連づけていたBugzilla-orgのバグがRESOLVED DUPLICATEとなった場合です。この場合、担当者は新たに重複していた元のバグの監視を継続することになります。 -

diff --git a/files/ja/bugzilla-jp/guide/lifecycle/mozillagumi/index.html b/files/ja/bugzilla-jp/guide/lifecycle/mozillagumi/index.html deleted file mode 100644 index fa276563bf..0000000000 --- a/files/ja/bugzilla-jp/guide/lifecycle/mozillagumi/index.html +++ /dev/null @@ -1,46 +0,0 @@ ---- -title: MozillaGumi -slug: Bugzilla-jp/Guide/LifeCycle/MozillaGumi ---- -

-

-

もじら組のコンテンツに関するバグのライフサイクル

-

このプロダクトではもじら組内のコンテンツ全般のバグ報告を扱っています。 -

またBugzilla-jpの運用方針に関するディスカッションもコンポーネント:bugzilla-jpで行っています。 -

このプロダクトのステータスは問題とされたコンテンツのバグの修正状況や、ディスカッションの状態を示します。 -

処理方法の各意味は次のように定義されています。 -

-

FIXED

-

このバグは既に修正済みです。 -

もしくは、ディスカッションは決着しました。 -

-

WORKSFORME

-

このバグは現在再現しません。もしくは、報告者以外の環境で再現しませんでした。 -

ディスカッションでは使用されません。 -

-

INVALID

-

このバグはバグではありません(仕様通りです)。または、何らかの報告内容の不備により、妥当なバグ報告として成立しませんでした。(例えば、スタッフからの問い合わせに報告者が応答しませんでした。) -

ディスカッションの場合、提案は却下されました。 -

-

WONTFIX

-

このバグはバグですが修正されません。 -

ディスカッションの場合、提案の内容は的を射ていましたが、対応不能です。 -

-

OBSOLETE

-

このバグは修正された訳ではありませんが、再現不可能になっています。バグのあったページが削除された場合等に使用されます。 -

-

DUPLICATE

-

このバグは別のバグと同じ内容でした。 -

-

LATER

-

使用しません。 -

-

REMIND

-

使用しません。 -

-<hr> -

このプロダクトでは報告された内容がバグであると確認されるか、ディスカッションすべき内容であると確認されると、NEWとなります。 -

もし、バグではない場合や、的を射ていない提案の場合は、RESOLVED INVALIDに、バグが修正できないと判断された場合や、提案は実現不能と考えられた場合は、RESOLVED WONTFIXに、バグが再現しない場合は、RESOLVED WORKSFORMEとなります。そして、別のスタッフがこれに同意すれば、VERIFIEDとなります。 -

もし報告されたバグが修正可能で、担当者が作業を開始するとASSIGNEDとなります。ディスカッションの場合は誰かが議論の中心に立つ場合、担当者となりASSIGNEDとなります。 -

そして修正が完了、もしくは決着すると、RESOLVED FIXEDとなり、別のスタッフがそれを確認すると、VERIFIEDとなります。 -

diff --git a/files/ja/bugzilla-jp/guide/lifecycle/qamozilla/index.html b/files/ja/bugzilla-jp/guide/lifecycle/qamozilla/index.html deleted file mode 100644 index 360bef3837..0000000000 --- a/files/ja/bugzilla-jp/guide/lifecycle/qamozilla/index.html +++ /dev/null @@ -1,40 +0,0 @@ ---- -title: QAMozilla -slug: Bugzilla-jp/Guide/LifeCycle/QAMozilla ---- -

-

-

談話室ばぐじらに関するバグのライフサイクル

-

このプロダクトは他に適当なコンポーネントが無いディスカッションのために用いられます。 -

このプロダクトのステータスは話題の状態を示します。NEWもしくはASSIGNEDならまだ話題についての議論は続いているのでしょう。逆に、RESOLVEDやVERIFIEDならおそらく議論には決着が着いています。 -

処理方法は概ね次のような意味かもしれませんが、明確な定義はありません。 -そのバグの下の方のコメントを読んで、自分で判断するべきでしょう。 -

-

FIXED

-

この議論は決着したのかもしれません。もしくは、コメントが大量に付いたため、 -新たにバグを登録して、そちらでの議論に移ったのかもしれません。 -

-

WORKSFORME

-

おそらく使用されません。 -

-

INVALID

-

話題は的を射ていないことだったのかもしれません。 -

-

INCOMPLETE

-

その議論の提案者にしか判断できない議論なのに、提案者から応答が得られなかったようです。 -

-

WONTFIX

-

議論は決着が着かなかったのかもしれません。 -

-

OBSOLETE

-

議論の内容に意味がなくなったのかもしれません。 -

-

DUPLICATE

-

この話題は別のバグと同じ内容でした。 -

-

LATER

-

おそらく使用されません。 -

-

REMIND

-

おそらく使用されません。 -

diff --git a/files/ja/bugzilla-jp/guide/lifecycle/webstandard/index.html b/files/ja/bugzilla-jp/guide/lifecycle/webstandard/index.html deleted file mode 100644 index d08f2ff17a..0000000000 --- a/files/ja/bugzilla-jp/guide/lifecycle/webstandard/index.html +++ /dev/null @@ -1,56 +0,0 @@ ---- -title: WebStandard -slug: Bugzilla-jp/Guide/LifeCycle/WebStandard ---- -

-

-

Web標準化プロダクトに関するバグのライフサイクル

-

このプロダクトのステータスは問題のあるサイトの管理者とのコンタクト状況や、 -問題のサイトの修正状況を示します。 -

このプロダクトで行われる作業とは、報告された問題に関する仕様の調査と、修正方法(標準仕様に準拠した代替方法)の検討、問題のあるサイトへの修正依頼と、そのサイトの監視です。担当者は問題のあるサイトにコンタクトをとった人物で、サイトの監視義務はありません。 -

注意:このプロダクトに報告された問題は、報告された時にスタッフによりチェックされますが、(色々な意味で)興味深い問題ではなく、さほど公益性のあるサイトで無い場合には誰も担当しない可能性があります。 -

ただし、興味深い問題に関しては、Web標準普及プロジェクトや、Geckoそのものにフィードバックが行われることがあり、この場合、そのサイトが修正されなくても大きな意義があります。 -

処理方法の各意味は次のように定義されています。 -

-

FIXED

-

問題のあるサイトはGeckoに対応させるために修正してくれました。 -

-

WORKSFORME

-

問題のあるサイト、またはページが無くなりました。または、Geckoの仕様変更により、最新のリリースビルドで非標準への妥協があり、Geckoでのアクセスには問題なくなりました。 -

-

INVALID

-

INCOMPLETE導入前はINVALIDが代わりに利用されていましたが、現在は利用されていません。 -

-

INCOMPLETE

-

妥当な報告として成立しませんでした。 -

-

WONTFIX

-

問題のあるサイトにコンタクトを取りましたが、長期間に渡って反応がありませんでした。もしくは、問題のあるサイトから、修正しない旨の返事がありました。 -

-

OBSOLETE

-

使用しません。 -

-

DUPLICATE

-

この問題は既に報告されていました。(同一のサイトであることが条件です。) -

-

LATER

-

問題のあるサイトにコンタクトを取ったところ、後ほど(例えば、次のリニューアル時に)対応すると返事がありました。 -

-

REMIND

-

問題のあるサイトにコンタクトを取ったところ、検討するという返事がありました。 -

-<hr> -

このプロダクトでは報告があると、まず、 -発生している問題がWeb標準仕様に準拠していなためであることを確認します。 -もし、Geckoのバグが原因である場合はプロダクトが変更され、{{ mediawiki.external('Bugzilla-jp:Guide:LifeCycle:Mozilla|Mozilla関連製品に関するバグのライフサイクル') }}として処理されます。 -

サイト側の問題であることが確認されると、ステータスをNEWとして、次のように処理します。 -

まず、Web標準普及プロジェクトのWeb標準化Tipsに記載されている既知の問題の場合、ドキュメント内に原因や修正方法が既に記載されているので、サイトの管理者にそのドキュメントのURIを提示し、修正を依頼します。 -

Web標準化Tipsに記載されていない問題の場合、修正案を作成し、コメントに修正方法を記述するか、添付ファイルで差分を提出します。もし、別のスタッフに修正案を確認してもらう必要がある場合、差分を提出し、レビューを依頼します。そして、修正案が固まったら、サイトの管理者にコンタクトをとり、修正方法の提示と、修正依頼を行います。 -

修正依頼を行う相手は、サイト上に連絡先が明記されている場合には、その連絡先になります。連絡先が明記されていない場合で、ドメインを他のサイトと共有していないサイトの場合、WHOISサービスを使って、サーバの管理者を調べ、その管理者にメールでコンタクトを取ります。もし、他のサイトと共有しているサーバで連絡先が不明な場合はコンタクトを断念し、RESOLVED WONTFIXとなります。 -

サイト側とコンタクトを取ることに成功すると、その人が、担当に就任し、ステータスをASSIGNEDとします。 -

コンタクトをとった場合、サイトから返事が返ってくることがあります。 -この場合、その内容に従って必要ならステータスを変更し、 -処理方法に適切なものを設定します。 -

連絡が無い場合はそのサイトを適当に監視するしかありません。もし、サイトが更新され、問題に変化があった場合はその旨をコメントします。スタッフがそれを確認したら、適宜、ステータスを変更し、適切な処理方法でバグを閉じます。その後、別のスタッフによって再確認が行われると、VERIFIEDとなります。 -

もし、長期間に渡って問題が改善されず、不特定多数が利用する特にメジャーなサイトでは無い場合、RESOLVED WONTFIXとして監視を中断することもあります。 -

diff --git a/files/ja/bugzilla-jp/guide/lifecycle/webtools/index.html b/files/ja/bugzilla-jp/guide/lifecycle/webtools/index.html deleted file mode 100644 index d0c251cfd4..0000000000 --- a/files/ja/bugzilla-jp/guide/lifecycle/webtools/index.html +++ /dev/null @@ -1,31 +0,0 @@ ---- -title: WebTools -slug: Bugzilla-jp/Guide/LifeCycle/WebTools ---- -

Webtoolsプロダクトに関するバグのライフサイクル

-

このプロダクトは特殊で、コンポーネントによって異なります。このプロダクトにはBugzillaそのもののバグを取り扱うBugzillaコンポーネントと、Bugzilla-jpでカスタマイズしている部分のバグを取り扱うBugzilla-jpコンポーネントの二つがあります。前者については、Bugzilla.orgのプロダクトのバグのため、Mozilla関連製品に関するバグのライフサイクルと同じライフサイクルとなりますので、そちらを参考にしてください。このページでは、後者、Bugzilla-jpコンポーネントの場合についてのみ説明しています。

-

このプロダクトのステータスはBugzilla-jpのバグの修正状況を示します。

-

処理方法の各意味は次のように定義されています。

-

FIXED

-

このバグは既に修正済みです。

-

WORKSFORME

-

このバグは現在再現しません。もしくは、報告者以外の環境で再現しませんでした。

-

INVALID

-

このバグはバグではありません(仕様通りです)。または、INCOMPLETE導入前のバグで、何らかの報告内容の不備により、妥当なバグ報告として成立しませんでした。(例えば、スタッフからの問い合わせに報告者が応答しませんでした。)

-

INCOMPLETE

-

何らかの報告内容の不備により、妥当なバグ報告として成立しませんでした。(例えば、スタッフからの問い合わせに報告者が応答しませんでした。)

-

WONTFIX

-

このバグはバグですが修正されません。例えば、あまりにも巨大な修正が必要なバグは解決できません。

-

OBSOLETE

-

このバグは修正された訳ではありませんが、再現不可能になっています。バグが再現していた条件がサポート対象外となった場合や、設計変更等により、そのバグが発生していた要件が揃わなくなった場合に用いられます。

-

DUPLICATE

-

このバグは別のバグと同じ内容でした。

-

LATER

-

使用しません。

-

REMIND

-

使用しません。

-
-

このプロダクトでは報告された内容がバグであると確認されると、NEWとなります。

-

もし、バグではない場合は、RESOLVED INVALIDに、バグが修正できないと判断された場合は、RESOLVED WONTFIXに、バグが再現しない場合は、RESOLVED WORKSFORMEとなります。そして、別のスタッフがこれに同意すれば、VERIFIEDとなります。

-

もし報告されたバグが修正可能で、担当者が修正を開始するとASSIGNEDとなります。

-

そして修正が完了すると、RESOLVED FIXEDとなり、別のスタッフが修正を確認すると、VERIFIEDとなります。

-- cgit v1.2.3-54-g00ecf