Hello, > Be ready that it is now *very likely* that we will go for working with > the Wordforge people and that it is also *very likely* that the work > we will expect should be on some part of the needed implementation > that we have to discuss with Wordforge developers. If the consensus is that this is the way to go, that's fine with me. Besides, as far as I can tell, Wordforge people look favourably towards Python, which is my language of choice, so I can probably be fairly productive working on Wordforge projects too. I would like to point out basing the project on Wordforge is a risk which must be consciously evaluated. With a few days of sketching and prototyping I can predict fairly accurately how much I can do in X days working Y hours per day, say, using Zope 3, which I have been working with for the past two years. However, I cannot predict how much time it will take for me to familiarize with Wordforge, how much faster/slower my rate of development will be in its context, how much communication with its other developers will affect productivity, how much time it will take to improve Pootle's performance, etc. Say, if I am more than twice slower with the technologies Pootle uses than with Zope 3 (although this is unlikely), it's almost certainly a net loss for this project. In short: I could almost sign my proposal as a formal contract, but it would be hard to provide guarantees if we use Pootle as the base. Would you like me to update my proposal to reflect the stronger relationship with Wordforge? I don't see much point in doing it (that document will not significantly affect our future work), but I feel obliged to ask. You will notice that I am evaluating strictly the outcome of this project and not taking into account what Pootle gains from the cooperation. This is because the project is already not a small one, and unnecessarily making it more general will hurt the results. Of course, I want to help Pootle succeed as much as anyone, but this must be a conscious decision. By the way, I see some positive indicators in Pootle: there are unit tests, which is always a very good sign. The coding style is OK too (although the 2-space indent bugs me a little). Kid templates are used for HTML -- these will do fine. However, it is a bit more difficult to get a clear picture of the architecture quickly, so I can't say much about that. I want to make it clear that I am not a cowboy coder. Actually, you can probably already tell that I love discussing things ;) Discussions are essential so that one knows what he is doing. On the other hand, "discussion mode" (particularly "let's discuss!" as opposed to "let's discuss what to do with X") is different from "getting-things-done mode", and that's what I had in mind with that comment at the end of my previous email. > > I am still not sold on the 'translation owner' idea, I think that > > would be too rigid. Of course, this can be made configurable. > > Even though this sounds too strict, I will hereby add that this is > kind of a mandatory feature. Of course, we will also need all the > needed mechanisms, including automated ones, to actually *orphan* > translations when translators are inactive on them. OK, it is a requirement then. But I am still not convinced it is a good idea. Restrictions are supposed to solve problems and I fail to see what problem this feature solves that is not addressed by the ordinary review process. Could you provide a particular example of such a problem? I would suggest to only introduce the requirement when (if) we see several instances of a problem which would be solved by it. In that case, we lose almost nothing. On the other hand, if the restriction reduced the translator volume, say, by 70%, this would be a huge loss and we would never know. Please don't take this personally, I just want to either assure myself that this is indeed needed, or to show you that it is not. > You have been warned. I already told this may sound a bit early for > people wanting to jump into coding in a very geeky style (small pun, > no offense intended). You're not alone wanting to jump into code, so > be sure that things will happen....but talks and discussions HAVE to > happen. This is what makes long-term viable software. To be frank, I do not really want to jump into code. I do know that in general I tend to talk too much, so I'm trying to compensate ;) As I have noted in my proposal, I like design, but I don't favour big design upfront and prefer incremental software evolution and feedback-based approaches, which is far from "jumping into coding in a very geeky style". It's all about eliminating risk. In comparison, I see an abstract design problem as a theorem, and code as constructive proof. The idea is that it is risky to build a huge system of theorems without at least sketching the proofs. The proofs also hint at new theorems that you may not have thought of before. Obviously the project can't take off at all until we decide if we want to start from scratch or patch another project. I suggest that for the moment we concentrate on this question rather than interface/permission issues (which will be very important in the near future, but not right now). Perhaps someone else could look into Pootle and share their impressions. -- Gintautas Miliauskas http://gintasm.blogspot.com
Attachment:
signature.asc
Description: PGP signature