12:32 a.m.
[note: CCed to logistics list as suggested; see below]
On 02/22/2011 03:02 AM, Jared K. Smith wrote:
On Sun, Feb 20, 2011 at 10:33 PM, Ruediger Landmann
<r.landmann(a)redhat.com> wrote:
> This decision has greatly saddened and disappointed me. With all respect
> to Dmitris and his team, to me, it seems like Fedora is giving up a key
> part of our infrastructure and our independence.
Sorry for the slow response -- I wasn't keeping up with email for much
of the weekend, and didn't see this thread until this morning. I
understand your point here regarding our independence, but I don't see
any vendor lock-in here. The software is the same open-source
software we'd be running on our intrastructure -- it's just that
Indifex has offered to take care of the hosting/upgrades/maintenance
of it for us. Because it's open source and we have the ability to
host it ourselves at any time, it really comes down to a matter of
trust. Personally, I can say that I unequivocally trust Dimitris,
because I've seen the work he's done in Fedora both as a contributor
and a former member of the Fedora Board.
Thanks Jared; and sorry for my slow reply too. I don't think anything is
gained by further haste at this point, and I've been taking some time to
think through my responses.
First, can we please clear the air of any notion of vendor lock-in? That
has never been a concern of mine, and I hope that I have not said
anything to suggest that it was. I think we can agree that you can be
dependent on someone or something even without being locked in. You
otherwise understand what I'm saying about dependence, so really, the
point of contention is "only" whether in this case, the dependence is
good, bad, or indifferent! :)
Second, I'd like to put the question of trust aside as well. Dimitris
has certainly established his credentials and bona fides within our
community. When you suggest that the move to Transifex.net comes down
to "a matter of trust" you risk reframing the discussion from "do we
think that moving Fedora's translation infrastructure to an external
provider is a good idea or not?" to "do we trust Dimitris or not?" It's
just not fair to personalize the discussion that way, and I would hate
to think that anybody would equate "doesn't support the move to
transifex.net" with "doesn't trust Dimitris".
> Therefore, I have obtained permission from my manager to put time
and
> resources into packaging Transifex 1.1 for fedoraproject.org. I have
> also had the time and skills of two Red Hat sysadmins allocated to get
> Fedora's own instance of Transifex upgraded and migrated ASAP.
That's fine, but you need to coordinate that with both the
Infrastructure team and the rest of the L10N team. Having spoken to
the Infrastructure team about this several times over the past few
days, I know their first concern is going to be the dedication of
these resources. In other words, they're not just looking for someone
who can upgrade us to 1.0 (or 1.1-dev) now, but *guaranteed resources*
to keep it upgraded and maintained and bugs fixed over the *long
haul*.
Of course! :) I am working on getting something formalized in this
direction. Are the terms of the Fedora Project's service-level agreement
with Indifex a matter of public record? (and will performance reports be
publicly available to the community?)
> I believe that if the Fedora Localization Project is open to the
idea,
> we could have an up-to-date and fully functional local instance of
> Transifex 1.1 available within a week.
With all respect Rudi, it's not just about the Localization team... We
had meetings last week between the L10N team, the Infrastructure team,
the Docs team, FESCo, the Fedora Program Manager, and myself. We
weighed all the pros and cons of the move, and we decided as a group
to move forward with the migration to transifex.net. We migrated the
translations to transifex.net last Friday. We've got a deadline of
having the transifex client packaged up and ready to go for package
maintainers by this coming Friday. Any delay (or switch to another
platform) adds additional burden to our L10N team, especially when
we're already past the string freeze and into their translation time.
Understood, and I agree that added delay and uncertainty at this point
would pose a significant and unfair burden to translators. I'm sorry
that other options were not made available earlier. Thank you very much
for raising the issue with the Board (as you related in your follow-up
email, not quoted here) and I concur that it makes more sense to revisit
this after F15 is out the door. Your firm hand on the rudder is
appreciated :)
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.
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...
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.
> I also want to take this opportunity to thank Dmitris for his
extremely
> generous offer to host this massive project on behalf of Fedora.
> However, apart from the reasons I gave earlier, I also can't help but
> feel that this direction would be grossly unfair on Dmitris and his
> business. Indifex is, after all, a commercial venture, and server
> resources and bandwidth aren't free of charge -- especially on the scale
> contemplated for Fedora. Just before I came to work for Red Hat, I owned
> a small IT business myself, and know that every penny counts! :)
I don't think Dimitris would have made us the offer to host our
translations if he would have thought that it would be unfair to
Indifex. I agree that Indifex is a commercial venture and that the
work they're offering does cost them money, but if Dimitris and
company are OK with that, how can I argue against it? On the
maintenance/upgrades side of things, that's work they already have to
do for their other clients. On the bandwidth side of things, I'm sure
they'll yell if their bandwidth costs get too high, and then we'll
make a determination on whether to compensate them for bandwidth, move
to being self-hosted again, or find some other solution.
Great :) Like I said, it's a very generous offer by Dmitris and Indifex,
and whether or not I personally agree with the move, I applaud the
commitment that it shows.
So there's room in the Fedora budget to compensate Indifex if the need
arises?
May I also suggest that we move this discussion to the logistics
mailing list, since the discussion needs to include more people than
just the Docs or the Translation teams?
of course -- CCing them in.
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.
Cheers
Rudi
4:08 p.m.
New subject: L10N migration to transifex.net
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...
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...
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.
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
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
5:10 p.m.
New subject: L10N migration to transifex.net
On Thu, Feb 24, 2011 at 11:08 PM, Karsten Wade <kwade(a)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...
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...
>
> 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
6:17 p.m.
New subject: L10N migration to transifex.net
2011/2/24 Karsten Wade <kwade(a)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:
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting...
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
following reasons:
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
something new.
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
lasting.
--
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
6:56 p.m.
New subject: L10N migration to transifex.net
On Thu, Feb 24, 2011 at 05:17:00PM -0700, Stephen John Smoogen wrote:
The issue was that transifex has been an ongoing problem for the
following reasons:
<snip important list of reasons/details>
Thanks for providing those details. I meant, and wrote it poorly I'm
sure, that I presume that the situation was much as you described, but
in the end there were people who did not feel/get communicated to. At
that point, Infra and others were saying, "OK, sorry if you didn't
hear about this before, it's been a long-standing problem, and we need
to solve it now before the barn burns down."
So, sorry for characterizing the communication as poor. I think what
I'm seeing could benefit from some change management that all know
about. A lot of times we have to result to a change management list
that goes something like, "OK, ask
$this_list_of_individuals_I_can_think_of, then email
$this_list_of_mailing_lists_I_can_think_of, and write a blog post."
Anyway, I'm sure there is a not-too-much-bureacracy way to do this. I
started this ...
https://fedoraproject.org/wiki/Change_management
... I'm sure there are others who deal with that all the time around
here, maybe there are some existing processes we can adopt,
incorporate, hug, etc.
Thanks,
- Karsten
--
name: Karsten 'quaid' Wade, Sr. Community Gardener
team: Red Hat Community Architecture
uri: http://TheOpenSourceWay.org/wiki
gpg: AD0E0C41
9:26 p.m.
New subject: L10N migration to transifex.net
Hey all,
I want to say an enormous thank-you to the logistics folks who have
weighed into this thread -- your replies have been more than generous.
In particular, I want to thank Karsten, abadger, Smooge, and David
Nalley -- plus Ricky earlier in the thread -- for your thoughtful and
helpful insights into the Transifex migration and what led up to it.
It's times like these that I wish we had some formal way of recognizing
awesomeness in Fedora!
I don't really have anything more to add right now, but wanted to
acknowledge each of you guys rather than just let the thread die without
extending my gratitude :)
I also want to reaffirm that even if I'm (evidently!) not happy about
the decision, I'm fully committed to making it work wherever it touches
what I do in Fedora, and I'm behind our leadership 100% here :)
I look forward to revisiting the issue once we've got F15 out the door!
Cheers
Rudi
10:21 p.m.
New subject: L10N migration to transifex.net
Stephen John Smoogen さんは書きました:
2011/2/24 Karsten Wade <kwade(a)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:
>
>
http://meetbot.fedoraproject.org/fedora-meeting/2011-02-15/fedora-meeting...
>
> 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."
Hi Stephen
First of all, I like to express our sincere thanks from our bottom of
hearts to you and all your team members for every effort and time spent
for L10n. Now please allow me to ask further help to understand a little
more the situation where we are standing. It will help to establish an
exit plan in the future.
Hmm then I was not communicating very clearly:
The issue was that transifex has been an ongoing problem for the
following reasons:
1) It is a moving target. Development upstream is fast moving and
adding new features that translators want.
It seems natural that every software is moving better, adding new
features. However if a feature newly to be added may interfere existing
function, as a user translator, I wish not to have a new feature added.
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."
I see. So not enough resource can be assigned to such **frequent upgrade
tasks from long term view.
What I am understanding is that the problems we are encountering are
caused by older version, and that the solution is to only upgrade. Is
this correct understanding?
Please let me make the point clear that L10n just wants stable working
version, not necessarily keep upgraded.
What if we upgrade less often?
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
something new.
The old transifex above means v0.7 or v0.9.1?
Who is 'people' and what 'items' make these people hamstrung?
At least, there were actually v0.9.1 up on the staging server and
running, which beckerde and lots of people put their time, blood, sweat
and tears [1]. Many of language teams leaders who put themselves in CC
had been watching this ticket and hoping/expecting the v0.9.1 system to
be implemented onto production. What it the cause to make this ticket
abandoned?
Thanks in advance for your help.
noriko
[1]:https://fedorahosted.org/fedora-infrastructure/ticket/2389
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
lasting.
12:12 a.m.
New subject: L10N migration to transifex.net
I'll answer some of this. Smooge can feel free to answer differently,
from his perspective :-) I'm more on the developer side of
infrastructure and he's more on the sysadmin side so we do have
different ways of looking at things. On the subject of moving to
transifex.net we were both in agreement that transifex.net held
numerous advantages over our current situation so hopefully our
perspectives here won't be too different :-)
On Thu, Feb 24, 2011 at 8:21 PM, noriko <noriko(a)fedoraproject.org> wrote:
Stephen John Smoogen さんは書きました:
>
> 1) It is a moving target. Development upstream is fast moving and
> adding new features that translators want.
It seems natural that every software is moving better, adding new
features. However if a feature newly to be added may interfere existing
function, as a user translator, I wish not to have a new feature added.
<nod> This is always an issue. For a while, Infrastructure was under
the impression that upgrading beyond 0.7 might bring workflow changes
to l10n that l10n needed to take time to figure out. Then we were
told that upgrading beyond 0.9 would bring even more workflow changes
but that the benefits of getting to 0.9 outweighed the smaller
workflow changes. We've pretty much been consistently targeting
deploying a slightly outdated version of transifex.
>
> 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."
I see. So not enough resource can be assigned to such **frequent upgrade
tasks from long term view.
What I am understanding is that the problems we are encountering are
caused by older version, and that the solution is to only upgrade. Is
this correct understanding?
Please let me make the point clear that L10n just wants stable working
version, not necessarily keep upgraded.
What if we upgrade less often?
So that doesn't really help. As you point out, the ideal is to have a
stable, working version. However, we all know that all software has
bugs. Eventually, the bugs, corner case performance problems, etc hit
a mass where you realize that you have to address those problems or
admit that you aren't able to provide service that is good enough to
satisfy you, let alone the people who are consuming your service. I
think we all realize that we've hit that point with the current
transifex in infrastructure. The question is whether we are able,
with present resources, to address this.
If we had a lot of system administrators and packagers, one way out is
to upgrade *often*. We send our bugs upstream, upstream addresses
them in new versions, we package those up, deploy and test in staging,
then deploy into production. This has failed for us for two reasons
-- 1) we don't have a plethora of system administrators right now.
This is partially addressed because beckerde stepped up to update the
transifex packages and has been working on migrating the current
instance to 0.9. However, current transifex has already moved beyond
0.9 to 1.x which points at the second issue with this method for
infrastructure: 2) the newer versions of transifex require a different
workflow than previous versions. Staying close to upstream comes into
conflict with keeping the same workflow for the translation teams and
developers.
Alright, so if that method doesn't work well, there is another method.
Instead of staying close to upstream, we can settle onto a version of
upstream and depend on our own resources to take care of bugs,
performance issues, etc. In order to make this work we'd need extra
developers. People who know Django, deploying and scaling web apps,
are familiar with localizing software, and are willing to put that all
together into enhancing our version of transifex. Where we fall down
in many ways here: We're just as short of developers as we are of
system admins. The developers we have now aren't familiar with
Django. Once we go down the road of creating local modifications to
transifex, we're going to be locking ourselves into maintaining our
codebase so we really need to have people we trust to be committed to
this for the long haul and we have to be conscious that we're
committing them to, essentially, maintaining a forked version of
transifex. From my perspective, being on the developer side of
infrastructure and knowing how few developers we really have, this
looks even less inviting to me than the first option. Infrastructure
is already in charge of too much code that it can barely keep up with.
Becoming responsible for more code isn't a good idea in my opinion.
>
> 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
> something new.
The old transifex above means v0.7 or v0.9.1?
Who is 'people' and what 'items' make these people hamstrung?
At least, there were actually v0.9.1 up on the staging server and
running, which beckerde and lots of people put their time, blood, sweat
and tears [1]. Many of language teams leaders who put themselves in CC
had been watching this ticket and hoping/expecting the v0.9.1 system to
be implemented onto production. What it the cause to make this ticket
abandoned?
I think with beckerde's good work we might have been able to deploy
transifex 0.9.1 but it doesn't address the deeper problems that we're
experiencing which really center around not being able to run the
latest versions of the code at any given time. For instance, some of
the performance problems that are stopping people from getting work
done in transifex are due to the nature of transifex < 1.x mirroring
the upstream repositories and pushing directly to them. Getting
upstream transifex devs to work closely with our issues would also
require moving on and getting onto the latest upstream releases. Both
of these require moving onto versions that require workflow changes.
Ironically, I think that moving to transifex.net now makes it easier
to make a case for moving back to hosting on Fedora Infrastructure in
that the workflow had to change when we migrated there, so it's easier
to get onto the latest versions of the transifex packages here (as
long as we have the packagers and sysadmins to keep up with updates
from here on).
However, I would like to point out that if doing translations on
transifex.net works out for us now, there's a lot of value in
remaining there. No matter what we do, Fedora Infrastructure will
always have finite resources and ever growing desires. There are
things that we must host on infrastructure because we're the only ones
that run them (for instance, koji, bodhi, smolt), there's things that
are valuable to run on Fedora Infrastructure because we can provide a
higher quality service than elsewhere or it's the only way to not lock
in the data or it makes life easier for our contributors (For
instance, our wiki and websites, mirrormanager that configures our
mirring system, fedorapeople). Then there's things that we run in
Fedora Infrastructure only because it makes us feel more in control of
our own destiny.... If we're faced with finite resources, I'd love
to discard things in that latter category rather than things in the
second or (even worse) the first because removing things from that
category doesn't sacrifice quality or convenience or even freedom...
only the *feeling* that we're somehow more free.
I would argue that in the case of transifex.net, we're firmly in that
third category. glezos is a member of the Fedora Community, transifex
was born out of a GSoC effort that he wrote with Fedora Infrastructure
people as mentors. If he's running the transifex.net instance, it's
as close to having it run in infrastructure as we can get without
actually running on our hardware with our budget being spent on admins
to maintain it. Furthermore, the quality of service that we'll get
from running on transifex is bound to be better than what we could get
from having Fedora Infrastructure people running it. Keeping
transifex running is glezos's job. It would only be our secondary or
tertiary or lower job in the crammed-full-of-issues world of Fedora
Infrastructure. glezos and his company are intimately familiar with
the code and can work on bugs, performance bottlenecks, and missing
features as part of their day to day business. Having lmacken or
ricky or I try to code a fix not only takes time from other projects,
it also requires a period where we gain a rudimentary understanding of
how the transifex code works and where the problem is being generated
before we can begin to dive into actual coding.
The only place that I can see where we may come into conflict at some
point is if transifex.net's paying customers need the software to
evolve in a way that doesn't work for us at all. However, I don't see
that as an issue today and I think that glezos would be happy to help
us get our data out and onto our own systems if that were the case.
In other words, I think that's something we can easily evaluate in the
future when we start noticing that an issue exists.
Thanks for reading until the end :-)
-Toshio
12:08 p.m.
New subject: L10N migration to transifex.net
On Thu, Feb 24, 2011 at 23:12, Toshio Kuratomi <a.badger(a)gmail.com> wrote:
I'll answer some of this. Smooge can feel free to answer
differently,
from his perspective :-) I'm more on the developer side of
infrastructure and he's more on the sysadmin side so we do have
different ways of looking at things. On the subject of moving to
transifex.net we were both in agreement that transifex.net held
numerous advantages over our current situation so hopefully our
perspectives here won't be too different :-)
I am going to say that Toshio hit all the points I could make. The
lack of progress on moving forward with 0.9.1 was a lack of dedicated
developers and sysadmins. Looking at this I think that we need to have
an equivalent of pkdb where we can show who is the maintainer and
co-maintainer on items... so that we can all know what is currently
"orphaned".
--
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
6:44 p.m.
New subject: L10N migration to transifex.net
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
12:23 a.m.
New subject: L10N migration to transifex.net
[top-posting to retain the quoted mail in entirety]
Thank you Toshio for the detailed information. This does provide some clarity
about the events in the background that eventually led to the decision. Since we
are already into the transition phase, further debate on the 'hows' and
'whys'
and 'so thats what it really was' would not serve much purpose besides adding to
the noise.
However, since we do expect to review the decision and explore the possibility
of returning to a Fedora hosted infrastructure, we may as well ensure that we do
not repeat the mistakes, especially that of communicating. As opposed to the
individuals from the FLP, the FLSCo, an elected group of representatives from
the FLP did not seem to figure anywhere during all this (unreported) discussion.
As a result, an established communication channel within the FLP was completely
ignored or not utilized.
The 'threat board' is perhaps another good thing to have in the future. With red
signs flashing all over the FLSCo and FLP could have pushed for discussion much
earlier. It would also allow individual project teams to check back on the
general health of the tools that they use.
Thank you for your patience and hopefully we can see a much stable translation
infrastructure in place for the FLP.
regards
Runa
On শুক্রবার 25 ফেব্রুয়ারি 2011 06:14 , Toshio Kuratomi wrote:
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
--
http://fedoraproject.org/wiki/User:Runab
12:05 p.m.
New subject: L10N migration to transifex.net
On Thu, Feb 24, 2011 at 23:23, Runa Bhattacharjee
<runab(a)fedoraproject.org> wrote:
[top-posting to retain the quoted mail in entirety]
Thank you Toshio for the detailed information. This does provide some clarity
about the events in the background that eventually led to the decision. Since we
are already into the transition phase, further debate on the 'hows' and
'whys'
and 'so thats what it really was' would not serve much purpose besides adding to
the noise.
However, since we do expect to review the decision and explore the possibility
of returning to a Fedora hosted infrastructure, we may as well ensure that we do
not repeat the mistakes, especially that of communicating. As opposed to the
individuals from the FLP, the FLSCo, an elected group of representatives from
the FLP did not seem to figure anywhere during all this (unreported) discussion.
As a result, an established communication channel within the FLP was completely
ignored or not utilized.
I am not sure I know what/who the FLP, FLSCo, or such are. Could you
expand acronyms please? I guess my ignorance of them is to blame here
for making things not well communicated. There seem to be a plethora
of groups saying they needed to be consulted and I was only aware of 2
(L1ON and docs).
--
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
12:11 p.m.
New subject: L10N migration to transifex.net
Stephen John Smoogen (smooge(a)gmail.com) said:
> However, since we do expect to review the decision and explore
the possibility
> of returning to a Fedora hosted infrastructure, we may as well ensure that we do
> not repeat the mistakes, especially that of communicating. As opposed to the
> individuals from the FLP, the FLSCo, an elected group of representatives from
> the FLP did not seem to figure anywhere during all this (unreported) discussion.
> As a result, an established communication channel within the FLP was completely
> ignored or not utilized.
I am not sure I know what/who the FLP, FLSCo, or such are. Could you
expand acronyms please?
FLP = Fedora Localization Project (aka, 'the translation team', or
'L10N')
http://fedoraproject.org/wiki/L10n
FLSCo = Fedora Localization Steering Committee
http://fedoraproject.org/wiki/L10N/SteeringCommittee
Bill
6:58 p.m.
New subject: L10N migration to transifex.net
On 02/25/2011 08:08 AM, Karsten Wade wrote:
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.
+1 Excellent summary!
So I'm still not following where options were weighed up in open
consultation with the community. I agree with your reading of the logs
that suggests:
* a firm decision taken by some members of the infra team (who? when?
what other options were considered?)
* a firm decision taken by project leadership to support the previous
decision (who? when? what other options were considered?)
long before this meeting.
I guess I therefore perceive a serious disjoin between:
* the scenario described above
* the depiction of the move as having been developed in broad
consultation or being in any way democratic
If the move was acutally the result of a purely authoritarian,
unilaterial "fiat", why not say so? Sometimes decisions like that are
indeed necessary in any community, which is why we have leadership -- to
make tough and sometimes even unpalatable decisions. But if that was
indeed the case (and I'm still open to the idea that I'm badly
misreading the situation) -- Why the pretense that it was anything other?
I can easily quantify the disjunction by pointing to specific statements
by people in the meeting and in various mailing lists, but I'm not going
to single people out this way. I feel bad enough saying *any* of this
out loud, because I in no way want to undermine or obstruct our
leadership. But nor do I feel like I can just shut up and pretend I'm
not seeing what I'm seeing :(
<big snippage -- I really appreciate the analysis and completely endorse
your reading of the events, with one exception: >
* 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.
I am not comfortable agreeing with you that consensus existed, when the
most obvious gauge of that consensus was a vote:
* that was not advertised as part of the meeting agenda[1]
* took place an hour and a half into the meeting
* the purpose of which was changing right up to the time the vote was taken
* in an environment where dissent had been shot immediately
* in an environment where people could tell voters that resistance was
futile and those people were not sanctioned
* where participants who checked in at the start of the meeting were
silent -- under the circumstances, I wouldn't want to claim that their
silence was assent
* in a multi-cultural environment where standing up and saying "no" in
public defiance of authority might be really, really difficult for some
people.
In short, nothing about the meeting in general and the vote at 96
minutes in particular makes me feel like it was a safe and supportive
environment in which people could express their own opinions freely. I'm
a loudmouth, and I'm not sure that *I* would have felt comfortable doing
so :(
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?
+1 to all this -- excellent stuff.
Cheers
Rudi
[1] http://lists.fedoraproject.org/pipermail/trans/2011-February/008596.html
7:16 p.m.
New subject: L10N migration to transifex.net
On 02/24/2011 04:58 PM, Ruediger Landmann wrote:
If the move was acutally the result of a purely authoritarian,
unilaterial "fiat", why not say so? Sometimes decisions like that are
indeed necessary in any community, which is why we have leadership -- to
make tough and sometimes even unpalatable decisions. But if that was
indeed the case (and I'm still open to the idea that I'm badly
misreading the situation) -- Why the pretense that it was anything other?
I think you are misreading the situation. The Infrastructure team had
known for a while that there were problems with the Fedora-local
instance of Transifex, and members of the Fedora translator community
were complaining about lack of needed functionality.
It was proposed that since the current local transifex instance was not
a viable solution for providing translations for Fedora 15, that we
consider a move to the hosted tx.net offering (this was also the
recommendation from the transifex upstream, who offered to provide this
to us at no financial cost).
This solution was presented to the Fedora translation community for
consideration (albeit, with not a whole lot of time to decide), and they
decided that was a good plan for F15, with the understanding that we can
(and probably will) revisit this after Fedora 15 is done.
Can we please put this sort of "pre-made decision" or "decision by
fiat"
stuff to rest now? There is no attempt to cover anything up, just Fedora
Infrastructure trying to identify and deploy a solution that would
enable Fedora's translators to complete their work for Fedora 15.
~tom
==
Fedora Project
8 p.m.
New subject: L10N migration to transifex.net
So I'm still not following where options were weighed up in open
consultation with the community. I agree with your reading of the logs
that suggests:
* a firm decision taken by some members of the infra team (who? when?
what other options were considered?)
* a firm decision taken by project leadership to support the previous
decision (who? when? what other options were considered?)
long before this meeting.
I guess I therefore perceive a serious disjoin between:
* the scenario described above
* the depiction of the move as having been developed in broad
consultation or being in any way democratic
So, as one of the guys who often lurks in #fedora-admin I know that
this has been a problem for some time. Numerous calls for 'someone to
maintain t.fp.o' have gone out, and a few different people volunteered
in at least the past 6 or so months. Most of the complaints I have
seen in the way of tickets about the existing t.fp.o instance came
from within l10n, as one would expect. Sadly, the state of that
infrastructure hasn't changed much in months.
So this problem has existed for some time, calls for help have
essentially gone unanswered (whether there was a wide enough audience
is a different matter, and I don't know the answer to that, but it's
also hard to essentially call out and offer up root access on boxes
that are important to fedora if you don't know the people in advance).
And unlike a democracy, Fedora's decisions (excepting legal issues and
the like) are made by the people who are doing the work, and the work
of maintaining fedora's infrastructure is done by infra, and thus they
made the decision that something had to change, and that discussion
started at FUDcon (actually long before, but really concrete steps
started appearing post-fudcon.)
I think you've taken the right steps to remediate the situation - eg,
identified it's something you care about, and are willing to spend
time on, and committed to doing so. Every successful infrastructure
project I have seen has needed a long term person like that - whether
it was Ian and the wiki, or Jesse (and now dgilmore) with the
buildsystems. Every infrastructure project that hasn't had at least
one committed person has languished (and now appears on the chopping
block). It's not really different than package maintainers orphaning
packages (and as a point of reference that notice only goes out to
people on -devel)
4806
days inactive
4807
days old
logistics@lists.fedoraproject.org
15 comments
10 participants
participants (10)
-
Bill Nottingham -
David Nalley -
Karsten Wade -
Kévin Raymond -
Noriko Mizumoto -
Ruediger Landmann -
Runa Bhattacharjee -
Stephen John Smoogen -
Tom Callaway -
Toshio Kuratomi