|
楼主 |
发表于 2008-6-28 17:29:28
|
显示全部楼层
实现BUG跟踪是为了减轻管理员的管理负担
一楼更新用了
--------------------------------
--------------------------------
2008-6-29
谢谢大家的发言.我还是个小学生,前两天浏览了翻译区的帖子,昨天下午完成了第一篇稿子.昨晚我又继续构思了一下实施BUG管理的意义.
这篇算是对第一篇稿子的补充说明了.
早上看完了至9楼的回帖.
对于个别同志不懂,不清楚的情况,我很抱歉,还没完全构思好就发表了第一篇文章.我平时和EQUN论坛交流不多,大家的水平我还不十分了解.
首先很荣幸的介绍:"BUG跟踪"正是一种可以使文章发布管理变得轻松的方法,理论上说可以达到一劳永逸.
目的:
实现BUG跟踪是为了减轻管理员的管理负担,把管理者从管理工作中解脱出来,高效率利用自己的时间使之用于具体项目中去.
问题:
http://www.equn.com/forum/viewthread.php?tid=18481
我在搜索"版规".而这个帖子中反映出咱们论坛版规制度上的瑕疵.也就说是现在还没有版规.
新手加入,没有版规.不管如何,统一版规或是说契约还是必要的.这是个人信用的基石.
这一现象正是由于论坛缺乏管理才会产生的情况.而新志愿者的加入数量不够多,这缺乏版规的问题所造成的后果没有完全的暴露出来.
什么后果?这个后果就是大家还在为一个可以从一开始制定版规,就能摆平的问题分心,翻旧帖是新志愿者参与的过程,不应该过多干涉,这样会在一定程度上阻碍新事物发展.
无版规本身就是一个BUG.
方向:
从这里开始介绍的就要实行所谓的BUG流程跟踪了.
1.进行翻译工作遵循的规则(众多版规中的一个,也不完全是版规.只是一个翻译工作流程的介绍)
(1)翻译区的发布状态:
-所有已翻译的文章,整理并打包上传服务器.
-服务器上于干目录上划分一个1级支目录"@1"(内容:1.所有实施分布式计算的网站,2.版规);
-每一个"@1"下面再分2级支目录@2(包括:1.新闻贴,2.静态贴,WIKI贴或技术贴等);
-支目录"@2",在这里保存所有文章的最新状态.而且是处于正规状态(或者也可以说发布状态或其他意
思,总之是开放给大众的,这里也可挑错,但影响视图).
-支目录"@1"用于提供给其它英语官方网站下载中文.
(2)待译区的待译状态:
- 干目录
-待译文章在此处认领,察看待译文章的进度.译闭文章留底,留待会员更新查BUG.提交审核.
所有翻译任务可在工作区中进行, 这样的BUG跟踪,是一个无限的循环系统,界面良好.细节尚待讨论
2.由于BOINC的官方性,管理员需要相当慎重的发布信息.而我们需要大量挖掘潜在的志愿者,把文章翻译出来.不开放注册的WIKI无法满足此要求.
漂亮的WIKI最大不足就是无法及时进行BUG跟踪,这样也就无法满足一个分布式多线程的项目进行系统的同步开发.
管理上,前期需要将文章导入至BUG数据库,这是由一定工作量的,而且所有工作都要先从BUG数据库开始.后期导入WIKI就是直接提取数据了.
总结:
有一种特殊情况:可以不更新BUG而直接修改WIKI.这样就抛弃了前期所有的BUG跟踪工作.
那么为了一时方便就直接改WIKI得了吧?或者说我们只用WIKI?
不行.负责人的个人因素无法确定,WIKI会面临无法进行持续更新的情况.但由于WIKI本身的后期内容开放性,不足以使我想说明的问题暴露出来.
WIKI没有发布BUG的跟踪体系,更应该说是没有一种基于流程的跟踪体系.
WIKI也就是表(其中的察看更改历史功能只是后期发布工作的一部分,带来了后期的管理方便而已).
里则需要BUG管理全部的工作状态(也就是从前期开始 就实施全程跟踪,这个地方理解上有点绕弯),
真正的问题:实际上两者不是一回事.
BUG全程跟踪:是可以实现多个负责人同时进行工作的基础.大家不必为分配工作等管理问题操心,自然而然的实现了任务分配.
只要是有能力的人可以自行直接提交任务,
管理员审核后可以直接提交WIKI.
以后的任务自然又回归到BUG跟踪上来.
这样的流程体系升华了管理员需要自己维护BUG(也就是说管理员编写资料,发布资料的WIKI状态).
发展到志愿者提交BUG(减轻了管理员处理杂务的负担,管理员可以专心于自己的工作的这样一种流程状态)成为一种容易实现的过程.
管理员再也不必为管理所有的项目而担忧,不会因管理上遇到问题而使工作进展缓慢或造成耽误本职工作.
这种开发方法广泛应用于软件生命周期的开发过程,效果很好,国内应用正处于起步阶段.
而作为一种开发工具应用于协同翻译的项目组织管理,也是可行的.
这里提出一些建议:
需要采用事前管理的态度来实现目的. 从一开始就要规范化管理.目前所有项目可以说需要无数的"眼睛"关注BUG,更新BUG更容易.
管理任务也会轻松起来,但也不是这么容易说的清的.不过我该吃饭了.
再次谢谢大家! 2008-6-29 12:00
=======
最新内容时间 :2008-6-29 12:36
版权信息:不经本人同意,一律禁止.
=======
更新内容 2008-6-20-9 16:39
目前查询 关键词"CN"的GOOGLECODE项目不到200个."CHINA"的不到100个.
http://code.google.com/p/equn/
愿意尝试的朋友需要有GMAIL帐号,而且需要现经过我验证才能加入.
请把您的Gmail帐号告诉我.(请发论坛消息)添加Project owners或Project
members.
审核后我会尽快添加您的帐户到相应的权限下.我再发论坛消息通知您后就可以用Gmail登陆.
发放规则是:本论坛的管理员拥有Project owners;
会员拥有Project members;
提醒您:使用过程中可能还要用到相关软件进行BUG库的操作.
下面收集了部分可供学习参考的链接地址.
About SetiBoincInf
http://code.google.com/p/setiboincinf/
(用中国关键词)
南京大学天文系
http://code.google.com/p/astrodynamics/
CodeIgniter中国
http://code.google.com/p/codeigniterchina/
中文Squeak(land)
http://code.google.com/p/chinesesqueak/
(用china关键词)
ICanPay
http://code.google.com/p/icanpay/
easyMule
http://code.google.com/p/easymule/
yeeyan
http://code.google.com/p/yeeyan/
周蟒是針對華文地區,以簡化程式教學為主要目的的 Python 程式語言方言
http://code.google.com/p/zhpy
(用cn关键词)
launchy2 中文修改版
http://code.google.com/p/bugzilla-cn/
欢迎访问Bugzilla简体中文本地化开源项目网站
http://code.google.com/p/launchy-chinese/
关于 WordPress 中文团队
http://code.google.com/p/wpcn/
Cyask是一个简单易用的问答系统
http://code.google.com/p/cyaskuc/
Open Book Project 开放图书计划
http://code.google.com/p/openbookproject/
我们的目标是把django文档翻译成中文
http://code.google.com/p/djangodoccn/
GMLive并不直接提供P2P直播服务
http://code.google.com/p/gmlive/
聚合国内python人的力量,建立一整套python的中文本地化工具包
http://code.google.com/p/pyzh/
j(java) w (web) s (studio)是一个集成、绿色、简洁的开发环境
http://code.google.com/p/jws-jpt/
1stlog
http://code.google.com/p/1stlog/
基于Ruby on Rail的SCM(软件配置管理)WEB应用
http://code.google.com/p/rails4scm/
这是一个小型的项目开发管理
http://code.google.com/p/devemanage/
emlog 建筑工地
http://code.google.com/p/emlog/
[ 本帖最后由 duligavin 于 2008-6-29 18:56 编辑 ] |
评分
-
查看全部评分
|