Subject: Re: [Rfced-future] Naming the role (was Re: First Topic for Discussion: Thought Leader)

From: Carsten Bormann <[email-masked]>
Date: Thu, 1 Oct 2020 09:41:19 +0200

On 2020-09-30, at 22:57, Adam Roach <[email-masked]> wrote:
> 
> it would be ill-advised to include the word "Editor" anywhere in its description.

Unfortunately, this word is indeed overloaded.
(It mainly means “Emacs” for me :-)

The word we are looking for is “Herausgeber” in German.
My dictionary offers “publisher” and “editor”.

I think the perception problem can be addressed by being more explicit.

“The RFC editor, publisher of the RFC series” might be a good title.
Also provides continuity.

Grüße, Carsten

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 1 Oct 2020 07:37:35 -0700

On Wed, Sep 30, 2020 at 2:08 PM Christian Huitema <[email-masked]>
wrote:

>
> On 9/30/2020 10:40 AM, Brian Rosen wrote:
> > So, we think we have created the issues list, and we would like to
> > start on one of the key questions that we believe doesn’t depend on
> > other decisions.
> >
> > Is there a figurehead/thought leader, regardless of what the position
> > is called, how they are selected, who they report to, and what duties
> > they have?
> >  rea
> > a
> > Please send your thoughts on this subject.  We would actually
> > appreciate +1s as we go through this process so we can try to gauge if
> > we have any form of consensus.
>
>
> I am not sure that we need "a thought leader" for providing the
> publication expertise. I observe that changes in the series tend to be
> big steps, such as changes in formats, or changes in reference methods.
> I could easily see hiring publication experts to produce an audit and
> explain all the wrongness of our ways, and then have a working group
> drive for consensus on solutions. That would not require having a
> permanent expert position.
>

I am finding it hard to answer this question in the abstract, because the
question of what job we want done (i.e., what duties they will have) is
prior to whether we need the position.

With that said, I do not think we need what I would characterize as a
"thought leader" in the sense that it is their job to drive the discussion.
I think it is reasonably likely that we need to engage someone to provide
specialized expertise in much the same way as we engage a lawyer to provide
specialized expertise, but I do not believe they should be acting in a
"thought leader" position as I understand it.

-Ekr

-- Christian Huitema
>
>
> I
>
>
> --
> Rfced-future mailing list
> [email-masked]
> https://www.iab.org/mailman/listinfo/rfced-future
>

---

From: Lars Eggert <[email-masked]>
Date: Thu, 1 Oct 2020 20:19:58 +0300

> My dictionary offers “publisher” and “editor”.

"Issuer"?

Lars

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 1 Oct 2020 18:34:02 +0100

Yeah, well, Latin edere. But so what.

We run into the fact that, despite the dictionary definitions of "editor" being spot on, the common usage/understanding is broken.

"Publisher" is similarly misunderstood. And "Issuer" is pretty much a non-word.

"Distributer" implies, erm, distribution.

The way this is handled in the industry is to give a qualifier with "editor". Hence, "commissioning editor", "copy editor", "editor in chief", "supervising editor", etc. etc. But we're not going to make it down this path.

Let's work out what the job actually is, then work out how we want the role to be perceived, and only then let's give it a name.

A

-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Lars Eggert
Sent: 01 October 2020 18:20
To: Carsten Bormann <[email-masked]>
Cc: [email-masked]; Adam Roach <[email-masked]>; Michael StJohns <[email-masked]>
Subject: Re: [Rfced-future] Naming the role (was Re: First Topic for Discussion: Thought Leader)

"Issuer"?

Lars

---

From: Eliot Lear <[email-masked]>
Date: Thu, 1 Oct 2020 19:37:13 +0200

> On 1 Oct 2020, at 19:34, Adrian Farrel <[email-masked]> wrote:
> 

From a chair perspective, I think that sounds about right.  But the name discussion is interesting in as much as people are talking about what the job is.

---

From: Adam Roach <[email-masked]>
Date: Thu, 1 Oct 2020 13:04:25 -0500

> Let's work out what the job actually is, then work out how we want the role to be perceived, and only then let's give it a name.

This would be my preference as well.

/a

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Oct 2020 10:04:17 +1300

On 02-Oct-20 03:37, Eric Rescorla wrote:
> 
> 
> On Wed, Sep 30, 2020 at 2:08 PM Christian Huitema <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> I am finding it hard to answer this question in the abstract, because the question of what job we want done (i.e., what duties they will have) is prior to whether we need the position.
> 
> With that said, I do not think we need what I would characterize as a "thought leader" in the sense that it is their job to drive the discussion. I think it is reasonably likely that we need to engage someone to provide specialized expertise in much the same way as we engage a lawyer to provide specialized expertise, but I do not believe they should be acting in a "thought leader" position as I understand it.

We could split the issue into two, if you like.

- do we need a person with specialized expertise?
- does that person act as a thought leader?

I'd say yes to both. The first one because I saw the benefits of the previous RSE's knowledge and experience in the wider world of technical publishing. The second one because the technical community has a very inward-looking & intrinsically conservative approach to this topic, and I think we need an outsider to lead us into new thinking.

   Brian C

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 2 Oct 2020 10:11:24 +1300

>>From a chair perspective, I think that sounds about right.  But the name discussion is interesting in as much as people are talking about what the job is.

I agree, but it's worth noting that the word "Editor" is overloaded with many shades of meaning, which is why variants such as "Copy Editor", "Technical Editor", "Managing Editor", "Editor-in-Chief", etc. exist. My choice, "Advisor", is less overloaded, I think.

   Brian C

---

From: Nevil Brownlee <[email-masked]>
Date: Fri, 2 Oct 2020 15:39:47 +1300

Hi all:
For the last few weeks I've been thinking about what our RSE actually
does.  First, some history ...

RFC 8729 "The RFC Series and the RFC Editor" spells it all out, in nice
detail. rfced-future
(8729 was published in the IAB Stream, since IAB had oversight of the RFC
Series).  Here are the most important parts of 8720:
Section 1:  History
  "the IAB supports a future for the RFC Series that continues to meet its
   original mandate of providing the archival series for the technical
   research and engineering documentation that describes the Internet."
Section 2:  RFC Series Mission
   "The RFC Series is the archival series dedicated to documenting
   Internet technical specifications, including general contributions
   from the Internet research and engineering community as well as
   standards documents.
 RFCs are available free of charge to anyone via the Internet."
Section 3: RFC Editor
  "The RFC Editor is an expert technical editor and series editor,
   acting to support the mission of the RFC Series.  As such, the RFC
   Editor is the implementer handling the editorial management of the
   RFC Series, in accordance with the defined processes.  In addition,
   the RFC Editor is expected to be the expert and prime mover in
   discussions about policies for editing, publishing, and archiving
   RFCs."

This last paragraph states that the RSE is expected to be "the prime mover
for 'development of the series' (my paraphrase of that sentence)."  It
details exactly what Heather did for the changes to RFC's publication
format and the tools for preparing draft RFCs - so I'm puzzled as to why
some postings to the list have proposed changing it.

As for the name of the position, the RFC Series is - in publishing terms -
a Serial Publication, i.e. RFCs are published at irregular intervals, but
in a clearly identified sequence.  The title "Series Editor" seems entirely
appropriate to me.

Cheers, Nevil

On Thu, Oct 1, 2020 at 7:00 PM Eliot Lear <lear=[email-masked]>
wrote:

> Adam, Adrian, Mike,
>
> I’ve opened Issue 24 on how the role is named.  I would suggest that it is
> a good lead in to discussing what the job actually is (Issue 11), so please
> don’t stop discussion.
>
> Eliot
>
> --

-- 
-----------------------------------
Nevil Brownlee, Taupo, NZ

---

From: Adam Roach <[email-masked]>
Date: Thu, 1 Oct 2020 21:42:52 -0500

> I agree, but it's worth noting that the word "Editor" is overloaded with many shades of meaning, which is why variants such as "Copy Editor", "Technical Editor", "Managing Editor", "Editor-in-Chief…

I like this term, too, but I think it's because you and I have a 
reasonably similar vision for what this person should do. I'm very 
comfortable with "RFC Series Advisor" as both a concept and a title, but 
I suspect that is in large part due to the fact that I think the role 
should be advisory in nature.

/a

---

From: Adam Roach <[email-masked]>
Date: Thu, 1 Oct 2020 22:01:32 -0500

On 10/1/2020 9:39 PM, Nevil Brownlee wrote:
> As for the name of the position, the RFC Series is - in publishing 
> terms - a Serial Publication, i.e. RFCs are published at irregular 
> intervals, but in a clearly identified sequence. The title "Series 
> Editor" seems entirely appropriate to me.

I don't think this explanation is very responsive to the very real 
confusion among the IETF community about the role that the RSE has 
historically served. It seems very much in line with "you are 
technically correct" without any thought to second- and third-order 
effects of selecting a title with "editor" in its name, like the ones I 
cited up-thread.

/a

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Oct 2020 08:42:50 -0400

--On Thursday, October 1, 2020 18:34 +0100 Adrian Farrel
<[email-masked]> wrote:

> We run into the fact that, despite the dictionary definitions
> of "editor" being spot on, the common usage/understanding is
> broken.
> 
> The way this is handled in the industry is to give a qualifier
> with "editor". Hence, "commissioning editor", "copy editor",
> "editor in chief", "supervising editor", etc. etc. But we're
> not going to make it down this path.

Or, to look at that path from a different angle, to talk about
"RFC Series Editor" rather than "RFC Editor".  Hmm.   Been there.

> Let's work out what the job actually is, then work out how we
> want the role to be perceived, and only then let's give it a
> name.

Concur and I think this illustrates why, noting...

--On Friday, October 2, 2020 10:11 +1300 Brian E Carpenter
<[email-masked]> wrote:

> I agree, but it's worth noting that the word "Editor" is
> overloaded with many shades of meaning, which is why variants
> such as "Copy Editor", "Technical Editor", "Managing Editor",
> "Editor-in-Chief", etc. exist. My choice, "Advisor", is less
> overloaded, I think.

In "normal" publishing industry terminology "Managing Editor" is
usually actually close to what we are talking about.  But, if
our community doesn't understand that or understands it to mean
something else, knowing what the publishing industry thinks
doesn't help except possibly in recruiting.  And the problem
with "Advisor" (perhaps especially in our community) is that it
may imply a role in which advice is given but often ignored
_and_ one that is often held by many people at the same time,
e.g. consider it as a synonym for "Member of the Advisory
Committee" and how that might be interpreted relative to "Member
of the Supervisory Committee" or "Member of the Oversight
Committee" [1].  That interpretation of "Advisor" is likely to
be a recruiting disaster.

Again, let's figure out the role and then see what would be a
nearest match.  If we cannot, I suggest "RFC Series Grand
Pooh-bah" or "RFC Series Ring Lord".  :-(

    john

[1] These suggest "Series Supervisor" or "Series Overseer" but I
don't think we want to go there either.

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 06 Oct 2020 15:24:08 +1100

So I haven't had time to think about this issue, but it seems like our chairs are forging ahead.  With only 2 days of feedback gathered.  I've been otherwise occupied and will remain so for a little while yet.

Is the fantastical thing being constructed by this process supposed to pass for consensus?

On Thu, Oct 1, 2020, at 03:40, Brian Rosen wrote:
> This is: https://github.com/intarchboard/rfced-future/issues/10
> 
> We are basically looking for a yes/no.  Your opinions on secondary 
> issues if you think there is such a position are, as always, welcome, 
> but we are really trying at this point to see if we have consensus one 
> way or another on if there is such a role.  This is an opportunity for 
> those who haven’t spoken up yet to weigh in.
> 
> Brian
> 
> --

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Oct 2020 13:20:41 +0200

> On 6 Oct 2020, at 06:24, Martin Thomson <[email-masked]> wrote:
> 

And just how long would you like the group to wait?

> Is the fantastical thing being constructed by this process supposed to pass for consensus?

It will if you don’t engage.

Eliot

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 6 Oct 2020 13:45:48 +0200

> On 1. Oct 2020, at 16:37, Eric Rescorla <[email-masked]> wrote:

[snip]

> With that said, I do not think we need what I would characterize as a "thought leader" in the sense that it is their job to drive the discussion. I think it is reasonably likely that we need to eng…

I’m actually a +1 here. I don’t really know what a though leader is supposed to do and I strongly believe we don’t have a common understanding of that. 

Brian proposed two subquestions in a follow-up email (do we need a person with specialized expertise? does that person act as a thought leader?). I think I agree that we need a "specialized expertise” in some role but again I still don’t know what it would mean for that person to act as a though leader. 

I also think we need a person or group of people that actually drives problems for discussion and proposes solutions. While I think decisions should be made community-based, e.g. in a wg like setup, it’d be worried that we don’t see any progress if nobody in that open wg is committed to actually work on problems; and I don't think the chairs would or should be taking this role. While this might be some kind of leadership position, I don’t think this position must be help by the same person that brings in the specialized expertise, nor it would necessarily call this a thought leader.

Mirja

---

From: Eliot Lear <[email-masked]>
Date: Tue, 6 Oct 2020 14:03:16 +0200

Hi Mirja,

> Brian proposed two subquestions in a follow-up email (do we need a person with specialized expertise? does that person act as a thought leader?). I think I agree that we need a "specialized experti…

A little further down in the discussion the point is made that we really have to figure out what this person does, and then we can figure out how to name the role.  That seems to me the right order.  To that end...

> I also think we need a person or group of people that actually drives problems for discussion and proposes solutions. While I think decisions should be made community-based, e.g. in a wg like setup…

That seems like great input for characterizing the relationship between the person and the group and, perhaps even the RPC.  But what does this mean in terms of expertise or responsibilities?  This question is not just for you…

Eliot

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Oct 2020 13:09:35 +0100

Thanks Mirja,

You uncover a good point that we should generalise.

I am sure we don't have a common understanding of "Thought Leader".

My conclusion is that we must stop using shorthand in this discussion. If we want to properly reach consensus on what job we want done for us, we need to be very precise and careful in how we describe the work and the role.

Thanks,
Adrian
-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Mirja Kuehlewind
Sent: 06 October 2020 12:46
To: Eric Rescorla <[email-masked]>
Cc: [email-masked]
Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader

[snip]

Mirja

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 6 Oct 2020 14:39:04 +0200

On 2020-10-06, at 14:09, Adrian Farrel <[email-masked]> wrote:
> 
> I am sure we don't have a common understanding of "Thought Leader”.

Right.

I’d more comfortable with first identifying that person as a “professional”.
The next question is how much that professional can do on their own vs. requiring consultation vs. requiring consensus processes, and what level of initiative we expect from that position.

(This is a question we tend to run into a lot at universities; the keyword is “professionalization”.  And I can tell you we are well aware of both the upsides and the downsides…)

Grüße, Carsten

---

From: "Adrian Farrel" <[email-masked]>
Date: Tue, 6 Oct 2020 14:04:13 +0100

Not picking on you, Carsten, but...

> I’d more comfortable with first identifying that person as a “professional”.

This is another example of using a word believing it will be understood in a particular way, but potentially suffering some additional unwanted meanings. (It is less bad than the "thought leader" example.)

I think that what you mean is that "the person will be experienced in the field and will be paid for their work at the market rate." That is the "paid expert" that Mirja refers to in her email.

A

-----Original Message-----
From: Carsten Bormann <[email-masked]> 
Sent: 06 October 2020 13:39
To: [email-masked]
Cc: [email-masked]
Subject: Re: [Rfced-future] First Topic for Discussion: Thought Leader

Right.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Tue, 6 Oct 2020 13:02:19 -0400

On 10/6/2020 7:45 AM, Mirja Kuehlewind wrote:
> I also think we need a person or group of people that actually drives problems for discussion and proposes solutions. While I think decisions should be made community-based, e.g. in a wg like setup, it’d be worried that we don’t see any progress if nobody in that open wg is committed to actually work on problems;
Hence the need for someone actually paid to ensure progress.
> and I don't think the chairs would or should be taking this role.

I actually think its more like it would be difficult to find any 
volunteer whose funding source would find this a good use of their time 
for more than a year or so at a time.

> While this might be some kind of leadership position, I don’t think this position must be help by the same person that brings in the specialized expertise, nor it would necessarily call this a thought leader.

I had a parsing error for the above sentence.  I couldn't actually 
figure out what you were trying to say here.  I lost sync around reading 
"must be help".  Could you clarify please?

Mike

---

From: Mirja Kuehlewind <[email-masked]>
Date: Tue, 6 Oct 2020 19:04:54 +0200

See below.

> On 6. Oct 2020, at 19:02, Michael StJohns <[email-masked]> wrote:
> 
> I actually think its more like it would be difficult to find any volunteer whose funding source would find this a good use of their time for more than a year or so at a time.
> 
> I had a parsing error for the above sentence.  I couldn't actually figure out what you were trying to say here.  I lost sync around reading "must be help".  Could you clarify please?

Sorry, typo: I meatn "must be held”.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 7 Oct 2020 09:05:14 +1300

>> Hence the need for someone actually paid to ensure progress.

And that is very distinct from someone paid to provide expertise.

To revert to the comparison with the IETF's legal counsel, we've
never explicitly asked our counsel to propose IETF IPR policy or even
to lead discussion in the IPR WG; we've only asked them to explain the
legal implications of proposed policy.

So if we take it as a given that we have an expert advisor (the "RSA"),
do we want that person to lead the discussion by proposing RFC strategy,
writing drafts, etc.? That's a more active role than just advising.

   Brian

P.S. "Thought leader" is not a modern invention. It goes back at least to 1876, according to Wikipedia.

---

From: "Martin Thomson" <[email-masked]>
Date: Wed, 07 Oct 2020 11:11:01 +1100

> And just how long would you like the group to wait?

I am asking that you slow down a little.  For foundational questions, a week is fast.  2 days is ridiculous.  And maybe set some expectations ahead of time.

In this case, I can't promise anything this week.

> It will if you don’t engage.

Good to know.

---

From: Eliot Lear <[email-masked]>
Date: Wed, 7 Oct 2020 11:01:42 +0200

Martin,

I understand your (and others') concern.

To begin with, in this particular case, I think it should be clear that there are dependencies.  People may want a person or not, depending on what the person is asked to do.  We’ll have to allow for those dependencies to play out.  Recognizing this, my intent was to move, perhaps clumsily, to the dependencies.

Now that we have an issues list, we should find a path to address the issues in an orderly and timely fashion.  IMHO the best way forward is a virtual meeting every two – four weeks at various times of the day, covering as many issues as time allows.  That is- if we all agree on stuff, we keep moving, and if we don’t we slow down.  Of course, anything discussed in an interim needs to be confirmed on list.  My thinking is that people get a week after an interim to say something, and then we move on.

If someone does say something and we can’t resolve on list to a point of rough consensus, we’ll pick it up at the next interim.  Of course that will require participation in that interim.  Thus the standing agenda of the virtual meeting would be to trudge through those issues.

The one thing I would ask is that people take a few minutes to review the minutes of each meeting as they come out, so that any concerns can be raised in a timely fashion.   To be sure, this group is not the only thing going on in people’s lives, and so we will need to strike a balance between allowing a certain amount of leeway and seeing that our work gets done.  We can do that by adjusting the tempo of the meetings. 

There is definitely some inconvenience involving time zones.  I guess we should use that as a motivator to close things on list where possible ;-)

How does this sound to people?

Eliot

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 7 Oct 2020 04:58:55 -0700

On Tue, Oct 6, 2020 at 5:11 PM Martin Thomson <[email-masked]> wrote:

> I am asking that you slow down a little.  For foundational questions, a
> week is fast.  2 days is ridiculous.  And maybe set some expectations ahead
> of time.
>

Precisely this. We have an established practice for doing this kind of
thing and it involves setting an explicit deadline far enough out that
people have a reasonable time to respond. Neither of those things happened
in this case.

-Ekr

---

From: Michael StJohns <[email-masked]>
Date: Wed, 7 Oct 2020 12:29:15 -0400

Hi Brian - In line.

> And that is very distinct from someone paid to provide expertise.

I disagree.  Anyone who's been subjected to a product manager that 
doesn't know the technology will get my point that while expertise and 
responsibility *might* be distinct, having them be so is a recipe for 
poor performance.

> legal implications of proposed policy.

Unfortunately, you've picked the wrong example.  A better example is an 
outside counsel (lawyer) who's been charged with "defend our patents" or 
even a marketing or advertising professional who's been told to "help 
sell our products".    Both of these are multi-year engagements, both 
require the engaged professional to take the lead in the actions 
initiated by the customer.  And the customer will generally lack the 
specific expertise to engage successfully themselves.

For IPR, we all have at least a little of the layman's idea of what that 
entails, and have a pretty good idea of the result we want out of the 
discussion.  I'm pretty sure that while the lawyer took your input on 
what you wanted, the actual language of the IPR policy was based on 
legal principles, the lawyers own skill set and then finally language 
provided by the team that didn't conflict with the first two.

> writing drafts, etc.? That's a more active role than just advising.

I'm not taking as given that this person is solely an advisor. I 
*really* don't think we have enough internal expertise (e.g. knowledge 
of publication at least equivalent to the layman's knowledge of IPR) to 
make that model work.  I also would be surprised if we have anyone 
(volunteers I mean) that wants to hang onto the job long enough and will 
bring enough energy to the position to keep the RFC series on track over 
a long period of time.

Later, Mike

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 8 Oct 2020 10:01:32 +1300

Hi Mike,
> responsibility *might* be distinct, having them be so is a recipe for 

I was unclear. Yes, of course the line manager needs to understand
the work and the technology. But I was trying to work through the
issues in sequence. Do we need external expertise first, does
*the same person* need to be the line manager second. I maintain
that they are distinct questions. I would also argue that while
the line manager does need expertise, they don't need to be able
to answer questions about the Chicago Manual of Style or whether
ISSNs and DOIs are Good Things.
 
> provided by the team that didn't conflict with the first two.

You'd have to ask Scott Bradner for details of how that went. I'm not
sure I agree that "we" knew what we wanted in advance. I was pretty
ignorant in that area when I started in the IETF.

> bring enough energy to the position to keep the RFC series on track over 

Indeed, that is the point under discussion.

   Brian C

---

From: "Martin Thomson" <[email-masked]>
Date: Mon, 12 Oct 2020 12:45:17 +1100

> is called, how they are selected, who they report to, and what duties 

You did ask for a yes/no answer, so I'm going to put my vote for "no".  Certainly not in the sense of "figurehead", and I think that Adam's non-response matches fairly closely with how I am thinking about the "thought leader" concept.

Some additional nuance might help though.

In the discussion it has been fairly clear that there is a need for some sort of management position.  I would put most of what Sandy listed into this category.

What is somewhat unique in the prior arrangement here is the extent to which the "product" provided was tightly negotiated.  The RPC has apparently never had any "product management" function responsible for ensuring that their "product" is responsive to the needs of their client.  The client in this case is the community of people who produce and consume RFCs.

That the RSE has been responsible for this product management function is very clear from Sandy's list.  I guess that part of what I proposed is a move to a model where the RPC (or whatever it is called) moves to taking on more of that responsibility, at least as it pertains to those decisions that need to be made for operational reasons.

That might involve less of the RPC being told what to do in concrete terms.  I'm guessing here because much of the client-supplier engagement happens largely out of sight (I only get glimpses at AUTH48, and a filtered view through my stint on RSOC). That process thus far appears to involve some variation on a process where a problem is identified after which the RSE works with those involved and makes a decision.  A lot of the things subject to that process aren't high impact, but benefit from having the RSE, as a representative of the client, make a decision.  I'm tempted to say "bike shed colours", but it's almost never that far from consequential.

Up until now the community (in the broad sense) have delegated (and paid) the RSE to represent their/our interests as a "client".  On the full spectrum of issues, from the details of execution to setting long-term strategic direction.

That involves a lot of trust.  I couldn't find anywhere that documents the set of principles that guide the decision-making of the RSE.  There's a lot in what is implied by the documented record, or what can be conveyed via oral history, and a few RFCs.  But not a lot of that recently.  The principles documented in RFC 3 clearly don't match contemporary use.

What I proposed was not that our community design a system that results in a void, but instead to concentrate on building those principles.  Concrete decisions can be judged - or iterated upon - based on those principles.  I don't think that we necessarily need a specific person (in a paid position or otherwise) to guide that process, at least not on an ongoing basis, but we might allow those principles to be subjected to discussion and documentation.

I am concerned about the potential for an individual who is given authority to dominate discussions in this area.  Someone who is paid to drive will drive.  This is why the "advisor" function is vastly preferable to me.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 12 Oct 2020 16:16:45 +0200

Hi Martin,

Thanks for this detailed message.  Just for clarification...

> That the RSE has been responsible for this product management function is very clear from Sandy's list.  I guess that part of what I proposed is a move to a model where the RPC (or whatever it is c…

Are you suggesting that the RPC take on the entirety of the list or a part of the list, and if the latter, which part, and should there be some flexibility about that line time, and if so, how?

[…]
> I am concerned about the potential for an individual who is given authority to dominate discussions in this area.  Someone who is paid to drive will drive.  This is why the "advisor" function is va…

I think I heard three different roles from you:

Client representative: The person to represent "the client" to the RPC in cases of dispute.
Product manager: A person or group of people to manage tactical requirements.  
Strategic Advisor: A person who is an advisor to the community when addressing strategic requirements.

Is that about right?

Eliot

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Oct 2020 09:03:20 +1300

On 13-Oct-20 03:16, Eliot Lear wrote:
...
>   * Client representative: The person to represent "the client" to the RPC in cases of dispute.
>   * Product manager: A person or group of people to manage tactical requirements.  
>   * Strategic Advisor: A person who is an advisor to the community when addressing strategic requirements.
> 
> 
> Is that about right?

Speaking only for myself here, I'm not hung up on the "figurehead" or "thought leader" terminology. I think it's very useful to split the description of the role up this way. I'm certainly not answering for Martin, but I think that there are two other roles to consider:

 * Decider for policy and strategy issues
 * Arbiter for conflicts 

Also I have fairly clear ideas about who should fill most of these roles:

 * Client representative - the stream manager concerned
 * Product manager - the line manager of the RPC, as approved by the LLC
 * Strategic Advisor - a new role (proactive, not reactive)
 * Decider for policy and strategy - consensus of a new WG/IAB Program

but I don't see a clear candidate for the Arbiter role, which is why I wanted to understand what sort of conflict might arise. If it's really author vs RPC conflicts, and assuming we want editorial consistency between streams, it really does need to be someone outside the RPC line management hierarchy and *not* tied to one stream in particular.

   Brian C

---

From: "Martin Thomson" <[email-masked]>
Date: Tue, 13 Oct 2020 08:45:52 +1100

Well, Brian beat me to it.  I agree with what he said there.  I was going to call out the decider function; but missed the arbiter function.  I think that role is generally something the client representative and product manager do, generally.  That is, if an author is being troublesome, the RPC staff could escalate to their management, who would talk to the corresponding client representative and they work something out together.

One thing that was pointed out to me was that I might have accidentally denigrated the series by referring to it as a product.  I thought that I was being crisp, but clearly was not.  My intent was to describe the *service* provided as the product.  The editing and publishing and so forth.  The series is more than that.

On Tue, Oct 13, 2020, at 07:03, Brian E Carpenter wrote:
> Speaking only for myself here, I'm not hung up on the "figurehead" or 
> "thought leader" terminology. I think it's very useful to split the 
> description of the role up this way. I'm certainly not answering for 
> Martin, but I think that there are two other roles to consider:
> 
> but I don't see a clear candidate for the Arbiter role, which is why I 
> wanted to understand what sort of conflict might arise. If it's really 
> author vs RPC conflicts, and assuming we want editorial consistency 
> between streams, it really does need to be someone outside the RPC line 
> management hierarchy and *not* tied to one stream in particular.
> 
>    Brian C
> 
> 
>

---

From: Christian Huitema <[email-masked]>
Date: Mon, 12 Oct 2020 17:14:03 -0700

> but I don't see a clear candidate for the Arbiter role, which is why I wanted to understand what sort of conflict might arise. If it's really author vs RPC conflicts, and assuming we want editorial…

Brian,

Can you elaborate why you don't want the stream managers or their
delegate to do that?

-- Christian Huitema

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 13 Oct 2020 13:46:28 +1300

On 13-Oct-20 13:14, Christian Huitema wrote:
> Can you elaborate why you don't want the stream managers or their delegate to do that?

Simply because (to take silly examples) I wouldn't want different streams to take different decisions about use of the Oxford comma, or how to spell "acknowledgment". In general I think we want editorial consistency across streams.

Maybe the answer would to have the stream managers act as a committee to arbitrate disputes?

   Brian C

---

From: Christian Huitema <[email-masked]>
Date: Mon, 12 Oct 2020 18:30:48 -0700

> Maybe the answer would to have the stream managers act as a committee to arbitrate disputes?

The reason I asked is practical. Most disputes tend to be authors not
appreciating the work of the RPC, with a variety of motivations from "I
think my original test sounded better" to "these edits change the
meaning of the draft". The stream manager should be in a good position
to check that, and either encourage the author to just go with the
program, or in some cases explain to the RPC that an accommodation needs
to be found. In the IETF stream, the stream manager might contact the
relevant AD.

Of course, this assumes that the stream managers are acting responsibly.

-- Christian Huitema

---

From: "Joel M. Halpern" <[email-masked]>
Date: Mon, 12 Oct 2020 22:34:09 -0400

I think there are a couple of points which relate to why I think a 
leader responsible for this sort of thing is helpful.

1) I assume we want consistency.
1a) Having different stream heads deciding in different cases does not 
help us there
1b) having the person in this role change regularly (as both the IETF 
stream and IAB stream heads do) seems to reduce the likelihood of 
consistency over time.

2) Having a committee make the decision elevates the complexity and load 
for each decision and discussion.  That does not seem good for the series.

3) Having a person with visibility to these and other issues that arise 
from the RPC, who is tasked with bringing these to the attention of the 
community when needed seems very helpful.

Yours,
Joel