L10N migration to transifex.net

Fri Feb 25 00:44:23 UTC 2011

On Thu, Feb 24, 2011 at 02:08:40PM -0800, Karsten Wade wrote:
> 
> Definitely there was some process breakdown and some lack-of-process.
> 
> It seems that it wasn't an active open community discussion between
> Infrastructure and affected teams about problems with maintaining
> translate.fp.org and how to fix them. This all could have been
> discussed over the preceding months, presuming that were possible
> ... and I am going to presume it wasn't, that we are here based on a
> series of best-efforts and best-will from people involved.  Does that
> make sense?
> 
So... you'll need to contact mmcgrath for exactly where, with whom, and when
previous discussions took place but discussion had been taking place for
quite a while.  A lot of people realized there was an issue when this ticket
took 9 months to resolve:
  https://fedorahosted.org/fedora-infrastructure/ticket/1455

Enough that gomix, beckerde, other translators, and I discussed the
situation at FUDCon Chile last year and I opened this ticket:
  https://fedorahosted.org/fedora-infrastructure/ticket/2277

The first meeting that we (infra) discussed that ticket at, mmcgrath said
that he'd tried but failed to find someone to maintain transifex in infra
from the l10n team.  He and I tried to think of someone that we knew
personally that could do the job and via email got in touch with beckerde
who agreed to work on packaging and migration of the new transifex.

Since beckerde was new to Fedora packaging and transifex dependencies had
changed it took a while to get things working but with the help of other
latam packagers we got packaging sorted out eventually and started to test
upgrades on the infrastructure staging servers.  The version that's being
worked on is an older version because newer versions of transifex would
change the translation workflow (the recent talks have made clear that the
change in workflow is mainly for the developers of the translated software
rather than the translators.)

{{A side thread to this story:
In the F14 time frame (ticket 1455 time frame), the translation teams made
some valid noise about the problems that the version of transifex we were
running were causing them.  At that time, glezos, stickster, some people
from l10n and infra analyzed the possibility of moving to transifex.net and
decided that it was possible but were divided about the desirability.  We
were able to upgrade the FI instance of transifex which deferred the
question.}}

Sometime between the tests on stg and fudcon some of infra starts worrying
about how we're going to continue maintaining transifex.  beckerde is
signing up to work on packaging the software and deploying it but we're
still running several versions behind and we don't have in-house knowledge
on how to fix issues in the code.  Moving to the newest version is caught in
the workflow changing problem that, since infra isn't involved in using
transifex, none of us know what is changing or how to approach l10n about
changing their workflow to accomodate it.

{{Next side thread:
mmcgrath leaves as infrastructure leader.  This leaves us shorthanded as
we were already running close to capacity and mmcgrath was also a good
community leader who was able to entice and induct volunteers.}}

At FUDCon, smooge, skvidal, ricky, CodeBlock meet with igorps and some other
translators that are present and talk about moving off of Fedora hosting
transifex if glezos still wants to host us.  We talk about a gradual shift
at that time.  Later, infrastructure members talk to glezos on IRC and more
with each other.

{{Third side note:
At FUDCon, infrastructure realizes how deeply overcommitted we are.  People
at "The Next Big Infrastructure Project" were excited about a bunch of cool
ideas for new services but we realized that to do any of them, we needed to
either get rid of some of our present responsibilities or get new long-term
sysadmins to help out.}}

On IRC, post-FUDCon, we talk with glezos and firm up plans a bit more.
Someone convinces everyone else that moving a little at a time doesn't help
anyone because there's a lot more confusion if we have two separate places
to translate at, two procedures to integrate the translations with software,
etc.  Fedora Infrastructure has a meeting where we figure out how we feel
about migrating transifex service to tx.net.  We're in favour.  glezos to
carry the idea for coordination with the l10n team.

At this point things start moving fast.  Content is synced to transifex.net
for a Proof of Concept, meeting with l10n is setup to talk about migrating.
Decision is made to migrate pre-F15 because the FI-hosted transifex is too
painful, coordination with developers who will need to pull the translations
on newer versions of transifex is talked about, duties are assigned for
migrating, setting up teams, packaging the client-side tools for developers,
etc.  That brings us pretty much to the present.

What I draw from all this is that:

1) Although communication was present, it didn't involve everyone touched by
the change.  That's pretty hard to achieve in any circumstance but we could
try to make it better.  From infra's point of view, transifex was being
provided by us to the Fedora l10n team which is not entirely accurate.  So
there needs to be a way to figure out the chain of dependent people.

2) In some ways, people were just waiting on a decision.  Fedora
Infrastructure was not able to update to the newest transifex because of
workflow changes.  However, once it was decided that Fedora Infrastructure,
therefore, couldn't upgrade (or fix) transifex at all, it was easy and quick
for people on l10n to make a decision about changing workflow to get more
reliable service.

3) It seems that maintainance is harder to recruit people to work on than
a new direction.  That new direction can even be a continuation of the
current direction (move to a newer transifex on transifex.net) as long as
it's seen as a decision needing certain definite actions.

> Jared and Paul said in the meeting log multiple times that we needed
> to avoid people being surprised by the situation, but unfortunately
> that wasn't very likely. The timing involved made it a certainty that
> some people were going to be squeezed, surprised, and upset.
> 
> I perceive the following items as fait accompli before that meeting
> happened:
> 
> * Fedora Infrastructure decided they could no longer provide
>   translation services.
> 
> * To meet their service obligations, FI put in place a plan to move
>   translation services to Transifex.net.
> 
> * Fedora Project leadership were essentially in agreemen with that
>   plan.
> 
> I didn't see the following items as fait accompli before that meeting:
> 
> * Future of hosting our own translation tool of any kind on
>   fedoraproject.org. Clearly we can revisit this decision, clearly
>   people wanted to.
> 
> * Ability for resourceful people to step forward and make it possible
>   to either not move for F15 or move back for F16. For example, you
>   seem to have responded to this by seeking new, on-going resource
>   commitments.
> 
> * Commitment of L10n leadership toward any particular plan. People
>   came in to that meeting with different opinions and agendas, but
>   seemed to come to consensus by the end.
> 
One note here -- in the meeting skvidal made a statement about what would
happen if we didn't move to transifex.net which was both harsh and true.
But it shows that there's another thing that wasn't quite a fait accompli:

* Infrastructure could have continued to host a transifex instance
  but we could not continue to support it (with updates, with fixes for any
  of the numerous open bugs, with the ability to make it more reliable,
  etc).  skvidal's projection was that such a strategy, while possible,
  would eventually lead to our instance of transifex preventing work from
  being done at a time when nothing could be done about it making everybody
  upset.

> Community supported infrastructure doesn't have to be of a lesser
> service level overall, but things tend to be less formal across the
> board about change impact on community participants.
> 
> One lesson to pull from this situation is for *every* service provider
> (which inclues L10n, Docs, Infrastructure, et al) to have a change
> management process in place that:
> 
> 1. Exposes problems (needs for change) early and often.
> 2. Encourages discussion and work so decisions (why, how) are visible
>    to all affected.
> 3. Makes sure affected teams are not surprised by developments.
> 
I'd like to see an infrastructure threat board.  Here's an idea of how that
would work:  The threat board would have services that have no dedicated
person working on them as level red, things that have one or two  person
working on them as level amber, less than five in yellow, and green at five
or more.  A standing policy would be that things in amber or less are in
danger of being dropped and we need to work on how we're going to gracefully
drop, outsource, or reassign-drum up help for them (for instance, we can't
very well drop koji support so if it was in amber, someone would have to
come across from something else that they were doing to work on that).
Perhaps once a month, we'd post services that are not green to
fedora-devel-announce and if we didn't get its levels to rise in X amount of
time, we'd be free to enact our contingency plans if we chose.

-Toshio
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/logistics/attachments/20110224/4cecb5fc/attachment-0001.bin 