> 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. Well, from my live discussions here with Javier Sola, I would say, pretty rudely that they actually don't care a sh^W second about the tools, but more about the goal to achieve...which is exactly what I also have in mind. If Wordforge people (I'd like us to think about Wordforge as the whole project...Pootle being only one part of that project) have chosent python, I guess this is because they're more comfortable with it. In short, it was fitting their needs. And I actually don't want us to fall in the usual geek trap of choosing tools before having the goals. > 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. Certainly not, I think. We actually want things to advance and I would say that we are not *that* in a hurry. After all, it's like 13-14 years that Debian lives without i18n infrastructure. We can wait for a couple more months, or even one year. As long as the GSoC part of the project achieves the goals it will be assigned if the project is accepted, this will make things progress. > 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. Well, that would make things clearer, yes. I understand that this may sound as a decision, which is actually the hardest thing to achieve in Debian, but we need one to go on. And seeing all actors of the project agree with this and reflect this in their actions is what I actually expect. > > 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. It's one. Wordforge has enough interesting "bounties" they want to achieve that can be set as goal for the GSoC part of the project. > 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. What you can do right now is going through WordForge site and get here and there information about the things they'd like to see achieved and see which of those mostly feed what you feel the most able to do. > 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? Mostly interactions of translation work in different projects such as Ubuntu and Debian. And also, the internal culture of all the biggest l10n teams in the project (all of them have deeply confirmed this as an important feature for them) > 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. OK, point taken. To be fair, not being in a live discussion certainly doesn't help in that matter, especially when I'm actually in a complete hurry to get as much things as possible to be done during the unique occasion of Debconf.
Attachment:
signature.asc
Description: Digital signature