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 -- docs mailing list docs@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/docs
