4月15日组协调人会议纪要

[wjfonhand]

参加人员tony,jeff,simon,holts, holts整理记录, 会议讨论要点

simon:
tong我们在谈下一步如何走

tony:
大家都没方向了:D

simon:
不是相反大家都有目标只是都没做这个才是问题哈哈

tony:
最近上论坛不多，倒是一直在学习Python

jeff:
tony，统计翻译进度，技术上可行不？
我想要一个统计图，在wiki首页

tony:
这应该是可以做到的，不过我不是很想花这个时间
我觉得目前没有很大的进展，主要还是我们大家都对系统不够熟，对Python也缺乏了解
我们可以不必刻意追求进度
能出几个人把系统玩得流熟的
能有个把人可以解释程序逻辑的，自然就会有进展
文档的翻译是集合一些人来做一些事的一个方法
是希望在一开始不知道何处下手时，可以有一处轻易能做点事的地方
其实项目组既然已经有了这么多人，那么现在最重要的是保持大家学习的热情
学习系统的使用，学习Python，学习模块开发
文档的进度在其次，你们说呢？

simon:
这个不重要，重要的是持续

tony:
如果我们中出不了熟悉上面这些项目的专家，翻译的再好，也走不出下一步
所以我希望我们把论坛真正作为学习交流的场所
把自己所学，把疑问都带到论坛里来
不好意思，一言堂了，搞得兄弟们都大脑缺氧
我觉得mark的学习方法最值得提倡
把学习中的疑问提出来，交代自己的思考过程，有什么可能的解决办法
最后如果自己找到了解决方案，还做一个漂亮的总结
你说吧

simon:
谢谢呵呵
我首先说下我们现在的位置，是组织者就是引导大家的
刚才大家都说了一个问题缺乏目标
我的意见认为不是缺乏目标而是缺乏动力。
tong你刚才说了需要三方面的专家是系统学习，python开发和模块开发的专家？

tony:
我只是举个例子

simon:
那我问个问题你的意思是在我们中培养？

tony:
不是谁培养谁

simon:
那就是需要各方面的专家在我们中培养？
那问题的前部分你同意了是需要专家对吧
你真的这样想没其它不同是你核心的想法？
没关系就已现在来说就行，反正不变的就是不断变化
那你想这些人那里来和怎样来，这个倒是组织者的责任
算了不问这个留着下次说

tony:
如果永远不想办法学习提高，我们只会是比新菜鸟年纪大点的老菜鸟

simon:
我说下我的想法
刚才我说了一点我们要满足现在关注tinyerp的需求
一个管理软件对它关注的人一般分两类：技术狂和使用者
我觉得现在我们的大部分现在还处于使用者的角度看问题，从论坛上和msn的问题上都是一些怎样做的问题

tony:
这样的问题永远都会存在

simon:
这个我遇到最多，很少人说这个东西怎样样
我建议以操作手册作为起点，同时修正翻译
这个问题jeff提了两个问题第一是协同因为大家基础不同，第二是工作量大
我认为jeff问题的解决方法是组织的方式可以克服的
我的想法是用提问的方法，提出一个问题：如新产品怎样加，然后围绕这个问题解答，中间不说原理只说操作，用图来说文字尽量小
在初期我们自问自答
等问题基本好了放在wiki上自由修改
其他的问题同样这样来解决。

tony:
不错的想法

jeff:
good idea
我们真正需要解决的问题，很难界定

simon:
我不太主张什么问题都自问自答可以提出些我们真正需要解决的问题
但前期我们需要自问自答。这个要引导等成熟了会自然生长的
对我们有两种情况一种是我们安排的有能力自己解答的一种是我们正的需要帮助的，两种在不同的时间段有不同的侧重。我们前期是引导工作会频繁点后期我希望能以我们需要帮助的为主

tony:
我们可以这样，借用别人的沙盘演练，或讨论几个由简单到复杂的case，把它分解到每一步的框架，然后由大家把具体的操作填进来，所有都在wiki上进行
就象是一个共同完成的作业题
大家可以自己去设计作业题，由大家一起来完成

simon:
这个是组织方式，至于问题是什么解答什么，这个可以讨论
不过初期是需要我们引导，简单点说就是要我们工作。我们可以先提出很多问题当然也不要太多
这样组织可以不要什么计划，时间表，你提问题就是了，你能解答就答不能就等人来
不过再重点说一下，初期需要我们引导
好了我说完了，再多等下次吧呵呵不然你们会头晕的

[[i] 本帖最后由 wjfonhand 于 2008-4-16 22:51 编辑 [/i]]

[wjfonhand]

参加人员tony,jeff,simon,holts, holts整理记录, 会议讨论要点

simon:
tong我们在谈下一步如何走

tony:
大家都没方向了:D

simon:
不是相反大家都有目标只是都没做这个才是问题哈哈

tony:
最近上论坛不多，倒是一直在学习Python

jeff:
tony，统计翻译进度，技术上可行不？
我想要一个统计图，在wiki首页

tony:
这应该是可以做到的，不过我不是很想花这个时间
我觉得目前没有很大的进展，主要还是我们大家都对系统不够熟，对Python也缺乏了解
我们可以不必刻意追求进度
能出几个人把系统玩得流熟的
能有个把人可以解释程序逻辑的，自然就会有进展
文档的翻译是集合一些人来做一些事的一个方法
是希望在一开始不知道何处下手时，可以有一处轻易能做点事的地方
其实项目组既然已经有了这么多人，那么现在最重要的是保持大家学习的热情
学习系统的使用，学习Python，学习模块开发
文档的进度在其次，你们说呢？

simon:
这个不重要，重要的是持续

tony:
如果我们中出不了熟悉上面这些项目的专家，翻译的再好，也走不出下一步
所以我希望我们把论坛真正作为学习交流的场所
把自己所学，把疑问都带到论坛里来
不好意思，一言堂了，搞得兄弟们都大脑缺氧
我觉得mark的学习方法最值得提倡
把学习中的疑问提出来，交代自己的思考过程，有什么可能的解决办法
最后如果自己找到了解决方案，还做一个漂亮的总结
你说吧

simon:
谢谢呵呵
我首先说下我们现在的位置，是组织者就是引导大家的
刚才大家都说了一个问题缺乏目标
我的意见认为不是缺乏目标而是缺乏动力。
tong你刚才说了需要三方面的专家是系统学习，python开发和模块开发的专家？

tony:
我只是举个例子

simon:
那我问个问题你的意思是在我们中培养？

tony:
不是谁培养谁

simon:
那就是需要各方面的专家在我们中培养？
那问题的前部分你同意了是需要专家对吧
你真的这样想没其它不同是你核心的想法？
没关系就已现在来说就行，反正不变的就是不断变化
那你想这些人那里来和怎样来，这个倒是组织者的责任
算了不问这个留着下次说

tony:
如果永远不想办法学习提高，我们只会是比新菜鸟年纪大点的老菜鸟

simon:
我说下我的想法
刚才我说了一点我们要满足现在关注tinyerp的需求
一个管理软件对它关注的人一般分两类：技术狂和使用者
我觉得现在我们的大部分现在还处于使用者的角度看问题，从论坛上和msn的问题上都是一些怎样做的问题

tony:
这样的问题永远都会存在

simon:
这个我遇到最多，很少人说这个东西怎样样
我建议以操作手册作为起点，同时修正翻译
这个问题jeff提了两个问题第一是协同因为大家基础不同，第二是工作量大
我认为jeff问题的解决方法是组织的方式可以克服的
我的想法是用提问的方法，提出一个问题：如新产品怎样加，然后围绕这个问题解答，中间不说原理只说操作，用图来说文字尽量小
在初期我们自问自答
等问题基本好了放在wiki上自由修改
其他的问题同样这样来解决。

tony:
不错的想法

jeff:
good idea
我们真正需要解决的问题，很难界定

simon:
我不太主张什么问题都自问自答可以提出些我们真正需要解决的问题
但前期我们需要自问自答。这个要引导等成熟了会自然生长的
对我们有两种情况一种是我们安排的有能力自己解答的一种是我们正的需要帮助的，两种在不同的时间段有不同的侧重。我们前期是引导工作会频繁点后期我希望能以我们需要帮助的为主

tony:
我们可以这样，借用别人的沙盘演练，或讨论几个由简单到复杂的case，把它分解到每一步的框架，然后由大家把具体的操作填进来，所有都在wiki上进行
就象是一个共同完成的作业题
大家可以自己去设计作业题，由大家一起来完成

simon:
这个是组织方式，至于问题是什么解答什么，这个可以讨论
不过初期是需要我们引导，简单点说就是要我们工作。我们可以先提出很多问题当然也不要太多
这样组织可以不要什么计划，时间表，你提问题就是了，你能解答就答不能就等人来
不过再重点说一下，初期需要我们引导
好了我说完了，再多等下次吧呵呵不然你们会头晕的

[[i] 本帖最后由 wjfonhand 于 2008-4-16 22:51 编辑 [/i]]

[wjfonhand]

jeff:
实际上我们做过两个作业，界面和文档的翻译，结果的问题在那里，答案还没全
表扬一下，Simon这次表述得很清楚

holts:
其实开发我也是很喜欢的, 之所以做文档, 就是觉得这块大有可为.
我的目标就是看到wiki上的文字全部变成中文, 请人翻也好, 自已翻也好, 这个不搞定我不挪窝.
在这个过程中,我的目标就是尽快成为专家.
当然帮助手册和使用手册我们只能选一个
SIMON说的哪个作为FAQ放在WIKI上可以吧?

jeff:
那我们先叫他 维基 吧，先把这个英文消灭掉
FAQ代替不了help，任何软件都是这样的

simon:
我不主张翻译 ，原因是翻译很费神，你提的问题你要解答会自己去找，如果他认为翻译快你会去翻译的 ，但强制翻译就没意思了

jeff:
holts，为了说服他，你告诉simon现在翻译已经达到%了？

simon:
对啊所以需要搬运工 ，要组织 但前提需要素材
holts 你可能不知道做文档时一项很艰难的工作吧

holts:
翻译确实费神,我的时间计划是三年.

simon:
不是翻译是文档 文档要组织要想好怎样组织，我现在的想法只是你万里长征的第一步
但如果你现在就埋头去翻译我很担心你的恒心
原因就不说了
。。。我检讨思过去

holts:
初期只是做很浅的, 隋着对系统的深入,会有高质量的文章的,这个我相信.
当然中途会有反复
至于恒心就是我想成为专家,通过文档之路.
当然开发也是另一条路,到时我们在哪汇合.
我说完了.

jeff:
轮到我了
我说三分钟，然后自由讨论
首先，我们四个人思路不统一。tony和holts的意见是单兵作战，各自研究；我和simon的想法是组织人协作
个人感觉，一会儿可以自由讨论
其次，我们现在遇到了瓶颈，原有的人群有流失，新人没有很好地融入这个团队，我们现有的几个人也没有协力按计划作出完整的东西，下一步没有计划
第三，我们这个季度的目标是在界面和文档上保持与官方步调一致，时间过半，这个目标是否达成了一半，有没有量化的标准和统计数据激励大家继续走下去，这是个问题
第四，simon提到的FAQ和tony正在研究的开发技术，是不是超出了季度计划的范围，我们有没有精力和热情以现有资源再涉及更大的领域
第五，有人提出可以捐献tiny demo server，我们应该感激，但这样一个集中的服务器平台我们准备怎样有效利用，应该有一个实现的承诺
测试组上两周没有进度，下两周没有计划。有动作还是更新那个帖子

tong:
Jeff的思想缜密
但是有个误解，我并不是要提倡单兵作战
强调独立研究，解决问题，我是这个意思
我觉得wiki上可以更加活跃一点
大家可以在上面布置作业，请人回答，或自己回答
目的是提高对系统的功能的了解，和熟练运用
你们觉得这样是否可行？

simon:
我说的是一种组织方法，和目标没关系，我想说的是我们是组织者需要一种机制发挥每个人的能力，想到组员的需求和能力考虑到实际的情况，现在我们的能力有限就最大限度的发挥现在的人员力量。
我主张是在论坛上做但要搬运从论坛搬到wiki从wiki搬到论坛。还要组织下这个工作很简单但很费时间。还有holts你有决心和热情但也要讲方法，没方法你的决心和热情会慢慢消耗掉，我担心的每个人面对孤独忍耐是有限的有更好路走没必要和自己过不去，不过我倒是很赞赏的，换了我也不一定做到。
好了我说完了，你们总结如果没什么话说可以说完了到下一个

tony:
我建议大家多在论坛中提有建设性的问题
这就是组织引导的一种方式

jeff:
我建议关掉msn群
。。。。
其实我们的会议也不一定非要在这里开，有想法在论坛上讨论可能更清楚些

simon:
你叫他去论坛婉转点不就行了
日后可以现在不行现在我们很不稳定
不过日后稳定下来就真的没必要每星期开个会

tony:
完全不一样的功能
这里讨论的东东确实有价值的，也可以总结后搬到论坛上

simon:
这倒是提醒了我holts这是你的工作，让你知道下组织文字也不是很轻松的

holts:
没关系
明白,但我喜欢,至少目前为止:D

jeff:
我们四个人并没有做好协调工作，这个好像要先讨论一下
我今天就想讨论这个问题，希望能有个答案。

simon:
现在真的要做的事倒是翻译，现在的翻译alphi版都不及格

jeff:
我从开始例会开始就没有迟到或缺席过，我在考虑下次我是否参加

holts:
当然参加,不过可以三或四周开一次.
一些零碎的事用maillist.

tony:
jeff你有什么建议

simon:
他不是这个意思他说的是没有会议的作用
会议他的理解是讨论的要结果

jeff:

我们还按原计划把这个季度的事情做完，再想新主意
项目组会议季会：每三个月一次，由各组协调员及受邀的成员参加，用于确定季度内各组职能，决定季度内的工作目标，比如：发布的软件版本需具备的特性；文档，宣传资料，培训等方面的计划等，评估上季工作，组协调人任免，确定下次季会时间。协调员会议：每两个礼拜一次，由各组协调员及受邀成员参加。由各组协调员轮流主持确定议题。用于确定各组的具体工作计划，及组间合作事宜，评估上期工作。组内会议：由各组协调员组织本组成员及受邀成员参加的工作任务分配，布置会议，在每次协调员会议后至少举行一次。
这些东西既然写在wiki上了，就应该按这个做，否则不如删去
我们有组内会议么？没有，我们甚至没有组

simon:
恩如果实际不行倒是可以考虑暂停这个个方式

jeff:
是的，开源要做的事情很多，erp很大是交叉学科。但是我的经验是我们一件事做不好转作其他就能做好

tony:
本来真正参与的人现在也还很少

simon:
他当然知道不过做不到就不要说这个是原则

tony:
这种组织方式应该没有什么问题

jeff:
是的，但是它写在纸面上

tony:
我以为最重要我们这几个协调人自己对这个系统本身了解还不够啊

jeff:
就像iso9000质量体系认证，每一句话都是对的，但是每一句话都不是可执行的

simon:
我的经验告诉我这个组织办法除非开公司不然肯定不行，因为你不能给别人施加压力
真的我们是自愿组织，来的人我们都应该想象他们是客人

tony:
我们的组织方式是没有问题的，但是内容。。。

jeff:
问题不是组织方式，不是内容，是执行
每次协调员会议是不是只讨论季度目标
我觉得应该是
但是我们现在不是
simon说他忘了我们的季度目标是什么来着
holts一直拿不出来我们翻译进度的百分比
那我们开会做什么？
前一阶段我很激进，想按模块大家同步进行，现在看来这种硬性分配任务的方式不适合开源的自由协作，holts适时地指出了，这很好
所以我们要调整到新的方式，它是什么？
我们要改变的不是我们的组织方式和季度目标，而是我们日常协作完成那个目标的具体操作方法

tony:
可不可以我们集中力量先完成一项任务
把软件界面的翻译一起改进一下，不分组了，一起来

jeff:
如果我们本季度的任务是否完成到时候说不清，以后也好不到哪里去
界面和文档，我们只做这两件事

tony:
svn兄弟们学会用了吗
界面翻译的同步要用到的
希望我们几位协调人在以上两个项目的工作上能起到表率作用

holts:
说倒目标的专一,没有谁比jeff做得好,这点值得大家学习, 我将再一次把我的注意放在wiki上.
界面翻译的要求对系统全局的把握, 这个目前以我的功力还不能做这个工作, 至于SVN只用到一两个命令.

tony:
jeff我觉得今天简化操作和目标还是非常好的

simon:
首先我们要明确目标定一个确实可行的目标出来

tony:
目标就是文档和界面，大家一起弄本季度完成

simon:
只要一个就是翻译
这个目标还是很难的不要想太多，我们就只有4个人，还是兼职
首先我们得找bug和需要改进的方法，翻译的方法我现在还不知道呢
需要改进的地方
进度的控制，检查的时间，讨论的方式
版本的制定策略

jeff:
我想要个列表，放在wiki的首页，即时更新
你们怎么想东西都这么简单，要做一件事很简单但要做好都不是简单的
原文档 | 中文名称 | 翻译 | 校对 | 定稿
要做的 已经完成的 正在进行中的 一目了然，推荐相关人从这里入手参与进来，把自己的名字更新上去
可以不按模块，按文档或界面为单位是否可行？

simon:
首先是找bug怎样通知什么时候总结，在哪里
因为中间还有个讨论这个是不是翻译错了
但千万不要开会，尽量用论坛或者wiki
这个要闻tong
原来的的翻译是tong搞得，tong你先大概介绍下怎样翻译的吧，在论坛里

tong:
开会时间还是控制下为好
holts, Simon, jeff今天会到这里可以吗

[simon]

这是上一年最后一次的会议记录了，一年时间过去了。没想到用了一年的时间才做了一个测试版的翻译，不但是不完全的翻译，还没经过别人的校验。至少我自己就不同意发表。

如果说实际的进展：翻译、中国科目表（还未完成）和中文报表的显示。这三个实际的东西，当然还有 ------- 像oldrev对开发模块的认识。

算不算快和有收获，看你相对于什么？

个人认为这很慢，自认自己是一个比较有耐心的人，但我还是不满意现在的进度。
我甚至都怀疑为了什么？？如果是一个舞台这明显是一部超长的连续剧，如果为了交更多的朋友还不如参加舞会、会议等实际见面的或者在网上乱窜。

也许像oldrev和tony说的为了爱与世界的和平。大家不要笑其实为了爱与世界的和平是一个信念，就想信佛一样，大家绝大部份人都进过庙但问心一句你信佛吗？我看大部分都不能得到一个肯定的答案。

如果这问题问到我，我的答案是不信。可见要认同一个信念有多难，就算认同要身体力行就更难。不过不身体力行好像也不叫认同最多叫知道。

和tony谈这事好像禅语又好像原地打转。

大意是不能强求人家怎样而且就算你强求也没结果这样做不像是开源。

我倒是认为这是儒家思想己所不欲勿施于人，己所欲也勿施于人和开源结合的怪胎。

说了这么多废话说点实际的

我以后不会在msn群回答任何问题，有什么要问的发到论坛上吧

老实说我不喜欢这种松散的组织方式。就像一句老话说的“革命不是请客吃饭

[[i] 本帖最后由 simon 于 2009-5-13 00:50 编辑 [/i]]

[digitalsatori]

Simon凌晨1点还在发帖，幸苦了。也的确，这一年来我们的论坛里确实太安静了点:)。一点气氛也没有。

Simon以及各路高人，帮忙想想有什么可以一起完成的“任务”，我们来活跃活跃气氛，建立一个气场。