L10N migration to transifex.net

Thu Feb 24 23:10:51 UTC 2011

On Thu, Feb 24, 2011 at 11:08 PM, Karsten Wade <kwade at redhat.com> wrote:
> 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:
>
> http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.2011-02-15-13.00.log.html
>
> 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
> confusion.
>
> 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
>> http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting.2011-02-15-13.00.log.html
>>
>> 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
> make sense?
>
> 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.
>
> 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.

Yes, we (the infra and trans) should have discussed about our
transifex instance
more seriously before deciding that it is *really* to late to take time

>
> 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?
>
> - Karsten
> --

As seen now that we have started using Transifex.net, is that using
the same service as other communities helps collaborate.
It is easier to see and join other projects (in both ways) when you
can see their file and how their are managed.

-- 
Kévin Raymond (shaiton)
GPG-Key: A5BCB3A2