不具合報告において一度「修正予定」となっていた案件が「仕様」に移された件について

[Kamone]

以前に『こちら』の不具合報告を行わせて頂いたのですが、詳細なログやスクリーンショットは無いのですが
私が目視で確認した限りでは以下のようなカテゴリの変更がありました。

2019/07/18：投稿
↓
2019/07/19：「受理済み」に移動を確認
↓
2019/08/31：「不具合確認・修正予定」に移動を確認
↓
2019/10/24：「仕様」に移動を確認

不具合報告をしたのはこれが初めてだった為、なんとなく成り行きを見届けたいと思い観察しておりましたが、このような事になるのは良くある事なのでしょうか？
不具合報告のガイドラインには下記のように記載されておりました。

７、調査／検証の結果、事象を再現できなかった場合は「再現せず」、不具合と判断した場合は「不具合確認・修正予定」、ゲーム上の仕様と判断した場合は「仕様」にそれぞれスレッドを移動します。

つまり一度不具合と認められた状態から、やはり仕様であったという旨で移動されているのであれば納得が行くのですが、そういった理由が明記されない状態で「不具合が仕様になる」と言う状況に若干もやっとしております。
私が報告した案件は、特にゲーム上支障が起きるような事ではないので修正されずとも困らないのですが他にもこういった案件があるのでは？と思いスレッドを立てました。

一つ一つ確認はしていないので分かりませんが、一度修正予定に入っていた状態から仕様に移されている案件がありましたら教えてください。

[Aji]

モルモリオンの製作レシピがおかしい
http://forum.square-enix.com/ffxiv/threads/266453

ちょうど4年前ぐらいになるけどたしかこれがそうだったと思う。

[male_player]

何年も前から修正予定の中で放置されてるものがある中で、
わざわざ「仕様ということにしとけばいいか」みたいな対処をする必要性はあまりない気がしますので、
単に最初不具合かと思って修正予定に入れたものの修正しようと開けてみたら実は仕様の影響だったことが発覚、
みたいなそんなんでは。あるいは担当者の確認不足とかそういう。

[Kamone]

前例があるとの事で、少し「仕様」にある報告をいくつか見てみましたところ、
確かに一見不具合のように見えるが、ゲームのプレイに大きな支障は出ない程度の案件がカテゴライズされているように思えました。

何年も前から修正予定の中で放置されてるものがある中で、
わざわざ「仕様ということにしとけばいいか」みたいな対処をする必要性はあまりない気がしますので、
単に最初不具合かと思って修正予定に入れたものの修正しようと開けてみたら実は仕様の影響だったことが発覚、
みたいなそんなんでは。あるいは担当者の確認不足とかそういう。

なんにせよモデレータからの回答がない限りは憶測でしか語れない為、これ以上は何とも言えないのですが、
もしこのような状況なのであれば「不具合確認・修正予定」というカテゴリーに移動するのは不適切だと思います。

一度「受理済み」の時点で案件を精査した上で「不具合確認・修正予定」に移動されているという前提ですが、
ユーザー視点で見れば「あれは不具合である」と判断した上でプレイする事になると思いますので、
Ajiさんのようなクラフターのレシピのような案件であれば「修正されてから製作しよう」と言う方も居られるかもしれません。

それ故にカテゴリーの移動に関して特に通知・確認する手段が意図的に用意されていないのかもしれませんが、
何かログが見れる仕組みがあれば良いなとは思いました。

[kuma-pandemo]

最終的に「仕様」に振り分けられたことで、
　「目に見えない高さで「飛行」している」
という仮説が正しかった、という回答が出たのだと思いますが。

という冗談半分なコメントはさておき、ご提示の件についていえば、仕様は仕様なんじゃないでしょうか。
普通に言えば、開発者観点から言えば、仕様にはおそらく大きく分けて二種類あって、
１：開発者から見て想定通りの動きである
２：設計通りでないが、直す気がない
というパターンがあります。

２かもしれないですけど、１であるとして、ほかに滑っているミニオンではどうなんでしょうか。
検索した感じ、プリンスペンギンとかもおなかで滑るようですが。

[Kamone]

最終的に「仕様」に振り分けられたことで、
　「目に見えない高さで「飛行」している」
という仮説が正しかった、という回答が出たのだと思いますが。

確かにそうですね。逆に喜ぶべきところなのか…。
この報告に関しては私も仲間内とたまたま気が付いて不具合報告したら修正されるかな？
程度のノリで投稿したのでそこまで重要視はしてないのですけれどね。

という冗談半分なコメントはさておき、ご提示の件についていえば、仕様は仕様なんじゃないでしょうか。
普通に言えば、開発者観点から言えば、仕様にはおそらく大きく分けて二種類あって、
１：開発者から見て想定通りの動きである
２：設計通りでないが、直す気がない
というパターンがあります。

仰るとおり私も「仕様」の定義についてはその2通りの認識です。
しかしながらガイドラインにそういった記載が無かった為、
どういった経緯と理由で「不具合」から「仕様」に移されたのか？という部分が少し気になった所でした。

そしてそれを知る術がユーザー側に存在しないのは致し方ないとしても、
仕様なのか不具合なのかを判断できる唯一の場所であるフォーラムにおいて、
言葉の定義が揺らいでしまってはユーザーも困惑しますよ、という事を言いたいだけです。
ですのでガイドラインに、「調査によってはカテゴリの再移動も有ります」という旨を追記していただけるだけでも
混乱は防げるのではないかなと言う思いもあります。

ペンギン…地味に取るの大変なので持ってないですね…。誰か検証して下さい。

[moch]

最終的か現状はなのかわからんけど仕様と判断したから仕様に移しただけなので、ガイドライン通りの扱いかと。

「不具合だと判断した後に仕様と判明した場合は仕様に移す場合があります」と書いた方がわかりやすいのかもしれませんね。

小学校の先生じゃないんだからそこまで細かく説明する必要があるのかと言われたら、ひとによっては必要なんじゃない？としか言えません

[Kamone]

最終的か現状はなのかわからんけど仕様と判断したから仕様に移しただけなので、ガイドライン通りの扱いかと。

「不具合だと判断した後に仕様と判明した場合は仕様に移す場合があります」と書いた方がわかりやすいのかもしれませんね。

小学校の先生じゃないんだからそこまで細かく説明する必要があるのかと言われたら、ひとによっては必要なんじゃない？としか言えません

細かすぎるかなとは私も思いつつも投稿しているのですが、せっかく不具合の報告を問い合わせフォームの形ではなく、
ユーザー全員の目に届くフォーラムと言う形で行っているのですから、
「受理済み」の時点で最終判断をして頂いた方が、見ている側も利用し易いのではないでしょうか。

もちろん今回の件が仮に確認不足によるミスによるものだったとしても「ミスをするな」と言っている訳ではありません。
開発チームやコミュニティチームの方々も日々大量のフィードバックを処理しているでしょうし難しい事は重々承知しております。

ですが、「不具合確認・修正予定」や「仕様」の過去ログを見た際に振り分けされた案件を眺めて、
「こういうものが不具合として受理されるのか」という参考になっている方が良いでしょうし、
それが気付かぬうちにカテゴリーが移動されていて「やっぱり仕様でした」では参考にはなら無いのではないでしょうか。
せめてやはり何か一文、移動したログをつけて頂くか、ガイドラインに明記があった方が良いと思われます。