CNBorn|我不是大牛

参加了6月5日的 Google Developer Day 2009, Beijing，这是一个迟到的总结。

总体来说，会议期间的课程倒是并没有给我太大的收获，认真听的两个课程(AppEngine)全都中规中矩，没有提供什么特别新颖的东西。反倒是开场时演示的Google Wave快速吸引了包括我在内的大多数与会者的眼球。融合了电子邮件、即时通信，便于交流和分享的协作系统，是一个很多年前就诞生(想想2001年时的Groove)并开始发展的概念，但Google把它作为一项可能会对未来互联网产生深刻影响的标准来发展，成功的机会显然要比单独的产品要大很多。Google 已用它内心深藏的科学家气质把自己的战场直接开在了未来IT行业的基础之上。GDD09大会，给我的最大感觉是"标准为王"。无论是HTML5，还是Google Wave，都以Web未来基础的面貌出现。在竞争对手仍在以老旧的方式和产品来挑战这个行业的机会时，Google却在面向未来的更遥远的起跑线上。

另外在这次GDD上，我没有在第三方应用开发者的展示中，看到什么真正具有革命意义的，震撼的东西。基本上都是一些小点子和API的mashup，OpenSocial 依然占了不小的比重。因为我十分不喜欢反生产力的webgame，所以可剩下的让人印象深刻的生产力工具可谓少之又少，可记起来的，怕只有晚宴演讲排在我前面的北大美女的Gtalk-SSH应用了。

那天对我来说真正的亮点，是晚上的"谷歌技术开发晚宴"。这才是一场真正的Geek狂欢盛会。布满灯光的硕大会场、具备Google风格，肆意拜访的沙包椅、酒水饮料...... 实在是众多Geek们少有的体验。说那里是个充满Geek风格的Woodstock应该不为过。

自己还有幸参与了Google的开发者演讲。短小的演讲讲述不了太多的东西，而且正如我之前说的，真正具有震撼效果的开发者应用还太少，所以我对于讲述自己的产品如何通过具体的代码来实现一个小功能也十分不以为然。我更关注这个产品以后的潜力。于是就着重描述了未来的构想。(可以透露的是，在不长的时间里大家就可以看到 CheckNerds 的这个更新) - "已经做了什么"并不重要，重要的是"我们还能做什么"。现在回想起来我猛然发现，这也是Google的观点，所以它们一直在向新的标准迈进。

另外自爆一下，想看这次我的演讲是什么样子的朋友，请猛点这里，如果footbig当掉了看不到，还可以猛点这里

很早就听说过 Getting Real 这本书，但是开始认真阅读却是在启动自己的个人项目之后。赫然发现自己在项目中采取的一些原则和方法，原来早有类似的理论支持。当然，Getting Real 的理论更实际、也更加全面，毕竟是真正的经验之谈。此后这本书就成为了我时常阅读的材料之一。

刚开始翻阅 Getting Real 中文版的时候，发现它并没有翻译完整。而英文部分非常简单，也就没怎么在意。最近由于想要整理一些想法和知识，再次翻出Getting Real 这本书，突然觉得想为这本书做些什么。想到虽然官方的未完成版中文翻译阅读起来也没有太大的问题。但作为一个翻译版本，没有翻译完整总是让人感到遗憾。于是在网上寻找是否有未完成的中文部分的工作项目。发现了两个项目，其中一个架设在Google Groups的项目很久没有更新。而译言上关于这本书的项目却十分出色，翻译工作更是已几近完成。只是不知为什么没有能够最终进行修订、和已有的中文翻译整合。于是决定自己来做这项工作

事实上这并不是一个非常复杂的工作，剩下的翻译工作已经很少，而修订工作需要的，更多的是耐心和专注。主要修订一些明显需要优化的地方，如将"《一个实用编程者》"这样的翻译，改为大家认可度更高的"《程序员修炼之道》"等。

而目前我最关注的还是版权问题。由于这本书并不是CC授权，所以用Wiki这种形式来进行翻译及校对工作并不适宜。这个中文版本中原有翻译者的署名会保留，同时他们的工作会在文档中进行详细的描述（见中文版最后的"整合中文版编后"段落）。而经由我以及未来可能由更多参与者所做的一些修订也会尽力详细列出。未来在整个翻译、校对工作进行到一个比较好的阶段的时候，我会开始联系37signals，尝试把这个工作作为最终的官方中文版发布。

在最近和朋友们的一些讨论中，我再次感觉到了让更多的人了解Getting Real的必要。有太多的Web活软件项目正在变得非常庞大，以至于他们被无数的小特性冲晕了头脑，使得把握一个产品最核心的方向这样本质的行为几乎变成了不可能。我觉得Getting Real里讲述到的一些东西，非常适合一些大公司用来作一些思考：为什么更大的机构在很多时候没有更高的效率？为什么他们的产品会被小公司打得落花流水？如何唤回他们曾经是小团队时的战斗力？很多此书中的观点，更像是在经历了软件和Web项目无比复杂化之后，一种清新的思想回归。得以让人们重新发现，在他们没有宽敞的办公室之前，那些满腹理想的小团队时期真正宝贵的核心竞争力所在。

点此查看完整的 Getting Real 中文版，对这个项目有任何的意见或建议，欢迎与我联系。

Bugzilla是一个经典的软件缺陷追踪工具，最初版本由Netscape开发，1998年遵循Mozilla Public License协议公开源代码。Bugzilla作为功能强大的Bug Tracking系统，在无数的商业/非商业组织和项目中得到广泛的应用。

Bugzilla 系统中默认的设计是可将所有的信息对任何人开放，但是针对用户应用需求的不同，可以针对不同产品设置不同的权限设定。可以适用于如：在一个大公司的多个软 件项目组，通过一个全公司的Bugzilla系统来追踪各个项目的Bug，各个组之间的人员并不能查看或编辑其它组的内容等类似情况。

事实上Bugzilla 网站上的手册里针对此部分有很详细的说明，但是我在使用中发现，互联网上还没有对此进行介绍的较为详细的文章，同时如果没有通过实际的例子来将设置方法加 以展示的话，整个设置和对照英文文档的过程还是让人感觉晦涩及难以理解。所以本篇文章将以Bugzilla系统应用中的实例来讲解下如何对不同产品的权限 进行设定。

（本篇文章的内容在Bugzilla 3.2,3.2.3中测试完成，Bugzilla后续版本可能会对此部分功能进行变更，请在使用及部署中注意）

本文目的与要求：

通过实例讲述在Bugzilla系统中如何针对用户应用需求的不同，针对不同产品设置不同的权限。

您需要对Bugzilla有简单的了解和部署经验，并且已经在开始使用Bugzilla。本文中不会针对个别选项、设置进行事无巨细的探讨，也不保证所讲述 的内容涉及到权限设置部分的各个方面。仅以一些实例，为各位Bugzilla用户在各自的应用中起到一些抛砖引玉的作用。

设置不同组权限设置的前提要求：

    首先需要完成Bugzilla里的分组设置。如可根据用户的不同分为"质量"、"前端"、"测试"等不同的用户组。用户可以同属为多个组。组的分类可以和 要提交问题的产品相关，如针对"质量"的问题，会有一个对应的"质量"人员组；也可以和问题不相关，如通常为了管理方便，我会创建一个"部门主管"组（可 查看所有记录）、以及"所有用户"组（通过通配符 .* 匹配所有用户，在使用中可简化一些设置）。以下的几个实例的解决方法，会遵循我在这里的用户组设计。

    如需设置组分类和产品分类相对应，可启用Bugzilla->管理->参数设置->组安全设置 中的makeproductgroups选项。启用此选项后，每创建一个新产品，系统均会自动在用户组中创建一个与此产品对应的用户组。

产品分组权限设置页面：

    无特殊说明，均在Bugzilla->管理->产品管理->产品页面->编辑组访问控制页面中

权限设计需求实例:

1. 每个用户都可以提交不同产品的Bug
   
2. 所有用户均可编辑问题/只有相应组的用户才能编辑相应的问题
3. 所有用户在提交问题时，均可选择此问题是否针对其它各个部门的人员可见
4. 产品严格分组，不同的产品组只能查看相应组的产品Bug信息 - 此范例来自 Bugzilla官方手册
5. 创建一个只读产品（此产品的相关信息只能查看，不能提交和修改）- 此范例来自 Bugzilla官方手册
   

问题1解决：

    选中"所有用户"组的Entry选项

问题1解决说明：
    
    Entry 选项决定了一个组的用户是否有权限可以针对一个产品提交问题。同时如果有至少一个组选择了Entry这个选项的话，那么其它没有选择的组均无法针对此产品提出问题


问题2解决：

    所有用户均可编辑问题：选中"所有用户"组的editbugs选项
    只有相应组的用户才能编辑相应的问题：依次编辑各个产品，选中相应组的Editbug选项

      
问题2解决说明：

    Editbug 以及 editbugs 两个选项的差别：

• 当有任何一个组选择了Editbug选项后，其它未选择的组均无法编辑此产品
• 如果有一个组选择了editbugs以后，该组即可编辑此产品的所有问题

问题3解决

    修改相应其他组的MemberControl、OtherControl权限

    这两个权限各有三个选项

    简单说明，
    一个组的MemberControl指操作中用户属于这个组时，
        Default指可以在界面上选择此组用户是否可查看此产品问题，并且默认此选项选中
        Mandatory指在界面上无法选择此组用户是否可查看此产品问题，但此问题设置为强制与此组用户相关
        Show指可以在界面上选择此组用户是否可查看此产品问题，并且默认此选项不选中
        N/A指与此组完全没有关系，无法访问

    一个组的MemberControl指操作中的用户不属于这个组时的情况，三个选项和上面的相同。


    举个例子

        倘若有一个"主管"用户组，可查看/编辑所有提交的信息（并且此设置不可能由其它用户或相关的Bug提交者所改变），权限可设置为

            主管 Mandatogy Mandatory editbugs

        倘若有一个问题，可能需要"质量"、"前端"组用户查看，但需要提交此问题的用户（所有用户，可以不是这两个组的成员）在提交时进行设置。同时还不需要让"程序"组的用户查看，那么权限可设置为

            质量 Shown Shown
            前端 Shown Shown
            程序 N/A N/A
            所有用户 Entry (或设置为 除"程序"组以外的其他组均可以Entry)

     针对问题三的情况，应该设置成为：

        对其他可能会与此问题相关的用户组，权限设置成为 Shown Shown
        这样在提交问题时，选项里就会出现"是否让一下组查看问题"的选项了。


问题4解决：(此问题可视作问题3里设置权限的例子的一个延续)

   

问题5解决：(此问题可视作问题3里设置权限的例子的一个延续)

        创建一个用户组，名为"只读"。将需要设置权限的产品设置为

        只读 Entry, N/A N/A, CanEdit

        简单说明
                Entry及CanEdit均为排他设置，只要确保"只读"组没有用户，即可实现无用户可提交和编辑此产品的Bug信息。

Mozilla官方手册中还有不少权限设置的实例，相信在读完以上部分以后，理解Mozilla的说明会更加方便一些。

本文的大多数内容均经过我的实验，但是仅供参考之用，我不能确定文章中的所有设置均正确并适应您的需求，总的来说，Bugzilla的设置，还需要在实践中加以揣摩。

在日后时间宽裕时可能会对此文章进行进一步补充。如对此文章由什么意见或纠正，欢迎留言或直接给我写信，我的邮箱是 我的英文ID@gmail.com

最后需要明确的是"产品"这个概念。我在工作中搭建的Bugzilla系统均不是应用于软件开发领域，而是对流程中的问题进行追踪。"产品"这个在 Bugzilla中的概念，可能在Bugzilla系统根据用户需求进行定制的过程中被其它文字替换。关于针对Bugzilla系统进行定制的更多信息， 欢迎查看这篇文章：OpenParty "有狐"，在此次活动中，我进行了一个"Bugzilla系统部署、定制"的演讲，具体的介绍幻灯片可以查看这里《Bugzilla @ Customization》。

作者：CNBorn，bugzilla-cn (Bugzilla中文本地化)项目组成员


主要参考文档

本文中Bugzilla的中文翻译均来自 bugzilla-cn (Bugzilla中文本地化项目)

Bugzilla官方文档中对于产品组权限部分的说明(Bugzilla 3.2) http://www.bugzilla.org/docs/3.2/en/html/products.html#product-group-controls

Bugzilla权限管理讨论，这个是我在中文互联网上发现的少见的关于此问题的帖子，只有2句话，总结得不错 http://topic.csdn.net/t/20061226/23/5258177.html