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
+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
* 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
* 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
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
Community supported infrastructure doesn't have to be of a
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.