ＳＲＣ意見交換掲示板Mk2 [One Topic All View / Re[4]: No.5511本文 / Page: 0]

ＳＲＣ意見交換掲示板Mk2
(現在過去ログ51 を表示中)

[ 最新記事及び返信フォームをトピックトップへ ]

■5511 / inTopicNo.1)

　提案：(本文別記)Wikiへの「SRC添付ヘルプ補足」追加　第2ツリー

□投稿者/ 中箱 -(2007/05/02(Wed) 03:06:53) [ID:8NrUE61r]

2007/05/07(Mon) 22:37:22 編集(投稿者)
2007/05/02(Wed) 03:10:18 編集(投稿者)
2007/05/02(Wed) 03:08:52 編集(投稿者)

※5/7夜、本文を別記した旨を追記※

どうも、中箱です。

前ツリーのレス数が限界に達しましたので二つ目のツリーを立てさせていただきました。

運用面での議論も必要なようですので、需要調査の件はしばらくの間延期ということで

今までの意見交換の詳細は
 http://www.src.jpn.org/neko/multibbs/cbbs.cgi?mode=all&namber=5483&type=0&space=0&no=1
を参照してください。

●
なお、個人的事情により親記事として提示するべき内容を整理する時間がとれませんので、とりあえずは

　親記事を作成して、レスを付けられる状態にしておくだけ、

ということにさせていただきます。

現状が把握し辛いかと思いますが、時間が取れ次第、この記事の本文は書き直しますのでそれまでまとめ文はお待ちいただければ助かります。
申し訳ありません。

※5/7夜追記。本文はNo.5532に別記しました。

●
以下、前ツリーで付け忘れたレスです
>あかんべえさんのNo.5507
＞　まず、需要調査について。反対ではないのですが、Wiki の活性化はどうしても、需要がはっきりつかめないまま有志が手探りで始めていかななきゃしょうがないという面もあるかと思います。

ツリーの比較的初期ですが、管理人の猫王さんから「需要と関心次第」との見解だったこと。
それに加えて、私自身がどこまで引っ張る気になれるか、の問題でもあります。
「声は聞こえないが、実際に動き始めれば黙ってついてくる人もそれなりに出てくるだろう」などと楽観的にはなれませんし。

ですから、
需要調査という形でもなお需要も関心も見られないと私自身が判断してしまった場合、
管理側からの承認があったとしても、勝手かとも思いますが提案自体を撤回することを考えています。

●
不十分な親記事でのツリー立てになってすいません。
遅くともＧＷ明けにはきちんとした内容のものに直せるかと。

引き続き、ご意見等ありましたらよろしくお願いします。
では。

引用返信/返信削除キー/

■5512 / inTopicNo.2)

　Re[1]: 提案：(本文仮)Wikiへの「SRC添付ヘルプ補足」追加　第2ツリー

▲▼■

□投稿者/ 乾＠汎用データ -(2007/05/02(Wed) 05:12:18) [ID:FGrzbgFn]

おはようございました。
乾＠汎用データです。

wikiの◆動作の項目ですが、これは

「ヘルプ・マニュアルに明記されていない（忘れていた・見落としていた）が問題なく動作する」物と
「将来の動作保証が出来ないためにヘルプ・マニュアルに記載をあえてしていない」物に分かれると思います、というか、分かれています。

　ここで、後者の方はいかにもお役立ちテクニックのように解釈されてしまうと
正直制作者の方としては、将来余計なバグ報告が来る、ユーザの方としても
突然バグが発生する等の不都合が起こることになると思われます。

　なので、動作の方は掲示板などで問い合わせて、問題がないかどうかを
確認する以前の物は「保証未確認動作」等、項目名だけで保証が明確でないことを
認識できる物にして欲しいと思います。

引用返信/返信削除キー/

■5517 / inTopicNo.3)

　Re[1]: 提案：(本文仮)Wikiへの「SRC添付ヘルプ補足」追加　第2ツリー

▲▼■

□投稿者/ axiom -(2007/05/03(Thu) 17:42:54) [ID:GQSzpbQo]
http://www.lilie.jp/itemworld/

axiomと申します。

ここまでの議論を興味深く拝見させていただきました。
ここにきてようやく、私の考えがまとまってきましたので、
議論に参加させていただきたいと思います。
以後、よろしくお願いします。

(1) 賛否について
　賛成です。
　各シナリオ作者が発見したノウハウを蓄積する場としては
　Wikiが最適かと思われます。

　私自身がそうなのですが、仕様じゃない動作でも
　動くなら使ってみたいと考えているシナリオ作者は
　実際に存在します。
　(当然、動作しなくなっても各シナリオ作者の責任なのですが)

　ただ、乾さんもご指摘のように　
　Wikiを見て、仕様でない動作をバグ報告されるという問題が
　起こりうるため、保証対象外動作ということは
　明記すべきだと思います。

(2) Wikiの枠組みについて
　試作掲載内容を拝見いたしました。
　ヘルプの各項目に対する補足説明という形式をとっており、
　枠組みとしてはこれで良いと思います。
　
　試作品には載ってませんが、実際にはWikiの頭に
　目次が自動作成されるため、検索性にも問題ないでしょう。

(3) 分類方法について
　分類が多すぎるのではないでしょうか？

　乾さんもご指摘していますが、分類としては
　　[1-a] 仕様だけどHELPから抜けてる (＝記述ミス)
　　[1-b] 公式見解では仕様だが、HELPに載せてない細かい仕様
　　[2] 動作保証対象外だけど、とりあえず動く (＝保証対象外動作)
　の３種類しかないわけです。

　　// 注記. 乾さんレスの前者に(1)を後者に(2)を対応させています

　以下、私の意見です。

　[1-a] 仕様だけどHELPから抜けてる (＝記述ミス)

　そもそもバグ報告掲示板に書くべき内容です。
　第一報としてWikiに記述することを禁止すべきではない気もしますが、
　HELPが修正されたときに必ず記事の削除が発生するという点を考慮すると
　分類から外したほうがいいのかもしれません。

　分類として設置するなら、バグ報告掲示板に報告するよう
　誘導する注意書きが不可欠でしょうし、
　運用してみてWikiにだけ書き込む事例が多いのならば、
　禁止するという方向もやむを得ないと思います。

　分類名称はご提案どおり「◆記述ミス」で良いでしょう。

　[1-b] 公式見解では仕様だが、HELPに載せてない細かい仕様

　中箱さんが例として挙げた
　ハードポイントLv4＝ハードポイントLv1 x4 のような
　公式見解だが、HELPに掲載してない(できてない?)細かい仕様を
　想定しています。

　こちらの方は文章としてどこかに残しておかないと
　そのうち、うやむやになってしまう恐れがあるので、
　どこかに掲載する必要があるでしょう。

　もし、公式見解をすべてHELPに掲載可能であれば、
　この分類は不要となるのですが、労力的・容量的に難しいのでは
　ないでしょうか。

　この項目については、Wikiである必然性は感じませんが、
　上記の理由から、Wikiに含めるべきであると考えます。

　分類名称はご提案どおり「◆仕様」で良いでしょう。

　[2] 動作保証対象外だけど、とりあえず動く (＝保証対象外動作)

　私が最も関心の高い部分です。
　現状、こういった情報を共有する場がないため、
　SRC-Wikiのコンテンツとして設置していただければ、
　シナリオ作者サイドとしましても、大変重宝すると思います。

　性質上、掲載される情報は各シナリオ作者が保有しているため
　Wikiという方式が最も適しています。

　分類名称は仕様との区別を明確にするために
　「◆保証対象外動作」が良いと思います。

(4) 運用について
　現在、Wikiの利用状況が芳しくないのは
　　・そもそも「よくある質問集」に追加すべき内容が少ない
　　・編集するネタが多そうな「シナリオ作成応用編」が
　　　受付していないと公言されている
　　・サンプルが少ないので、編集してよいものか悩む
　　・そもそも、情報提供者がWikiの書き方に慣れてない
　　・サンプルが少ないから、既存の記事をコピペして使いづらい

　といったような理由が考えられます。

　現状を打開するためには、記事の増加が必須となるでしょう。
　Wikiではないですが、私がむかし一行掲示板を用語集として
　運用していた時に、一般からの書き込みが出てきたのは
　記事数が10～20程度に増えたときだったと記憶しています。
　当面は、有志による運用が必要でしょう。

　まずは「シナリオ作成応用編」の編集を解禁すると
　アナウンスすることが必要と思われます。

(5) 需要について
　幸い、保証対象外動作については、
　手持ちの情報が数十件ありますので、ご協力できると思います。

　ただ、こういったものをWikiに載せたところで
　リスクを背負ってまでシナリオに採用する作者がどれぐらいいるかは
　調査してみないと、判断がつきかねると思います。

以上、長文失礼いたしました。

引用返信/返信削除キー/

■5518 / inTopicNo.4)

　本筋と関係ない部分ですが

▲▼■

□投稿者/ 猫王＠管理 -(2007/05/03(Thu) 18:13:01) [ID:vVKpjjUl]

猫王です。

>　　・編集するネタが多そうな「シナリオ作成応用編」が
>　　　受付していないと公言されている

この部分ですが、応用編は実は受け付けています。

応用編は、よくある質問集の一部であると考えていたので、
よくある質問集だけを受け付けていると注意書きに書いていたのですが、
左側のメニューを見ると、確かに応用編は別項目である様にも見えますね。

注意書きを修正して分かりやすくしておこうと思います。

引用返信/返信削除キー/

■5523 / inTopicNo.5)

　Re[1]: 提案：(本文仮)Wikiへの「SRC添付ヘルプ補足」追加　第2ツリー

▲▼■

□投稿者/ 小一郎 -(2007/05/04(Fri) 23:56:05) [ID:S6yWlcX9]

前ツリーのレスです。

> では、精度の高いものを得るためには、何が必要だとお考えでしょうか？

中箱さんの決断です。

どうも中箱さん自身、Wikiの設立の提案はするが、運営には関与しない…という
印象を持ちます。簡単に言えば他人任せだと。

それゆえ中箱さんが管理運営の責任を持つ、と明言されれば安心して後は
お任せできます。無論、永続しなくてもよく過去にあった様々なコーナー
の様に寿命は管理者次第でも良いと思います。

小一郎

引用返信/返信削除キー/

■5524 / inTopicNo.6)

　Re[3]: 本筋と関係ない部分ですが

▲▼■

□投稿者/ axiom -(2007/05/05(Sat) 10:31:26) [ID:GQSzpbQo]
http://www.lilie.jp/itemworld/

axiomです。

今、自分のレスを見返してみると
けっこう強い書き方になってしまって、
ちょっと反省…。

文章で意図を伝えるのは、なかなか難しいものですね。

> 猫王さん

早速の注意書き更新ありがとうございました。
トピックが分かれていたので、何か意図があって
凍結していたのかと勘違いしておりました。

時間が空いたときにでも、記事の数を増やしておきます。

引用返信/返信削除キー/

■5528 / inTopicNo.7)

　小一郎さんの提案内容確認と意見

▲▼■

□投稿者/ あかんべえ -(2007/05/06(Sun) 08:39:32) [ID:85QBhDu0]

　ども、あかんべえです。

　小一郎さんのご提案についてですが、その趣旨は以下の二つのうちどちらでしょうか？

１．ご提案に至る話の流れは、No.5509 での小一郎さんの
> 現時点ではWikiの関心の低さが懸念されています。それゆえ情報が正しく修正されるかは
> 未確定で、どちらかと言えば不安要素です。

以下のご発言があり、それを受けて中箱さんが
> では、精度の高いものを得るためには、何が必要だとお考えでしょうか？

と発言されたことに応じご提案されたものだと思います。
　この話の流れからは、「Wiki 項目の内容の精確さへの保証」を求めるご提案のように見えます。

２．しかし、ご提案発言 No.5523 本文で小一郎さんは「管理運営の責任」に見える表現をされています。
　「内容の精確さへの保証」と「管理運営」はまったく別のことがらで、実際、Wikipedia など一般の Wiki の管理者はたいてい、
(1) 編集合戦など、書き込み者どうしの争いのとりまとめ
(2) 項目の分割・合同など Wiki（または担当の項目）全体の整理
つまり「管理運営」をしていますが、「内容の精確さ」には直接かかわってはいません。

　小一郎さんが意図されているのは、このどちらでしょうか。

　以下は、そのそれぞれへの意見です。

１．もし、「内容の精確さへの保証」を求められるのであれば、要は Wiki の内容を気にかけしばしば加筆・修正する人々がいればいいわけで、中箱さん個人が運営責任者として名乗りをあげなくてもかまわないと思います。というか、多人数が書くことに内容の充実を求めるのが Wiki、内容保証を特定個人に依存するようだと Wiki として失敗状態です。
　その上で、どうしても「内容の精確さ」にかかわる宣言をする人がいないと不安だと言われるなら、中箱さんならずとも私自身も、以後 Wiki の内容を日常的にチェックし気づいたことは加筆･修正していこうと思っています。
　さらにもし、小一郎さんがそれ以上をお求めで「誰かが Wiki の全内容に責任を持つ」ということなら、無理な要求だと思います。知恵や経験を寄せ合ってこその Wiki であり、内容が特定個人に担保しえる範囲内でおさまるものと想定できない、しちゃならないからです。

２．もし文字通りの「管理運営責任者」をお求めであるなら、中箱さんとあかんべえがすでに意見を出しています。まだ適切な形態がわかるわけもないから時期尚早、という意見です。
　その上でなお、「管理運営責任者が必要」と主張されるのであれば、反対意見とその理由以上に優先されるべき根拠を明らかにされるようお願いいたします。ご提案は上述のように「内容の精確さ」の話の流れに乗ったものであり、「管理運営」という面からはなに一つ論拠が示されていないとお見受けしますので。

引用返信/返信削除キー/

■5531 / inTopicNo.8)

　色々レス

▲▼■

□投稿者/ 中箱 -(2007/05/07(Mon) 17:55:52) [ID:8NrUE61r]

どうもお待たせいたしました、中箱です

●●
>乾さん
＞　なので、動作の方は掲示板などで問い合わせて、問題がないかどうかを
＞確認する以前の物は「保証未確認動作」等、項目名だけで保証が明確でないことを
＞認識できる物にして欲しいと思います。

では、編集方針としては
「◆動作」ではなく、「◆保証未確認動作」とするということで

●●
>axiomさん
＞ここまでの議論を興味深く拝見させていただきました。
＞ここにきてようやく、私の考えがまとまってきましたので、
＞議論に参加させていただきたいと思います。
＞以後、よろしくお願いします。

レスありがとうございます。こちらこそあまり上手くないまとめ役かと思いますがよろしくお願いします。

●
＞(1) 賛否について
＞(略)
＞　Wikiを見て、仕様でない動作をバグ報告されるという問題が
＞　起こりうるため、保証対象外動作ということは
＞　明記すべきだと思います。

注意書きのページに凡例のような形で解説しておけばいいかな、と思っていましたが、
やはり、より安全を期すためには分類名で分かった方が良いですね。
上にも書きましたが、乾さんが提案されたまま　◆保証未確認動作　を使おうと思います。

●
＞(2) Wikiの枠組みについて
＞(略)
＞　試作品には載ってませんが、実際にはWikiの頭に
＞　目次が自動作成されるため、検索性にも問題ないでしょう。

試作品は頭に
>#実際のWikiには、記事上部にページ内リンクが自動生成されるハズです。
とだけ書いて、
ぶっちゃけ手抜きしましたスイマセン(^^;

●
＞(3) 分類方法について
＞　分類が多すぎるのではないでしょうか？
＞　乾さんもご指摘していますが、分類としては
＞　　[1-a] 仕様だけどHELPから抜けてる (＝記述ミス)
＞　　[1-b] 公式見解では仕様だが、HELPに載せてない細かい仕様
＞　　[2] 動作保証対象外だけど、とりあえず動く (＝保証対象外動作)
＞　の３種類しかないわけです。

こちらの想定している◆記述ミス　の内容について誤解があるようです。

[1-a]に関しては
＞そもそもバグ報告掲示板に書くべき内容です。
のような内容は対象にしません。

「本来はバグ報告板等に行くべき内容がWikiに来てしまったらどうするか」は考える必要があるとは思いますが、
記述内容としてはあくまでも「実害の無い誤字や記述抜け」のみが対象です。

分類名が「記述ミス」で紛らわしいようでしたら･･
んー、「微細記述ミス」　とか、「誤字」とかの方がたいしたこと無い感が出ますでしょうか？

現在の分類としては
　◆記述ミス（実害の無い誤字や記述抜け）
　◆仕様（axiomさんの分類では[1-b]に該当）
　◆注意
　◆動作　改め　◆保証未確認動作（[2]に該当）

　◆　　（未分類の記事）

の5種類を考えていますが、多いでしょうか？

これらのうち　◆記述ミス　に関しては、
>バグ報告掲示板に「ヘルプの細かい記載ミス報告でもＯＫ」というような旨の注意書きが追加される場合は利用目的から外す
としています。

未分類記事・◆仕様・◆保障未確認動作　は必要でしょうし、
残る◆注意　についても、

>○利用目的３：各コマンドなどの使用例・記述例とその動作、類似能力との仕様の違いについての注意書き。
>※例えば、
>　Info関数の記述例とその返り値の実例。
>　プロテクション能力項に、実例を挙げたレジスト能力との違いの説明（この場合はレジスト項にも同様の記述）
>など

のような内容を想定しているので、他の分類に含めるのも違うかなと。

●
＞(4) 運用について
＞(略)
＞　現状を打開するためには、記事の増加が必須となるでしょう。
＞(略)
＞　当面は、有志による運用が必要でしょう。

稼動初期にどれだけの記事を載せられるかが大事になるんだろうな、とは。
同時に、初期は特にこまめな記事メンテが必要でしょうね。

●●
>猫王さん
＞応用編は実は受け付けています。

そうだったんですか、すいません、了解しました。

●●
>小一郎さん
＞どうも中箱さん自身、Wikiの設立の提案はするが、運営には関与しない…という
＞印象を持ちます。簡単に言えば他人任せだと。

そうですか。
理由がどこにあるにせよ、小一郎さん個人がそういう印象を持たれていることは承知しました。
今後のレスに生かしたいと思います。

＞それゆえ中箱さんが管理運営の責任を持つ、と明言されれば安心して後はお任せできます。

明言いたしませんし、
お任せできます言ってくれるのが、ハナからWikiの編集に携わる気自体が無さげな発言を繰り返している小一郎さんでは、かえって迷惑というものでしょう。

●●
親記事本文の書き直しについてですが、
すでに結構な数のレスが付いてしまっているので、親記事の編集ではなく、一つのレスとして書く事にしようと思います。
今回のレスも含めた内容になりますので、その方が分かりやすいでしょうし。

提案内容のまとめは今日の夜には出せるかなと。
では

引用返信/返信削除キー/

■5532 / inTopicNo.9)

　No.5511本文

▲▼■

□投稿者/ 中箱 -(2007/05/07(Mon) 22:35:26) [ID:8NrUE61r]

No.5511の本文、現時点での提案内容のまとめになります。
（～5531までのレスを反映した内容になっています）

抜けなどがあったらご指摘ください。

●Wiki項目への「SRC添付ヘルプ補足」追加提案
についての意見交換を行っています。

●
「ヘルプ補足」は、以下のようなものとして考えています。

○利用目的１："実害の無い"　誤字や記載ミスの類をまとめる

　・修正が必要な各種バグ（現在、各バグ報告掲示板で）の報告は、現状通り各掲示板で行う。変更は求めない。
　・かつ、このような類のものはWikiの記事としては扱わない

　※ただし、バグ報告掲示板に「ヘルプの細かい記載ミス報告でもＯＫ」
　　というような旨の注意書きが追加される場合は利用目的から外す

　・利用目的から外す場合も、
　　「各管理人・作者に確実に伝えたい事柄については、該当する掲示板やメールなどを使うように」
　　という旨の注意書きや、掲示板への誘導リンクを設置しておく。

○利用目的２：バグ報告に対するレス中で「仕様である」との見解が示されたものの記録

　・バグ報告掲示板のログが100件しかないため、過去に示された見解が参照できなくなることを防ぐため。
　・将来、ログが残るように掲示板が設定変更された場合も、Wikiへの記録は継続する。
　　（掲示板の過去ログを検索するよりも、Wikiの該当する場所に記録しておいた方が参照しやすいかと）

○利用目的３：各コマンドなどの使用例・記述例とその動作、類似能力との仕様の違いについての注意書き。

　※例えば、
　　　Info関数の記述例とその返り値の実例。
　　　プロテクション能力項に、実例を挙げたレジスト能力との違いの説明（この場合はレジスト項にも同様の記述）
　　など

○利用目的４：仕様であるかどうかは不明だが、問題なく動作しているものを、
　「仕様確認されておらず、保障されていない動作である」ことを明記した上で掲載する。

　・動作確認されたバージョンを明記・追記する

　＊：過去に仕様確認が行われたが、回答が無かった事について掲載するべきかどうか？

○その他

　・開発版で実装されている新機能に関連する内容は原則として掲載しない。

　＊：記事の編集合戦などが起こり情報が混乱した場合、その対応や処置をどうするべきか、を現段階で検討しておくべきか？
　　※Wikiへの項目追加が行われた後で良いと言う意見と、検討しておくべきだと言う意見、共に出てはいます。

　＊：現段階で、あらかじめ専任管理人のような人間を設置しておくべきか？
　　※立候補者がいるのであれば、設置すること自体には問題無いと考えています。

　＊：表現次第で「ヘルプ補足」と「シナリオ作成～編」のどちらにも記述できるものについてはどうするか？
　　※両方に記述した場合はメンテナンスの必要が生じた時に手間が増すが、片方にのみ記述した場合は参照性が低下する。
　　　記事本文は片方にのみ記述し、もう片方からは誘導するだけ、にした方が良い？

　＊：検証用のデータ＆シナリオを用意しておけば以後の動作確認の手間が大幅に減ることは予想できるが、
　　　その分、そのデータ＆シナリオを準備する手間がかなり大きいので現実的ではない、と思う･･･。

●
記事構成枠組み案

項目の分類は、ヘルプの各項目に対する補足説明、という形式をとります。
（そのため、基本的にQ&A形式で書かれている「シナリオ作成応用編」等とは視点が異なるものとなります）

ただし、項目は必要に応じて増やしてもＯＫ
　例：[命中率に関連するもの] というタイトルで、
　　　特殊能力や状態の項目へのリンク集的なページを作る

完成した各記事には、その内容に応じて

　◆誤字
　　　　目的１に該当。実害が無さそうであれば、記述抜けなども含む
　　　　（実害がありそうなものは原則記述しない）
　◆仕様
　　　　目的２に該当。公式見解では仕様だが、HELPに載せてない細かい仕様。
　　　　（ヘルプから充分に読み取れる内容であれば　◆注意　に含める）
　◆注意
　　　　目的３に該当。例の追加や、関連項目の事情も合わせた説明
　　　　（ヘルプからだけでは読み取れないものは　◆仕様　か　◆保証未確認動作　に含めること）
　◆保証未確認動作
　　　　目的４に該当。動作保証対象外だけど、とりあえず動くもの。
　　　　（普通は役に立たない情報はどうするか、という問題もあるかもしれない。(能力の最大値云々とか)）

　◆　　（未分類）
　　　　書きかけであったり、上記のどれに該当するのかの調査が不十分であったりするもの。

という分類表記を付けることとします。

動作確認した本体バージョンや仕様であると見解が示された時期も、記事に合わせてできるだけ掲載することに。

未完成の記事であっても、未完成だと分かるように書いてあれば、分類表記が付いていてもOKということで。

　※レイアウトなどの詳細については、記述例ページを作成した後に
　　よりわかりやすく、かつ編集者にとって敷居が高くならないようなものを目指して試行錯誤することになるかと。

●
以上のような内容での提案となっています。

既存意見への賛否含めて、ご意見等何かありましたらよろしくお願いします。

では。

引用返信/返信削除キー/

■5533 / inTopicNo.10)

　細かな意見いくつか

▲▼■

□投稿者/ あかんべえ -(2007/05/08(Tue) 07:31:53) [ID:wKVMCYX0]

2007/05/09(Wed) 20:59:43 編集(投稿者)
2007/05/09(Wed) 17:30:27 編集(投稿者)
2007/05/09(Wed) 17:28:56 編集(投稿者)
2007/05/09(Wed) 17:28:46 編集(投稿者)

　中箱さんご苦労さま、あかんべえです。
　提案内容のまとめ、基本的に賛成です。以下は、細かな部分の意見にすぎません。

> 　＊：表現次第で「ヘルプ補足」と「シナリオ作成～編」のどちらにも記述できるものについてはどうするか？
> 　　※両方に記述した場合はメンテナンスの必要が生じた時に手間が増すが、片方にのみ記述した場合は参照性が低下する。
> 　　　記事本文は片方にのみ記述し、もう片方からは誘導するだけ、にした方が良い？

　SRC Wiki では、被参照箇所にアンカーをつけ参照箇所からリンクすることが手軽にでき、かつ、読み手がかんたんにジャンプすることができるので参照性はそれほど低下しないと思います。なので、「片方」を心がけたほうがより良いかと。
　でもまあ、こういうことは書き手によって、両方書く人、片方の記述に気がつかずに他方に書き込む人とか出てくることは必至で、実際の書き込み情況を見ながら柔軟に対処していったらよいと思います。

> ◆保証未確認動作
> 　　　　目的４に該当。動作保証対象外だけど、とりあえず動くもの。
> 　　　　（普通は役に立たない情報はどうするか、という問題もあるかもしれない。(能力の最大値云々とか)）

5/09 夕刻編集――以下、"###"までの意見は撤回します。お騒がせしましたm(._.)m
　情報として大事なのは、“Keiさんの保証宣言が出てない”ということにあり“第３者による確認の有無”ではないので、「保証未確認動作」という表現には多少違和感があります。「保証外動作」ではどうでしょうか。たいしてこだわるわけではありませんけど。
###
　撤回の理由は、“あえて保証の明言はさらていないけれど、SRC の基本動作にかかわること”なども項目に含まれるからです。たとえば、「変数に他の変数やサブルーチンの名前を入れれば、その内容が呼び出される」ということはHELPに書いていませんが、「変数による呼び出し」というとても基本的な事項にかかわり、「保証外」と言い切ってしまうのは気が引けます。

　それから、「普通は役に立たない情報」という制限は考える必要ないと思います。
　どういう情報が「普通は役に立たない」と思うかは人それぞれ違うので、この種の制限は書き込みを抑制する心理につながってしまうことが一つの理由です。
　また、＜普通は＞役に立たない情報が、価値が低い情報では必ずしもないとも思います。たとえば、能力の最大値目いっぱい近くまで使うようなシナリオが作られたとします。このシナリオはたしかに「普通」ではありませんが、しかし、ＳＲＣの可能性を広げるという大きな価値を持ちます。したがって、Wiki のほうでも、ＳＲＣの機能が目いっぱい使われる可能性を想定しておきたいと思うのです。

引用返信/返信削除キー/

■5534 / inTopicNo.11)

　保証未確認動作という項目

▲▼■

□投稿者/ 乾＠汎用データ -(2007/05/10(Thu) 00:00:10) [ID:FGrzbgFn]

乾＠汎用データです。

「保証未確認動作」という項目名を挙げたのには実は意味がありまして
開発者に仕様として認識していいのかどうか「未確認」の状態である。
　って、意味を強調したかったのです、で、ついでに言えば、
少なくとも汎用戦闘アニメに関しては、面白い動作の物を見つけたら、
積極的に汎用データ掲示板で「確認」を取って欲しいのです。

　仕様として維持する価値がある使い方をしていれば、それを意識して
開発が行えますし、あるいは、もっと便利な形に手直しして
正式な機能として提供する事もできるかもしれませんので。

（余談ですが、ＳＲＣの汎用戦闘アニメ自体がそういった
仕様の確認を私がKeiさんに問い合わせた過程で生まれた物だったりします）

　もちろん、将来動作を保証する事が出来なさそうなものや、他の方法で
行った方が良い組み合わせなども出てくる可能性も大きいので、
「未確認」状態の物は保証できない、というのも重要部分なのですが、
使えない機能と言うより、使えるようになる機能の洗い出しに
役立てるカテゴリであって欲しいな　と思う次第です。

引用返信/返信削除キー/

■5535 / inTopicNo.12)

　Re[2]: No.5511本文

▲▼■

□投稿者/ 中箱 -(2007/05/10(Thu) 19:33:27) [ID:8NrUE61r]

どうも、中箱です
No.5532のまとめにいくつか挙げた「？」付きの点について、私個人の意見を出していないことに気付きました＾＾；

特に意見が付かないまま議論自体が収束した場合は、以下の私の意見を提案に盛り込ませていただきます。

●
＊：過去に仕様確認が行われたが、回答が無かった事について掲載するべきかどうか？

今後行われた仕様確認の結果は掲載するが、
過去のものを掲載する場合は「明確なソースの無い情報」だということを必ず明示したうえで行う。

●
＊：記事の編集合戦などが起こり情報が混乱した場合、その対応や処置をどうするべきか、を現段階で検討しておくべきか？
＊：現段階で、あらかじめ専任管理人のような人間を設置しておくべきか？

項目の追加が行われた後に、
状況や需要に応じて、必要だと判断した方の主導により意見交換掲示板などで改めて議論を行う。

●
＊：表現次第で「ヘルプ補足」と「シナリオ作成～編」のどちらにも記述できるものについてはどうするか？

「片方を基本とする」だけで、現段階ではそれ以上明確な規制は設けない。

●
＊：検証用のデータ＆シナリオを用意しておけば以後の動作確認の手間が大幅に減ることは予想できるが、
　　その分、そのデータ＆シナリオを準備する手間がかなり大きいので現実的ではない、と思う･･･。

目に見える形での記述は避けるが、コメントアウト中でテスト用の記述は推奨する。
（Wikiだけでは必要なファイルを一まとめにしたテストシナリオの添付は行えないので現実性に欠ける。
　なので、もしやるとしても、必要な情報をコメントアウトの形で記述しておくようにする程度が限界かだと思うし）

●●
また、旧◆動作　こと◆保証未確認動作　の名称についてですが、

乾さんの意図(No.5534)への積極的な反対意見がなければ、
　◆保証未確認動作
を用いることにしたいと思います。

以下、軽くレスです

●●
>あかんべえさん

＞> 　＊：表現次第で「ヘルプ補足」と「シナリオ作成～編」のどちらにも記述できるものについてはどうするか？
について

私の意見は上にも書きましたが、基本的に対立するものではないようですから
反対意見が出なければ
「基本は片方。両方に書いてある場合は適時適当に対応しましょう」ぐらいで。

＞「普通は役に立たない情報」という制限は考える必要ないと思います。

では、制限するべきだという意見が出なければ制限しない方向ということに。

※なお、明らかに脇道とはなりますが、
＞「変数に他の変数や関数の名前を入れれば、その内容が呼び出される」ということはHELPに書いていません
についてですが、

"変数に他の変数や関数の名前を入れ"ることは　Setコマンド　であり、
ヘルプの「式」項に
>イベントコマンドやイベントラベルの引数は式とみなして値が評価・計算されます。式の要素として使えるのは下の4つです。
>数値
>文字列
>変数
>関数
とあるので、
この件を記述するのであれば「◆～動作」ではなく「◆注意」に入ると思います。

引き続き、何かしらありましたらご意見等よろしくお願いします。
では。

引用返信/返信削除キー/

■5536 / inTopicNo.13)

　説明ありがとうございます

▲▼■

□投稿者/ あかんべえ -(2007/05/12(Sat) 01:57:05) [ID:cPnv95pM]

　乾さん、撤回した部分に対してわざわざていねいな解説をしてくださり、ありがとうございます。
　なるほど、この表現には積極的な意味があったのですね。了解しました。

引用返信/返信削除キー/

■5537 / inTopicNo.14)

　Re[3]: No.5511本文

▲▼■

□投稿者/ あかんべえ -(2007/05/12(Sat) 02:16:37) [ID:cPnv95pM]

　あかんべえです。中箱さんからの追加提案、意義ありません。

> （Wikiだけでは必要なファイルを一まとめにしたテストシナリオの添付は行えないので現実性に欠ける。

　一応、できそうに思います。Wiki ページ上方右隅の添付機能を使えるのでは？　現在の設定では容量制限が厳しいですが、変更可能ですし。
　まあ、だからといって「添付すべし」と言っているわけではないのですが。選択肢としてはありそう。

> この件を記述するのであれば「◆～動作」ではなく「◆注意」に入ると思います。

　う～む、う～む・・・そうですね。論理的に考えてみれば「◆注意」ですね。
　「Call 変数」でのラベル指定は私にとって驚くべき機能で、今でも信じられない気分があります。そのため、「無保証の追加機能」という印象を持ってしまったんでしょう。

引用返信/返信削除キー/

■5538 / inTopicNo.15)

　分類表記「注意」について

▲▼■

□投稿者/ axiom -(2007/05/13(Sun) 14:04:56) [ID:GQSzpbQo]
http://www.lilie.jp/itemworld/

レス遅れてすみません。
中箱さん、内容のまとめ、お疲れ様です。

まとめの内容を拝見させていただきました。
現時点の最新版で問題ないと思います。

以下は、内容ではなく、文言についての意見です。

>　◆注意
>　　　　目的３に該当。例の追加や、関連項目の事情も合わせた説明
>　　　　（ヘルプからだけでは読み取れないものは　◆仕様　か　◆保証未確認動作　に含めること）

> ○利用目的３：各コマンドなどの使用例・記述例とその動作、類似能力との仕様の違いについての注意書き。
>
>　※例えば、
>　　　Info関数の記述例とその返り値の実例。
>　　　プロテクション能力項に、実例を挙げたレジスト能力との違いの説明（この場合はレジスト項にも同様の記述）
>　　など

「注意」では、利用目的や内容を適切に表現しきれていないような気がします。

違和感があったので辞書で調べてみましたが、
注意には「相手に気をつけさせる」という意味合いが強く、
この分類の目的を誤解されるおそれがあります。

注意書きというよりも、注意勧告とかYellowCard(*注1)みたいに
「こういう理由があるから、～はやってはいけない」とか
否定的に受け取られかねないので、別の文言のほうがいいと思います。

私としては、注意書きの意味とイコールな「注釈」が良いと思います。

あるいは、もっと広い範囲で使えるようにするならば、
「補足」「補足説明」などの表記とするのも良いかもしれません。

*注1.
カタカナだと制限語句に引っかかるため、英語表記にしました。
蛇足ですが、この「注」は「注釈」の略称です。

引用返信/返信削除キー/

■5544 / inTopicNo.16)

　Re[2]: No.5511本文

▲▼■

□投稿者/ 中箱 -(2007/05/20(Sun) 02:32:49) [ID:jwikVFnr]

どうも、しばらく間が空きました、中箱です。

提案内容ですが、大筋(目的や掲載内容の方針)に関しての意見は無いようですので、
今日から丸一週間と少し経った　5/27　までに大きな変更が無ければ確定とし、
その内容でWikiの項目として追加して良いかどうかを、管理側に伺いたいと思います。

需要調査の方は･･･私個人のやる気は(今の所、しばらくは)大丈夫ですし、積極的に賛同をされている方もいらっしゃるので、
(積極的に反対される方はいらっしゃらないようですし)
「やるべきだ」という強い声や、「やった上で判断する」のような管理側の見解があれば行う
ということでよろしいでしょうか？

Wikiの記述中で用いる単語の名称などについては意見をいただいているのでもう少し詰める必要がありそうですが、
項目を追加するべきか否かの判断においてはさして重要ではないと考えますので
名称関連の変更であれば　5/27　という概要確定期限の変更はしないつもりです。

また、もしも項目追加が許可された後でも、依然として必要であれば、
名称関連や記事記述のレイアウトをどうするかなどについては継続して意見交換を継続します。
項目追加の際には、記述例ページも作っておく必要があるでしょうし。

●
･･･ということで、名称関連についていただいたものなどへのレスです。

●
>axiomさん

＞「注意」では、利用目的や内容を適切に表現しきれていないような気がします。

＞私としては、注意書きの意味とイコールな「注釈」が良いと思います。
＞
＞あるいは、もっと広い範囲で使えるようにするならば、
＞「補足」「補足説明」などの表記とするのも良いかもしれません。

最初のうちは分類名称は漢字二文字で揃えていたんですが、まあ別に揃える必要があるわけでも無いですし、

すでに　◆動作　は　◆保証未確認動作　になっていますし、◆誤字　も、一時は　◆記述ミス　でしたし、
誤解される方が数倍マズイですから変更しましょう。

･･･　◆注意　→　◆仕様補足説明　ではいかがでしょうか？

同様に、◆仕様　は　◆未収録仕様　と。
◆誤字　も　◆微細記述ミス　では･･あんまり変わらない気もしますが、多少は分かりやすいかなと。

●
>あかんべえさん
(テストシナリオの添付について)
＞　一応、できそうに思います。Wiki ページ上方右隅の添付機能を使えるのでは？　現在の設定では容量制限が厳しいですが、変更可能ですし。

あ、ホントだ見落としてました。ありがとうございます。
容量に関しては1MBあれば充分では？

･･･とはいえ、実際に作るとなると手間がものすごい事になりそうなので、
とりあえずは今後次第という事にしたいのですが。

何かありましたら引き続きご意見等よろしくお願いします。
上にも書きましたが、大きな変更が無ければ　5/27を目処として提案の是非を伺おうと思います。
では。

引用返信/返信削除キー/

■5545 / inTopicNo.17)

　Re[3]: No.5511本文

▲▼■

□投稿者/ 猫王＠管理 -(2007/05/20(Sun) 15:48:22) [ID:sbOH5usf]

2007/05/20(Sun) 15:57:50 編集(投稿者)

猫王です。
いくつか意見があるので書き込ませて頂きます。
直接言及していない部分は特に異存が無いか、現時点ではまだ問題に気付いていないといった感じです。
宜しくお願いします。

>○利用目的１："実害の無い"　誤字や記載ミスの類をまとめる
>
>　・修正が必要な各種バグ（現在、各バグ報告掲示板で）の報告は、現状通り各掲示板で行う。変更は求めない。
>　・かつ、このような類のものはWikiの記事としては扱わない
>
>
>　※ただし、バグ報告掲示板に「ヘルプの細かい記載ミス報告でもＯＫ」
>　　というような旨の注意書きが追加される場合は利用目的から外す

バグ報告掲示板、開発版掲示板、汎用データ掲示板で細かい記載ミス報告も受け付けている旨を注意書きに入れておきました。
誤字や記載ミスの報告は掲示板に集約して、Wikiでは運用しないという事にさせて頂きたいと思います。

>>あかんべえさん
>(テストシナリオの添付について)
>＞　一応、できそうに思います。Wiki ページ上方右隅の添付機能を使えるのでは？　現在の設定では容量制限が厳しいですが、変更可能ですし。
>
>あ、ホントだ見落としてました。ありがとうございます。
>容量に関しては1MBあれば充分では？
>
>･･･とはいえ、実際に作るとなると手間がものすごい事になりそうなので、
>とりあえずは今後次第という事にしたいのですが。

今後次第という事でありますが、一応。

上記の一連の話でテストシナリオの目的が良く分かりませんでした。

シナリオ構造についてなら、サンプルシナリオとチュートリアルシナリオに誘導して、
特定のサブルーチンやインクルードを紹介する場合、Wiki本文に記載する形で良いと思っています。

なお、中箱さんのやる気は（しばらくは）大丈夫との事ですし、
短期的に見て問題はなさそうですので、私としては進めて良いと考えています。

やるのを前提とした意見交換で項目の整理と再確認をしてから、
中箱さんに項目追加の実作業をお願いして良いでしょうか？（Wikiで必要なパスワードなども送ります）

レイアウト等については実装後も意見が出ると思いますので、
最初はある程度の試行錯誤がありそうですね。

SRC Wikiへのリンクを左のフレームの分かり易い場所に引っ張り出しておこうと思います。

引用返信/返信削除キー/

■5546 / inTopicNo.18)

　Re[4]: No.5511本文

▲▼■

□投稿者/ 中箱 -(2007/05/23(Wed) 23:39:02) [ID:8NrUE61r]

次ツリーは週末に立てる予定ではありますが、
それ以前でも何かありましたらよろしくお願いします。

>猫王さん
読んではいたのですがレスを書くのが遅れました、すいません。

●
＞バグ報告掲示板、開発版掲示板、汎用データ掲示板で細かい記載ミス報告も受け付けている旨を注意書きに入れておきました。
＞誤字や記載ミスの報告は掲示板に集約して、Wikiでは運用しないという事にさせて頂きたいと思います。

注意書きの追加、ありがとうございます
では当初の予定通りバグやミス関連は項目の目的から外します。

●
＞上記の一連の話でテストシナリオの目的が良く分かりませんでした。
＞
＞シナリオ構造についてなら、サンプルシナリオとチュートリアルシナリオに誘導して、
＞特定のサブルーチンやインクルードを紹介する場合、Wiki本文に記載する形で良いと思っています。

･･･読み返したら、どういうものを考えているのか説明して無いようなものでしたね。失礼しました。

◆保証未確認動作は、本体のバージョンによって動作が変化する可能性が(比較的)高いので、
>・動作確認されたバージョンを明記・追記する
ことが必要になる情報です。

けれども、動作によってはその確認を行う為の準備が面倒な場合もあります。
記述内容としては大した事が無いようであっても、動作確認のためには例えば
「一つの特殊能力のレベルのみを色々に変更した複数のパイロットデータを準備した上で適当にイベントを設定する」必要があったりします。

このような記事の場合、せっかく情報を更新しようとした方がいたとしても、
うっかり準備を間違えて結果まで違った結果、間違った情報が追記されたり、
データの書き換えと確認がだるくて途中で飽きられて更新されなかったり、
･･･ということがあるともったいないですから、

そこで、この面倒な準備をできるだけ省くようなもの、
例えば、
　シナリオを起動させて表示されているユニットデータとunit.txtに記述されている内容とを照らし合わせるだけで、ある記事の動作確認ができたり、
　起動後、所定の行動を行うことで実動作の確認ができたりする
・・・ようなものを、「テストシナリオ」と称していました。

存在すればWikiの情報更新に有用だと思うんですが、作る手間を考えるとちと現実的じゃないかもな、と。

●
＞なお、中箱さんのやる気は（しばらくは）大丈夫との事ですし、
＞短期的に見て問題はなさそうですので、私としては進めて良いと考えています。
＞
＞やるのを前提とした意見交換で項目の整理と再確認をしてから、
＞中箱さんに項目追加の実作業をお願いして良いでしょうか？（Wikiで必要なパスワードなども送ります）

了解です。
ではまず、次ツリーで項目の整理と再確認などを行わせていただきます。
（とはいえ、ツリー立ては次の土日になるかと思います、すいません）

以上です
では。

引用返信/返信削除キー/

トピック内ページ移動 / << 0 >>

このトピックに書きこむ

過去ログには書き込み不可

HOME HELP 新規作成新着記事トピック表示検索新着情報過去ログ

- Child Tree -
- Antispam Version -