L10N migration to transifex.net
Stephen John Smoogen
smooge at gmail.com
Fri Feb 25 00:17:00 UTC 2011
2011/2/24 Karsten Wade <kwade at redhat.com>:
> Caveat here: I wasn't in any meetings, had no foreknowledge of
> anything, and am not involved in any of these activities. I'm an
> observer who just read that IRC log and some mailing list threads over
> the last few days. I'm going to attempt to keep my reply within the
> confines of these recent activities and my general knowledge of how to
> do things the open source way.
> The IRC log in question:
> On Thu, Feb 24, 2011 at 04:32:37PM +1000, Ruediger Landmann wrote:
>> I'm a little confused by the nature of the meetings you're talking about
>> though. I was only at the docs meeting, and that didn't seem to include
>> any weighing up of options. For that matter, the L10n meeting didn't
>> either, based on the logs -- it reads to me more like a fait accompli.
> I think you are right, and there was clearly confusion about the
> meaning of the vote. My reading is that everyone understood what they
> were voting for at the end. It was clear people felt it was rushed,
> uninformed, and risky to proceed. However, the plans do seem to have
> seen adjustment in response to L10n concerns.
> I read the results of the L10n meeting as:
> Infra: "We really hate to do this, but we have no choice and no time
> to do anything other than move all L10n services to Tx.net
> immediately. Sorry about the late notice."
Hmm then I was not communicating very clearly:
The issue was that transifex has been an ongoing problem for the
1) It is a moving target. Development upstream is fast moving and
adding new features that translators want.
2) We are really really behind on upgrades. There have been multiple
groups who have stepped up, started to do it and then had real life
hit them with some sort of curve ball. So what started out as 0.7 ->
0.8 became 0.7 -> 0.9 and now would have to be 0.7 -> 1.1. We had
multiple people who for the last 3-4 months have said "We would be
happy to upgrade, but we aren't really able to do more than that."
3) We could have kept the old transifex going but this seemed to cause
more problems than it solved. There have been many items where people
were 'hamstrung' with the current software and wanted us to move to
4) In looking at Infrastructures current status I realized that we
were spending a lot of time on triage and not moving forward with
projects (and in some cases were moving backwards). We looked at what
our core missions were and what we could have other people do better.
And it meant pruning back stuff we were not doing well so we could
focus on getting things done elsewhere.
Now where we did not hand off things well.
1) We asked people in L10N and docs about it but did not make sure
that was communicated clearly with their groups. That meant we ended
up with thinking we had agreement but didn't.
2) Web software is hard to keep up with unless people stick to it.
Volunteer infrastructure scales well for certain items but has had
problems with long term projects. [This is no different than dealing
with drupal, plone, most Ruby on Rails etc. If your software is
updating every 3-6 months it is hard to deploy in a production
environment unless you have dedicated people to keep up with it.]
3) As I said in my blog post on this and some other items:
Now usually after a post like this occurs, we get a bunch of
volunteers who will say "We can take this over." I am asking people
not to do this, because frankly volunteering under pressure usually
means leaving when the pressure is gone. We have gone this route
several times before, and its not something I think is sustainable.
We will look for volunteers who can replant the services, document
them, build out a staging and production service and train OTHER
volunteers on them so that any replacement service has a chance of
Stephen J Smoogen.
"The core skill of innovators is error recovery, not failure avoidance."
Randy Nelson, President of Pixar University.
"Let us be kind, one to another, for most of us are fighting a hard
battle." -- Ian MacLaren
More information about the logistics