--On Friday, February 13, 2015 09:10 -0900 Melinda Shore
<melinda.shore@xxxxxxxxx> wrote:
> On 2/13/15 8:44 AM, Dave Cridland wrote:
>> Moreover, if you accept that the word "culture" is effectively
>> indistinguishable to outsiders from the term "status quo"
>> (though the intent is obviously different), it's really quite
>> revealing. All this "preserving the culture" talk comes out
>> in an entirely different light.
>
> I think this is a really important comment. I mean,
> *really* important comment.
>
> But it also seems to me pretty clear that the culture
> is changing, anyway, and it's one of those things that
> I expect most people know without addressing it directly.
> I don't think meetings were so heavily emphasized 10
> years ago, although that's subjective and could be wrong.
> We've now got a very large number of people participating
> whose primary job function is to create standards, and
> that's caused some changes because their incentives are
> different from those whose job it is to create products
> or technology. I don't know how long it's been since
> running code was a significant adjunct to the work being
> done in the IETF, but I think it's been quite awhile.
> So these cultural shifts are taking place anyway, and
> they are not being "managed." Some are good, some are not.
> I do think that the increased significance of meetings
> in IETF participation (and here, I'm not talking about
> things like nomcom but about significance to our technical
> work) is a problem, both because it tends to marginalize
> people who can't come to meetings and because it slows
> work down.
I completely agree with all of the above. I think we are also,
as a community, frequently in denial about those changes and
their consequences. To take a pair of examples that has been
discussed before but without either conclusions or actions, if a
Nomcom cannot distinguish between those whose "primary job
function is to create standards" and those who function is
primarily to "create products or technology" --either because
they have been told the difference isn't important or because
most of them fall into the first group (perhaps because that is
where the resources are to support Nomcom work), then the odds
are increased that we end up with an IESG that is mostly the
former group as well (again, perhaps in part because it is
easier for professional standards developers to find support for
the time and resources the IESG takes than it is for an
organization to take a product designer off the job for a few
years). Perhaps that is ok, but we are not discussing its
implications, implications that experience in some other SDOs
suggest are significant.
john