On 2/23/21 5:05 AM, Carsten Bormann wrote:
On 2021-02-23, at 05:33, Keith Moore <moore@xxxxxxxxxxxxxxxxxxxx> wrote:
And yet, you shouldn't be required to work with any specific person to get around those idiosyncrasies.
While this is a desirable goal, it also is a lofty one.
To clarify, one of the complaints that we have heard is that a newcomer
was told that he had to work with one specific person or he could not
expect to succeed in IETF.
I certainly agree that it's likely to remain difficult for a newcomer to
get consensus around an RFC in an established area without help from a
more experienced IETF participant.
(Though I also remember that when I first started writing drafts, the
notion of "shepherd" did not exist yet. I definitely had supportive
comments and constructive suggestions from other participants via
private email after I submitted my initial draft, and I had been on the
working group mailing list since before the group was chartered so I was
familiar with the conversation. IETF was smaller then than it is now,
but not that much smaller. What's changed is that we have more
bureaucracy, more rules, and a much wider and more diverse range of
increasingly narrow interests.)
The reality in *any* organization is that it is easier to do things for people who know the organization than for those who don’t. (We have a German word for that, Stallgeruch, which is hard to translate, so I’m not going into more details here.)
The objective can only ever be to make the organization *more* accessible.
I believe finding a shepherd for new work is exactly the right way to approach the IETF, and I applaud Bron for playing this role with datetime-new.
I don't have a problem with people being encouraged to find a shepherd
(though perhaps not required to do so). I only have a problem if
someone is told "you MUST work with this one person". Sometimes this
kind of relationship can be used to manipulate or use the newer person
to support poor technical or political positions.
(I found Bron’s telling of the deleterious effects of fashions like “everything must be done in OAuth” refreshing; our work has also been hit by this one, but is now slowly emerging, albeit in a rather damaged way, from ACE. But avoiding fashions is maybe orthogonal to making the organization more accessible from the outside — fashions damage insiders, too. It is also not easy to recognize a fashion from a groundswell.)
Since I consider OAuth rather limited in its applicability (especially
if you don't believe every application should be tied to the web) and
kind of dangerous (from a privacy perspective), I was appalled to read that.
Keith
