Two things here: For what it's worth, we have collectively used "greybeard" to refer to long-time IETF participants, for various reasons and don't further this particular conversation, and it's not fair to say that we can use it to refer to ourselves but others can't use it to refer to us. We can have a separate discussion about whether it's a non-inclusive term that's an artifact of the past and better let go, but at this point it's neither ageist nor misandrist to use it. It *is* "greybeardist", if I may coin the term for the moment, to say, "All those greybeards are jerks." But if your experience is that every time you've been treated badly it's been by a long-term IETF participant, it's NOT ageist to tell people that that's the case. And then we need to ask ourselves whether there's a tendency toward that: is it true that we have a long-term IETF culture of behaving that way? Is that an aspect of our long-term culture that we would be better off changing? I think we do, and it is, and getting offended and claiming ageism when someone points that out doesn't help. Let's look at ourselves and see how we can do better. I think that's really important. Barry On Tue, Jun 14, 2022 at 12:51 AM Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 6/13/22 19:06, Phillip Hallam-Baker wrote: > > I am mostly in agreement with Tim except that I have also met the 'reverse victim' tactic where the person whose general unpleasantness and aggressive behavior caused the code of conduct to be introduced in the first place weaponizes it by making a series of challenges. > > > The issue I think we need to focus on is what are the criteria that maximize the scope for open discussion without people being shut down by deliberate rudeness or for that matter unintentional rudeness or people playing political games. > > I know that when I make a proposal and the first four responses are of the form 'that is already being done by <new proposal>' that this is the result of someone involved in <new proposal> seeing a potential competitor and sending an email round to their mates telling them to jump on the thread quick in the hope of squashing the threat. > > I also know that when someone says my proposal is good but it absolutely MUST be built on top of some scheme that was developed years back but never made it to deployment that they are trying to make me carry their boat anchor for them. > > I also know that whenever someone says 'we can't spend time considering alternative design proposals because it is absolutely essential that this be deployed in 12 months' that the proposed WG is doomed and I can expect to be the SECDIR reviewer for something pretty similar to what was rejected on the grounds of insufficient time roughly 8 years later. > > But most folk don't know to expect that sort of behavior. > > > <SOAPBOX> > I think the example that Tim cited is both ageist and misandrist, and the implication that participants with that attitude should be somehow favored seems extremely dubious to me. I don't know why denigrating people because of their age and/or gender and/or facial hair color is any better than prejudice based on race, sexual presentation or preference, body size or shape, nationality or ethnicity, religion, etc. Clearly those who are old enough to have grey beards should have had the decency to die already, or at least to Know Their Places. Some people seem to think that this kind of prejudice is acceptable, and that others should naturally agree with it and support it. > > We have a long way to go as a species. > </SOAPBOX> > > But I suspect that his example (and your message, PHB) also illustrates a phenomenon that exists in IETF, what I've sometimes called "damage control" but that's actually a poor name. > > Experienced participants know that once an idea gets momentum, it's difficult to stop it or to steer it in a different direction. This can be true for Good Ideas, Bad Ideas, Good Ideas for which success requires solving some difficult or unsolved problem, ideas that are aligned with your interest, and/or ideas that you see as contrary to your interest. > > So there's a common practice of trying hard to nip some kinds of ideas in the bud, especially prior to forming a WG. Because once a WG gets a charter there's a strong expectation in the community that it's going to be allowed to produce RFCs, and that IESG is going to approve those RFCs in some form, even if those ideas really are horrible or the resulting RFCs are horrible. And while attempts to fix fundamental problems in charter wording are often unsuccessful, attempts to fix them at Last Call time are usually even less successful. So there's a narrow window in time to keep this from happening. > > Experienced IETF participants (regardless of the color of their facial hair or whether they have any) understand this phenomenon, so they naturally try to work the process to improve anticipated outcomes. And it's at least possible that wisdom conferred by experience better enables one to have a better sense of which ideas are Good, Bad, or otherwise. On the other hand, sometimes less experienced people are right, because they haven't been burned by choices made in the distant past that aren't being made any more, or which are less relevant than they once were. Experience is far from infallible, and some people are wise beyond their years. > > I do think that inherently Bad Ideas and some inherently Good Ideas exist, with a lot of in-between. But it's often hard to prove that an idea is Bad or Good, especially before a WG is actually formed. Often we don't know how Bad or Good an idea is until it's had several years of deployment, after which of course it's even harder to get rid of them. (I won't cite examples here because that would be unnecessarily divisive, but I'm sure that many of us have no trouble finding some.) > > It's hard to see how to avoid the situation entirely. WGs invest years in their work, and nobody wants to see years of their work thrown away even if/when they realize that the result is like sausage in the worst (sorry) ways. > > But we might at least explicitly recognize why this happens and point it out to newcomers, so they're not surprised by it. Maybe we could recognize and record expressed concerns, and expect WGs and/or document authors to explicitly state whether and how they've addressed those concerns as their documents evolve. Maybe we could learn a bit from agile practices that try to adapt designs along with emerging understanding of their consequences, rather than trying to anticipate and solve every problem up front. Maybe that would reduce some of the pressure to anticipate every problem before WG charter time and Last Call time. > > I think it's a real problem, but I emphatically disagree with the ageist and misandrist expression of that problem. > > Keith > >
