L10N migration to transifex.net
kwade at redhat.com
Thu Feb 24 22:08:40 UTC 2011
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."
L10n: "Wow, that is really surprising, I don't know if I support
this all the way and want some protection in place. I see it's
too late to do anything else for the F15 cycle so I'll support
the move with the agreement that we revisit this discussion as
many of us would prefer to have L10n services hosted by the
Fedora Project if we can."
From what I read in that log, the lateness in the F15 cycle meant a
program mangement and project leadership decision had to be made,
which was really to support what Infrastructure had already decided
made the most sense. Bringing it all-of-a-sudden to L10n with a
mysteriously-valuable vote in the wings seemed to add to the
However, do I see that the whole discussion has raised some items that
were not fait accompli, which I cover below.
> On the subject of the L10n meeting: I'm in a difficult position. I'm
> proud to number some of the people who participated in that meeting
> amongst my friends, so I *really* don't want to single out specific
> people or comments in the log. Also, IRC doesn't capture the nuances of
> human communication very well and I can't discount the possibility that
> I'm badly misreading the tone of the meeting. So, all I can do is invite
> anyone who's interested to go and read the log at
> One specific thing in there that does confuse me though is the vote that
> occurs about 96 minutes into the meeting; I don't really understand what
> was going on there or how it fits together with the idea that the
> decision about where to host Fedora's translation infrastructure wasn't
> just up to the Fedora Localization Project. I'd appreciate clarification
> from anyone who was at the meeting.
Thank you for your email, it is an excellent summary of the
situational concerns, has some good resolution, and shines light on
the path we can keep moving down.
> In conclusion, I'm really conflicted here, because on the one hand I
> don't want to strain friendships or to be obstructionist, but on the
> other hand I feel compelled to speak up about a decision (and a process)
> that disturbs me.
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
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
* Fedora Infrastructure decided they could no longer provide
* 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
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
* 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.
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 have seen the Fedora Program Manager and various teams work this
process manually over the years, but I'm not sure how many teams have
a change management process in place so they can reduce surprise with
other Fedora teams?
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.fedoraproject.org/pipermail/docs/attachments/20110224/799c7a1f/attachment.bin
More information about the docs