Quoting "charles-h.schulz" <[EMAIL PROTECTED]>:
Hello,
I hope you're all having a good week-end. It's going to be a week I am among you and I didn't see the time passing by! Thanks to the translators and the community to make this tour a real pleasure!
It was my pleasure to serve you as a translator as well. :-)
-How can OOo as a community and as a product improve?
Ok. This is a big question, but let me give you what I feel about the current OO.o in general (both as a community and as a product), and this is strictly from *my point of view* only. Also, my view does not represent the ja community's view.
First, I personally believe that OO.o as a product is improving at a
reasonably rapid pace. Some may believe the rate of improvement is not as fast
as they hope because their favorite XYZ feature is not being included or their
most annoying bug is not being fixed. But to me it is satisfactory. I like
what I see in 2.0 Beta, and I'm looking forward to seeing what comes beyond
2.0.
Unfortunately, these product improvements are mostly as a result of the effort made by the Sun engineers, and community participations are still rare outside of porting and localization. I strongly believe this needs to change.
From the Sun development side, there should be some effort to clarify the process required to contribute a feature/enhancement into the main tree. I have in the past submitted some patches to enhance Calc's functionality, but I also observed some confusion within Sun as to how to deal with my patches (it was obviously because I didn't follow the right steps). Since then, I have learned a great deal about the development process for introducing a new feature/enhancement, but unfortunately most of it is still undocumented or unknown among the community participants (the specs project is a good example).
From the community side, we must break the myth that for whatever feature we want in OO.o, we must rely on Sun to implement it. Some features are technically easier to implement (good starter project for a community coder), while others require an intimate knowledge of the internals thus are best left for a Sun developer. Sometimes, it is a good idea to dive into an issue, submit a patch and lobby for its inclusion, than complaining loudly until somebody notices three years later.
But the key, I think, is more and more communication and collaboration between Sun and the community participants, and it requires willingness from both sides. Working together also improves trust between the two parties, and in the end OO.o as a whole will benefit. But both sides must make the effort.
I understand this is not specific to the ja community or the NLC, but I just felt that I needed to share it with you since you asked that question.
-How do you feel about forming an Asian CJK native-lang group? This group would be composed of three projects (ja, ko, zh) each of them keeping its strucure but sharing ressources on technological and marketing aspects.
I admit I am not very active in the native-lang front, but I for one support this idea.
Kohei
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
