YAMAMOTO Kengo / YamaKen
yamak****@bp*****
2006年 8月 6日 (日) 13:10:44 JST
ヤマケンです。 uim ＠ fdoの方にもメールしましたが、以下のようにuimプロジェクトを構 成する各種サービスを移行したいと思います。日本語でも構わないので ご意見お願いします。 日本語で読みたい/この英文意味不明 という場合は訳しますので言って ください。 I have recently registered uim to the opensource project hosting service of Google Code, as experimental use. http://code.google.com/p/uim/ Committers, please let me know your Gmail account to add you as a project member (members that I know the account is already added). And all, please let me know your opinion about my suggestion of project hosting services transition: - svn repository Move to Google Code once the import/export feature is supported (and became stable). - File release Move to Google Code once the feature is supported. - Bug tracking system Continue using freedesktop's Bugzilla until Google Code's issue tracker is well revised. - Mailing list Move to Google Groups once agreed. - Wiki Move both English and Japanese wiki to Wikia, once agreed. Details follow. * Google Code After I tried every features of Google Code and traversed some discussions, I realized that the system is simple, useful, effective and I believe that it will become better beyond sf.net. Notable issues are: - Gmail accounts are used as developer accounts - only Subversion is supported (with some Subversion developers) - svn import/export feature is planned and having high-priority - file release feature is planned - mailing list service is provided via Google Groups (and useful) - a wiki service is being discussed (not coming soon) - Google's own tag-based issue tracker system is simple, useful and flexible - the issue tracker lacks activity notifications for uim-bugs list regardless of issue's owner - the issue tracker lacks dependency management feature (although dependencies can be recorded as labels such as 'DependsOn-617', only direct ones can be searched) * Mailing list Google Groups had been born again as a mailing list service in addition to USENET news browser. Although it has non-simple and screen-region wasting decorative UI for web-based archives, it is acceptable and useful than sf.net's. It offers various useful features that we don't have in current service, such as serial ID for each messages ("Subject: [uim 3259] "), per-thread subscription, message rating for important issues and message deletion by moderator. So I want to move to the service. Especially the serial ID feature is a strong reason to help our development to mention a message in short form at source code, commit log, and so on. I created following lists as experimental use. Post any messages to the lists to test the behaviors. I'll remove all testing messages before actual use. - uim-en ('uim' is rejected since at least 4 chars required) - uim-ja - uim-bugs - uim-commit - sigscheme-ja * Wiki We have two separated English and Japanese wikis currently. http://uim.freedesktop.org/wiki/ http://anthy.sourceforge.jp/uim/ And it is having several problems: - Japanese wiki deployed must be maintained by our own hand, including security updates - Since the implementation Hiki used for Japanese wiki is not major, learning cost for its writing rules and UI behaviors are not reusable for other wiki contents edition - Likewise, the implementation MoinMoin used for English wiki is not major, at least for Japanese - Hiki lacks change history feature (only provides most recent diff) - The Japanese and English wiki cannot share its contents To resolve above problems, I would like to move both wikis into Wikia (http://www.wikia.com/) which adopted Mediawiki as its system. It is beneficial since: - System maintenance free - Since it is using Mediawiki, the knowledge about editing and UI can be shared with ultra-major Wikipedia. This means that Wikipedia users can easily edit uim wiki, and uim wiki users can share their time investment with worthful Wikipedia expertization - As most major implementation, Mediawiki will be improved well - Multi language page for one article is supported. This feature is useful to share information between languages - Multilingual text handlings are probably most sophisticated through Wikipedia experience - uim-independent generic contents about input methods such as 'preedit', 'input context' and 'conversion engine' can easily be generalized into Wikipedia without text format conversion - Any language must have translated Mediawiki documents Please let me know your opinions. ------------------------------------------------ YAMAMOTO Kengo / YamaKen yamak****@bp***** FAMILY Given / Nick
