前言
历来中文区提交的 bug 数量都非常之少，少到可以忽略不计的地步。
因为他们更倾向于「找人」、「去论坛哭诉」、「去贴吧痛骂」，一片同仇敌忾的大好局面，然后…bug 不来不去。（当然这不是种族优越论，老外也会这么做，只不过他们去抱怨的地方比较靠谱：邮件列表，G+ openSUSE 社群，直接能接触到开发者，而我们更倾向于找一个「靠山」，让这个靠山来给你过一倒手。）
这本质上说是一种内心不够强大的表现（当然也不能太强大，太强大就完全不抱怨地跟 bug 一起过了…），或者说脸皮不够厚（怕鸡同鸭讲啊、怕英文不好丢人啊，但你要知道，openSUSE 不像别的发行版，我们的母语其实是德文，回复你那位就不怕鸡同鸭讲吗？还有英文不练永远不好），或者说患得患失（我这算不算一个 bug？算与不算不是你说就算的，要开发者来鉴定，bugzilla 上有一个分类叫做 invalid），或者说封闭倾向（我天朝地大物博，还内部消化不了一个 bug？但是开源的精神就是：即使内部能消化，也要公开化。最终还是要有个人把那个 fix 提交，既然如此，为什么要麻烦我们本来基数就不大的讲中文的开发者呢。只有越封闭落后的地方，「开眼看世界」的桥梁纽带才越多，然后桥梁纽带的自利心理又会去阻止更多的人变成桥梁纽带，比如某咸平。但我们 openSUSE 社区不会是这样）
我成为不了你的人生导师，你的心理问题我解决不了，只能解决流程问题。
正文：
我们以汇报 gettext-runtime 的一个 regression 为例。（所谓 regression，也是 bug 的一种，意思就是比如之前版本本来好好的东西，现在这个版本不行了，这主要是因为版本过渡时的某一个 bugfix，触发了更多的问题，让本来好好的东西不好了）
发现过程：
是我在 M17N 源里的 scim-anthy 原来编译得好好的，突然我们的 release manager coolo 给我发提醒说 13.1 Beta 里面这个包已经 fail 7 天了。于是我去 M17N 源看了一下，openSUSE 12.3 是成功的，openSUSE Factory 是失败的。点开两者的编译日志对比了一下，发现在 autopoint 这个命令后面，openSUSE Factory 并没有去 copy intl 文件夹。
于是我祭出万能的 Google，搜索「autopoint copy intl」（注意，到这里我依然不知道 autopoint 是干嘛的），看到了这个：
里面有说
大概意思是那人认为复制 intl 有个 bug，于是提供了一个 patch。问题在于，你帮忙修复的心是好的，但是现在是我不复制 intl 就编译不了啊。于是这是一个 regression。
上面是正面的例子，我现在要看看有没有人已经汇报过这个 bug 了，于是搜一下反面「autopoint not copy intl」，一下子就出来了：
bug #39536: autopoint 0.18.3 does not copy “intl” directory any more
savannah.gnu.org/bugs/?39536
跟进阅读，发现了这个官方人员的 commit：
git.savannah.gnu.org/cgit/gettext.git/commit/?id=c0d3ce9120fc24d2b78af59c5760ce1ec0dc0ad4
果真是之前那位犯二了。现在我知道这是 gettext 的问题了。因为 gettext.git 修的嘛。
但是这个 bugfix openSUSE 有没有呢？看下提交时间是 7 月 20 号。
于是去 build.opensuse.org，右上角搜 gettext，看到 openSUSE Factory 里有一个 gettext-runtime。点进去看发现它的最后更新日期是 8 周前，也就是 7 月初。所以没有。于是我要报一个 bug。
汇报过程：
注意：全程英文
- 登入 bugzilla.novell.com（你需要一个 Novell 帐号）
（ 用 Firefox 登，Chrome/Chromium 会报「重定向循环错误」，我也不知道为什么 ）
-
点击「Home」旁边的「New」
-
产品线选择「openSUSE」，产品选「openSUSE Factory」（你要是 12.3 出的问题就选 12.3）
- 第一步是让你看你遇到的问题有没有人报告过了，往下拉有个搜索框。
我们来搜索下，关键字从小到大，比如 autopoint 是 gettext 的一部分，我就先搜它后搜 gettext。
autopoint 没搜到。gettext 搜到两个：
第一个是 OBS 管理员 Adrian 报的，名字就叫「build fails」，汗，看到了吧，即使是开发者自己，有时候写的 bug report 跟我们也都是一样二的，点进去看下，通篇没提 autopoint，是无关的; 第二个人家在标题就写明白了 libvirt，这是虚拟化的事情，也是无关的。
于是我们需要自己报
- 「组件」那里自己选，都比较好理解，我选的是 BaseSystem，因为刚才在 OBS 上我已经看到 gettext 是在 Base:System 开发源里面开发的了。
「硬件平台」是指出错误的 CPU 架构（CPU 架构是跟编译器相关的），我这里选 All（因为编译都失败了），如果你是 32 位上遇到的问题就选 i586，否则选 x86-64（当然开发者也想到你可能搞不明白，所以直接给了两个选项：32 bit/64 bit 23333…）。
「操作系统」是指出错误的操作系统，一般就是你正在跑的操作系统，选 openSUSE 12.3，当然也有别的，不过你是 Debian 也不需要来 SUSE 报 bug 对吧…
「产品版本」这不需要讲了。我选的 13.1 Beta1，因为 coolo 发的邮件就是说那包在 13.1 Beta 里 fail 了 7 天。
重点来了：「摘要 Summary」。
摘要的写法要起到开宗明义的作用，就是不点开看你的 report，看标题就大概知道这是什么问题。比如我写的就是「Gettext-runtime autopoint not copy intl dir due to upstream fixed bug」
要点明：出错误的软件包（gettext-runtime），出错误的程序（autopoint），问题（not copy intl dir）。
至于后面的 「due to upstream fixed bug」是点出这东西上游已经修了。这样开发者比较的开心，因为不用自己修啦，于是心理上抵触就不会太大，比较愿意点开看。
至于之后是怎样，是进入 13.1 呢，还是怎样，你在正文里表达希望就行了。
有两点是要避免的：
- 摘要其实是一个标签系统，只要双方能看懂，别用冠词 a/the 什么的去占位置，也可以用一些缩写，比如 directory（文件夹）我就写了 dir，因为 它有长度限制
- 不要把出错消息整条的贴在那里。 Linux 下有各种各样的日志，如果不是开发者写在维基上面（Category:Reporting bugs - openSUSE Wiki 有整整一个分类告诉你报各种不同的 bug 需要提供的信息，有些我翻译成了中文，你进去看左边的多语言标签有没有简体中文就行了）明确说了需要的日志里面产生的错误消息，没人有心情去关注你系统上的日志，这是时间的浪费。
「细节」就把我前面的「发现过程」言简意赅的描述一下就可以了。
你遇到的情况、相关的日志节选（注意是节选，完整日志请用附件，实在不知道贴啥也没关系，开发者会管你要的，除非是他写到维基要啥了然后你还不给，那这样的 bug report 会被主观地判定为低质量的，于是就放在那里不管）说明下。我写的是
「重现频率」：是肯定会发生啊，还是频繁啊，还是偶尔啊，还是别的啊。我这个是肯定会发生的，要是「频繁」或者「偶尔」，你得继续在下面的「重现步骤」里写怎么重现它。「期望结果」和「实际结果」也都要写。你不能期望得太离谱以至于这程序还没实现呢，那就不叫 bug 叫 feature 了。
然后最后还有一个「严重性」，就是说你这个 bug 需要被优先处理还是怎样，一般崩溃类的是优先处理的，但是你也不能太虚张声势，明明没崩溃的 bug 选了个 crash，那样第一印象就不好了，因为你在跟别人抢开发者的时间。
都填好了，点击提交。
恭喜！