愿意奉献时间精力来维护fcitx的请进来

xw_xiao

Post by biAji
个人用互联网N年的经验来说。。宁可被盾，也不要放在国内服务器上~~

googlepage已经被盾了吧

SF是已经解盾的，相对来说，比较安全。

投一票。

联系一下sf上的管理员，把sf上的项目用起来吧。

elisir

Post by dogking

http://gforge.oss.org.cn/
教育网访问很快，其他用户也可以先看下访问速度怎样。

济南网通 768K 访问gfore.oss.org.cn，尝试下载东西，在没开其它下载的情况下，最高下载40KB左右，最低23KB/s。

感觉还是放在sf上好点，如果教育网的访问速度慢，也可以在国内这个网站上做个镜像。

dogking

Post by elisir

感觉还是放在sf上好点，如果教育网的访问速度慢，也可以在国内这个网站上做个镜像。

这样也好，做个镜像方便国内无法访问到sf的用。也可以当作fcitx代码，文档之类的备份。这样安全很多。开发之类的放在sf上，国内这个用来备份。也可以放针对不同发行版打好的包。

ailantian

不知道大家能不能弄个邮件列表，或者其他的什么联系方式，对输入法比较感兴趣，想做一个旁观者：），别骂我，我想先熟悉一下输入法相关的东西，之前不能做任何保证。
也真心希望这个“新”项目能持续做下去。

karron

还是建议放到sf,或者googlecode上, 国内的最多作为一个镜像.

acguy

我觉得开源的东东，不是这么组织起来的。
一般得有个牛人默默接手，做了一些工作，再释代码出来，取得大家信任，大家团结在牛人周围。项目得以壮大。

组织架构再完美，没人动手code也是白费。

westfox

我觉得还是需要一个人来主持协调一下。
dogking, 你愿意站出来主持这个项目吗？
看来你是教育网，学校里的应该时间会多些。而且可以拉身边的人,呵呵. 我自己的时间不是很多.
我觉得代码放在http://gforge.oss.org.cn/projects/fcitx/.  就足够了,再增加一个镜像 问题是这个支持导入吗?我建议将http://sourceforge.net/projects/ ... ors.redv.com/fcitx/  的tag都尽快导入,就可以开工了..

我已经申请加入http://gforge.oss.org.cn/projects/fcitx/里的commit maillist,希望感兴趣的也加入,
- 另外应该有一个bug mail list

dogking

Post by westfox
我觉得还是需要一个人来主持协调一下。
dogking, 你愿意站出来主持这个项目吗？
看来你是教育网，学校里的应该时间会多些。而且可以拉身边的人,呵呵. 我自己的时间不是很多.
我觉得代码放在http://gforge.oss.org.cn/projects/fcitx/.  就足够了,再增加一个镜像 问题是这个支持导入吗?我建议将http://sourceforge.net/projects/ ... ors.redv.com/fcitx/  的tag都尽快导入,就可以开工了..

我已经申请加入http://gforge.oss.org.cn/projects/fcitx/里的commit maillist,希望感兴趣的也加入,
- 另外应该有一个bug mail list

westfox抬爱了，我的水平很有限，经验也不足。是没有能力作项目号召者的。
我想是，先做到帮忙注册这个项目，哪怕最终代码放在sf上，GForge只是作国内镜像也好。或者GForge上这个项目最终没有被大家作镜像使用也没所谓。

我只是想，作为一个fcitx多年的使用受益者，想为它作一点点力所能及的事情。
我希望一个有开发经验和项目管理经验的朋友主持。我时刻准备着让出管理员权限。自己作一些力所能及的事情。

希望fcitx的未来充满光明，让小企鹅永远活在俺的os里~~呵呵

mrkissinger

服务器其实是一个末节问题，只是我手里有这样的资源，所以才提起。

关键的问题其实是文档。
一个越来越庞大的软件，没有文档是不可接受的。一个开源项目是否能真正获得社区的支持，文档是决定性的问题。

在下有一个观点，即一份没有文档的源代码，意义是非常有限的。
多数程序员都可能碰到过这样的情况──一份可以运行的代码交到了手里，但是却因为缺少文档而无法很好的把握它，结果还不如从头做一次。
对于国内的程序员做开源项目就更是如此。本来大家都没有很多的精力，好不容易想改进一个bug或者功能，结果半天找不到对应的代码，结果就放弃了。这样，社区的力量其实就没有真正利用起来，而是白白浪费了。

做过大项目的朋友都知道，文档不仅仅是代码注释，更重要的是对整个软件的整体把握。试想，不明白MFC、Swing、J2EE的架构，是不可能用它们真正做出可靠的软件的，更别说去hack了。
fcitx虽然规模不是很大，但是也有2万多行了，而且应该会进一步膨胀。没有清楚的架构描述，很难让新手快速加入。
我说的“新手”，并不是初学者，而是对项目不熟悉的程序员。他可能是很有经验的程序员，比如在下吧，写程序也有10多年，但是要把握fcitx这么一个规模的项目，我估计需要半个月到1个月才能有基本的概念，真正做到了然于胸应该需要半年的时间。
这样的时间门槛会将很多人拒之门外。

所以，当务之急是文档。

解决的办法：

1. 将现有fcitx代码加上初步文档。
做这件事情的最好的人选当然是yuking兄，熟悉fcitx代码的同仁也可以参与。
需要完成的文档包括：
- 目录、文件说明：即哪个目录是放什么文件的，每个代码文件是什么类别的功能。
- 模块、函数级的说明：我简单看了一下py.c(貌似是最大的一个文件)，yuking兄采用的是传统的注释方法，没法直接用doxygen这样的工具直接生成文档，改一下格式问题不大。
- 工作原理描述：postfix的文档做得很好，看了就能很快把握系统，值得借鉴。

有一个问题需要提一下，yuking兄是使用中文来写注释。
虽然开源社区一般建议使用英文来写注释，不过fcitx主要面向华语社区，所以倒也无所谓。
问题在于中文有不少编码，目前yuking兄采用的是GBK/GB18030，而linux默认一般是utf8，这个需要统一一下。如果考虑可能有台湾香港或者海外华人参与，个人觉得utf8更好一点。

2. 现有代码可重用分析。
我没有具体分析，但是yuking兄说架构一直没有功夫好好设计一下，那么可以猜想下一个版本的fcitx应该有更好的架构。
目前的代码似乎是按照功能、输入法来划分模块的，相关的黏接代码混合在输入法模块中。
通过分析，可以把这些代码进一步细分，把低耦合的代码整理成可重用模块，为下一个版本做铺垫。

3. 做出版本规划。
好的项目要良性发展，版本规划是不可或缺的。
linux/mozilla/firefox/sun java都是有很详细的版本规划，这样开发者在写具体代码的时候可以平衡当前需求和未来需求，减少走弯路的可能。
fcitx的版本目前是3.5，但是我一直不是很清楚具体版本的区别，功能增加也有明显的个人色彩。
在只有yuking孤军奋战的时候倒也可以这样，但是如果有一个team来开发，如果没有大家都明白的开发目标，就很难进行协调。所以版本规划必不可少。

4. 进行不同分支的开发。
版本规划完成了，并不是大家都照最新的版本去开发（事实上有这样的情况，程序员对新鲜的东西更有兴趣）。
linux的2.4和2.6版本是并存的，而且开发都很活跃，firefox 2和3也是这样。
如果fcitx继续开发，应该是分为1个不断增加功能、解决bug的版本，和1个重新规划架构的版本。老版本在增加功能的同时，因为明确了新版本的需求，就不会随意的写代码，会充分考虑新版本的需要，这样就可以得到可重用的新功能，同时适用于新旧2种架构，满足激进用户和保守用户的不同需要。

5. 相关文档的整理
postfix网站会给出smtp的标准文档，gaim/pidgin网站给出msn协议的文档，这些细节其实对项目成败有很大影响。
既然我们知道今天已经不是软件英雄的年代，那么如何成功的吸引社区力量就成为一个很重要的问题。其实1-4点都是围绕这个指导思路来设计的，而相关文档这一点是最容易被忽视的。
前面说了，一个好的程序员可能只是有很好的编程水平，但很难要求他在某个项目涉及的具体领域也很熟悉，提供尽可能完善的相关文档，会降低程序员参与项目的门槛。
拿fcitx来说，起码可以提供一个XIM协议的文档（链接可能面临访问速度、文档被删除等问题）。

目前个人认为fcitx缺失的几点都阐述完毕，待有志同仁商榷。

dgod

1 文档当然要做的，注释风格修改一下也不成问题
  GB编码是yuking一直坚持的，也是这次事件的一个诱因，我的意见是坚持下去（编码问题无伤大雅无碍大局）

2 代码重用性是不好，但在3.5版本就没必要改动了，等熟悉了之后再做

3 fcitx其实是一个用户驱动的项目，太详细的规划反而是种束缚

4 我的意见是逐步重构，而不是完全来个新的

5 文档是好的，但提供XIM协议的文档是自杀，我想没有几个人能理解它，包括其他输入法的作者，没几个人敢去碰他。
我们的文档应该是一些在fcitx上进行输入法开发的文档，比如怎样注册一个输入法，怎样提交输出结果等，怎样读取系统中的配置，怎样和其他输入法进行配合等。

mrkissinger你有很好的想法，挺适合担起责任来。
我觉得可以行动起来了，否则热情会很快消失的，只要开始，我们最终会走到一起。