Blender.jp

[wiki]
***挙げられた案

-Bmesh の開発

-ジョブ管理とスレッド化の開発（ごめんなさい、私がこれを提案しましたが、残念ながらミーティングには参加できませんでした。Xat)


***QA
Q: コンパイル時に多くの Warning がでますが、これらを綺麗にするのがプロジェクトのいいスタートではないのですか？

A: そうですが、いくつかは本当のバグであるわけで、明示的なキャストは常に解決策になるとは限りません。いくつかの暗黙的な宣言は簡単に修正できるでしょうが。


Q: 同じバグに二人が作業してしまうのを防ぐ方法は？

A: もしそれの作業をしばらくするつもりなら、BugTracker にリプライを残して下さい。もし簡単に修正できたのなら、単純にパッチを作成し、BugTrackerにリンクを貼って下さい。


Q: モジュール作者とバグの議論をするのは役に立ちますか？ 彼らは私の質問に答えてくれますか？

A: もちろん。もしそのバグに多くの変更が強いられる場合、まず作業前に彼らと議論する方がいいでしょう。
時間がゆるせば、モジュール作者がコードの質問に喜んで答えてくれるでしょう。ただし、バグの箇所特定の手助けを頼む時、それが時にはバグ修正作業の90％にもなることに注意して下さい（これは質問が苦痛ということではありません）。


Q: バグ修正はさておき、コード自身になれるいい方法はなんでしょう？

A: 小さな機能のリクエストを見る、もしくは現存の機能を追跡してみて、あちこちに小規模の変更を行うのがコードの流れを理解するのにいいでしょう。


Q: UIの動作のドキュメントはありますか？

A: いくつか。 http://wiki.blender.org/index.php/Dev:2.5/Source/UI/UIlayoutGuide http://www.blender.org/documentation/250PythonDoc/bpy.types.UILayout.html http://wiki.blender.org/index.php/Dev:2.5/Py/Scripts/Guidelines/Layouts http://wiki.blender.org/index.php/Dev:2.5/Source/UI/LayoutEngine また、release/scripts/ui/properties_data_camera.py のような UI スクリプトを見るものいいでしょう。


Q: 将来的に Git や Mercurial に切り替えする計画はありますか？

A: しばらくはありません。


Q: バグをトラッキング(BugTracker)するのと同じように新機能を管理する場所は？

A: 組織化されたようなものはありません。大きな機能の時（それらが内蔵されていない機能の場合）は、大抵 Branch 内で作業されるか、もしくは品質が認可と精査がされるまでは一連のパッチ内にあります。その後これらは Trunk にマージされるかもしれません。


Q: OK、では新機能は私たち自身が決め、その後担当の開発者に提示し、賛成か反対かを受ければいいのですね？

A: 最初に機能について話をしておけば、その機能の作業が終わった後に反対される可能性は少なくなるでしょう。
開発者たちは恐らく否定するでしょうが、大抵の場合彼らが決定するため、こんな感じでモジュール作者に話を通しておくことが一般的に一番いい方法です。


Q: 公式な新機能リストはありませんが、モジュール作者はそのモジュールの新機能リストを所持していると考えていいでしょうか？

A: ええ。いずれはもっと組織化すべきでしょうね。


Q: ソースフォルダの最新の概要はありますか？

A: http://wiki.blender.org/index.php/Dev:2.5/Doc/Blender_Source/Files_structure
[/wiki]