Subject: Re: [Rfced-future] Welcome to the romp! A reminder of what I would like us to decide first...

From: Stephen Farrell <[email-masked]>
Date: Wed, 1 Apr 2020 10:02:11 +0100

Hiya,

On 01/04/2020 07:34, Eliot Lear wrote:
> 
> Should the program worry about the structure of the series or should
> the program worry about putting in place someone who could lead the
> community in worrying about the structure of the series (among other
> things)?

I think the focus ought be on the latter, or more precisely
on defining that role and it's accompanying setup rather
than on the direct "putting in place" of a person to fill
the role. I hope this process produces an accepted method
for the "putting in place" bit but doesn't aim to actually
run the hiring process;-)

> A related question:
> 
> Should we establish a process that addresses series evolution over
> time or should we leave that for later?
Personally, I think we ought keep in mind that we are
dealing with a 50-year old artefact (the series) that I at
least would like to see setup so it could continue for
another 50 years, should the content of RFCs in the series
continue to be relevant. 50 years is too far into the
future to be fair, but I'd like us to aim to set things
up so that could happen and I figure that means we need
to define the RSE role with that in mind. Concretely, I
think that implies some level of independence from IETF
process-change may be needed for the RSE - but I don't
claim to know how that might best be done.

Cheers,
S.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Apr 2020 09:18:17 +1300

> run the hiring process;-)

Agreed. But in addition to role & responsibilities, I think we
need to be clear about (as was said yesterday) the checks and
balances on the role, and how the role relates to the community.

As Christian Huitema pointed out more than once, the community for
the RFC series is not well defined. But I don't see how we can get
very far without some notion of what that community is and how to
have a conversation with it.

> claim to know how that might best be done.

Indeed. Another way of looking at it is: Which bits of
RFC8728 and 8729 (and possibly 8730) are we interested in
changing as a result of this conversation?
(See https://www.rfc-editor.org/rfc/rfc8728.html#model-figure
for example.)

Stay well,
   Brian

---

From: Eliot Lear <[email-masked]>
Date: Wed, 1 Apr 2020 22:28:27 +0200

Hi Brian,

> On 1 Apr 2020, at 22:18, Brian E Carpenter <[email-masked]> wrote:
> But in addition to role & responsibilities, I think we

> have a conversation with it.

I have thoughts at least about how to ask that question of this program, and will propose them in due course.  But I do not believe that it has to be the first question answered.  Not to worry.  I don’t see it as that far away.

> (See https://www.rfc-editor.org/rfc/rfc8728.html#model-figure <https://www.rfc-editor.org/rfc/rfc8728.html#model-figure>
> for example.)

Which brings us back to the work plan.  The basis by which we answer that question is to understand precisely what we think could stand improvement.  What are we trying to solve for?  I speak of this at a high level, but I am quite certain that everyone on this list could come up with at least three or four items that they would class as problems, challenges, or opportunities.  I think our next step is me asking that very question, and everyone taking some time to think about what are the issues we need to address.

Eliot

---

From: Doug Royer <[email-masked]>
Date: Wed, 1 Apr 2020 14:54:53 -0600

Has "what went wrong" been defined? Fixed? I saw a lot of opinions. I don't recall a conclusive resolution or definition.

-- 
Doug Royer - (http://DougRoyer.US)
[email-masked]
714-989-6135

---

From: John C Klensin <[email-masked]>
Date: Wed, 01 Apr 2020 18:31:02 -0400

--On Wednesday, April 1, 2020 10:02 +0100 Stephen Farrell
<[email-masked]> wrote:

>> Should we establish a process that addresses series evolution
>> over time or should we leave that for later?

Strongly agreed.  

Let me add something that, given your comment about IETF process
changes, you may have had in mind:

If we are trying to aim for 50 (or more) years, the structure
and mechanisms should be sufficiently robust and flexible to
adapt to either or both of the following extreme events:

(1) The IETF, at least the IETF as we know it as a SDO with a
collection of principles and customs, disappears or,
alternately, pulls its Standards Track documents out of the RFC
Series.

(2) XML is superceded by a vastly improved YML, ZML or something
else and becomes a historical artifact that people view with
about as much amusement (and have current, active, and
maintained tools for) as eight inch floppy disks are viewed
today.

I'm not predicting either of those things, but a 50 year plan
that was not sufficiently robust to be able to think clearly
about them and adapt is not really a 50 year plan.

best,
   john

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Apr 2020 11:44:34 +1300

> Has "what went wrong" been defined? Fixed? I saw a lot of opinions. I don't recall a conclusive resolution or definition.

I think we should avoid finger-pointing, since it wouldn't serve any useful purpose. So I think that means we should look for structural problems that were the ultimate cause of what went wrong.

As John Klensin said, an important symptom was people thinking that the RSE was an ordinary contractor with key performance indicators to be measured. Another symptom was that the oversight committee (like the IAOC) was apparently getting far too involved in details. Were there other symptoms?

Looking at the symptoms, we might be able to discern the structural problems that caused them.

   Brian

---

From: Doug Royer <[email-masked]>
Date: Wed, 1 Apr 2020 16:59:43 -0600

On 4/1/20 4:44 PM, Brian E Carpenter wrote:
> I think we should avoid finger-pointing, 

I don't mean it in that way. I don't care *who*. I still don't know what happened. I am now guessing, from your reply, that it was an interpersonal issue. If that was it fine.

Was it a too many bosses issue?
Was it lack of staff?
Was it a lack of job description with too many expectations?

If whatever was not fixed, then how will it not happen again?

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 2 Apr 2020 13:57:04 +1300

> I don't mean it in that way. I don't care *who*. I still don't know what happened. I am now guessing, from your reply, that it was an interpersonal issue. If that was it fine.

That's exactly the discussion I don't want to be part of, hence the second part of my message that you elided.

> Was it a too many bosses issue?

Not exactly, IMHO: but the way the RSOC was set up seems to have led to many cooks trying to stir the same pot.

> Was it lack of staff?

I have seen no suggestion of that.

> Was it a lack of job description with too many expectations?

I don't think that Heather, nor Bob Braden, nor Joyce Reynolds, nor John Postel,
were ever hampered by that.

> If whatever was not fixed, then how will it not happen again?

That's what we're here for, isn't it?

Stay well,
    Brian

---

From: Doug Royer <[email-masked]>
Date: Wed, 1 Apr 2020 19:04:25 -0600

> That's what we're here for, isn't it?

For me, having no clue. I guess I could start with dozens of suggestions, many of which would be shot down as they don't apply to the unknown problem.

 From what I have read so far, including what I cut out, whatever the issue was, is the problem that shall not be named.

I am not trying to be difficult. I am trying to catch up.

---

From: Michael StJohns <[email-masked]>
Date: Wed, 1 Apr 2020 22:50:55 -0400

> I think we should avoid finger-pointing, since it wouldn't serve any useful purpose. So I think that means we should look for structural problems that were the ultimate cause of what went wrong.
I agree with this.  Hopefully, this will be forward looking, and will 
map out changes to create a sustainable structure.
> As John Klensin said, an important symptom was people thinking that the RSE was an ordinary contractor with key performance indicators to be measured. Another symptom was that the oversight committ…

As a general thought, the technical leadership of the IETF probably 
shouldn't be involved in day-to-day  or even month-to-month management 
of the non-technical portion of the IETF as that's not generally their 
expertise.  A given member of a given I* might have the specific skills 
to do that oversight, but what happens when we do the turnover to a new 
person or a new board?    I think that covers the RSE, RPC, IT, Tools 
and the Secretariat.   Input is needed from these groups - control is not.

Another symptom was the RSOC was not (and is not) responsible to the 
community and there is no way for the community to express its 
displeasure if it runs off the rails.  For the IAB at least, we have the 
annual NOMCOM process and there is the rarely used recall process.

Going back to John's comment.  The RSE contract was structured  - for 
good and useful reasons - as two years plus 2 two-year renewals.  My 
understanding of this was that the renewal periods were proforma and 
there mainly to allow for unforeseen changes in the situations 
(financial or otherwise) of either the IETF or Heather.  It shouldn't 
have been possible for this to change without community discussion.

Mike

---

From: Doug Royer <[email-masked]>
Date: Wed, 1 Apr 2020 20:55:49 -0600

> Looking at the symptoms, we might be able to discern the structural problems that caused them.

I am writing this while reading the incoming messages on this list.

I am learning a lot. This might be and old rehash for many of you. This may be long an boring for some. I want to help and I need to understand.  I am trying to see the problem and possible fixes in my head.

So, thoughts, suggestions ...

> Not exactly, IMHO: but the way the RSOC was set up seems to have led to many cooks trying to stir the same pot.

(1) To the too many cooks comment:

Those problem look like an employer problem and too many bosses all of which think they are the only or most important boss.

I have worked in jobs where I had a company boss (say IAOC) and a project boss (say RSE lead). In those situation the company boss gave me the raises, and the project boss evaluated my performance for my raises and gave me my assignments. I sometimes had several projects in on year. That seems to me to be the existing RSE mode - two or more bosses. Whenever my company-boss gave me conflicting assignments than my project boss, we had a meeting and the problem was resolved. If the conflict continued, then I would step out of the meeting and let them slug it out. I did not care which direction things went. I would just work on another lower priority task until resolved. It always got resolved.

I do remember reading a mailing list comment that made me think it was attempting to change the priority or process for some documents. If so, then a document showing the processing flow and how exceptions work. That would include the process used to resolve those exceptions before bothering the editors that do the work.

Were they getting direction from more than one IAOC individual at a time? If so, would only one agreed on individual at a time in the IAOC be the point person for the RSE maybe solve the problem? And perhaps that IAOC individual needs approval from the IAOC committee and the RSE manager before asserting an exception to editors. In that context the RSE manager would be effectively on the IAOC for that process role.

Are there a lot of exceptions? If so, maybe one (or few) assigned to deal with the exceptions. And everyone else does the normal flow.

Does the existing RSE team have a manager? If so, then everyone else takes direction from that manager or team leader.  And maybe rotate the lead in the RSE office if that works. At Sun we had a project motto "no foreign orders". That means that each individual only took direction from one person. Whenever possible when asked to change direction, they would be referred to that lead. And have only one lead at a time. So when an editor is working on draft-awesome, they would work only on that document, until redirected by their lead. If your not a lead, you don't interact with the IAOC (or whoever else).

Document out of band communications, perhaps: Editors communicate only for clarification and not process issues to the IAOC members or draft authors. Otherwise, it goes through the lead.

In summary, if possible, isolate the workers from the exception flow and priority conflicts.

(2) What do they spend their time doing that may cause too many process flow problems:

I have always been confused about the internal workings of the editors office. xml2rfc should have reduced the load by minimizing the content formatting. Is there a written list of the tasks an editor does? There has to be checklist, even if it is a checklist of RFC's to conform to at any point in time.

I remember for a while (maybe still) the editors took the output from xml2rfc and edit that, effectively throwing away the XML original. If so, why? Does xml2rfc only do part of the formatting work? Bugs? Are the editors unfamiliar with (or unwilling to learn) editing XML documents to fix the original? I can see changes to text using that process taking a lot more time than would be expected and it would lead to frustration when yet another from above change happens.

What percent of the editors time is spent actually editing documents? What percent is tracking things down, or what? I would think it would be more efficient to have editors and one manager or lead. Do some edit only? Do some research for accuracy and not others? Does everyone do everything for the draft they are working on?

In my minimal experience with the editors. In person they were great. With email - I felt like I was bothering them and I often got answers that confused me more. In one case I was told 'not to bother them again', when I thought I was answering their question. I guessed they were overworked. I still felt bad for bothering them.

How many are in the RSE office / team when all positions are filled?

Would volunteer pre-screeners solve some of the problems? What percent of the issues that need to be resolved are process flow vs xml2rfc vs content of the document or drawn images or ABNF or text emphasis is? I am sure they have a gripe list of repeat problems even if not written down :-)

And what does "ACCOUNTABLE" mean to the RSE?

Does anyone have a flowchart perhaps drawn by dia that shows the flow and "accountable to who" links?

Do people think that only micro changes are needed? Is the general thinking that too much of the flow is undocumented and this is causing problems? Is everyone always in all loops - causing anxiety when hearing about things that may never happen? If so, have a manager that deals with the process and editors that are awesome with grammar and readability (unlike me).

---

From: "Adrian Farrel" <[email-masked]>
Date: Thu, 2 Apr 2020 11:32:54 +0100

I have a lot of sympathy for Doug's question. One logical way to approach
this project is to look at history and "what went wrong" and try to fix it.

But I agree with Brian that "finger-pointing" will not be productive
(although it might be therapeutic ;-) and may just burn cycles.

Is a better way to approach this simply to work out how we want things to
be, and then design a process for that? Of course, not learning from the
past can have risks, but perhaps rather than trying to agree on what we can
learn, we can each (privately) apply the lessons we think we have learned to
help shape the outcomes.

That means we need a positive engineering process where we work towards
objectives.

That leaves our initial problem being to work out what our objectives are.
How do we want things to be, not what do we not want to go wrong? 

Of course, the conversation might now be "why don't we want it to be exactly
how it was?" but I suggest that is the easy question to ask because it
avoids considering how we want things to be. So the next step is to try to
imagine the functioning RFC Series and what the RSE's job should be.

A
-----Original Message-----
From: Rfced-future <[email-masked]> On Behalf Of Doug Royer
Sent: 02 April 2020 03:56
To: [email-masked]
Subject: Re: [Rfced-future] What went wrong [was Welcome to the romp! A
reminder of what I would like us to decide first...]

> As John Klensin said, an important symptom was people thinking that the
RSE was an ordinary contractor with key performance indicators to be
measured. Another symptom was that the oversight committee (like the IAOC)
was apparently getting far too involved in details. Were there other
symptoms?

I am learning a lot. This might be and old rehash for many of you. This may
be long an boring for some. I want to help and I need to understand.  I am
trying to see the problem and possible fixes in my head.

Those problem look like an employer problem and too many bosses all of which
think they are the only or most important boss.

I have worked in jobs where I had a company boss (say IAOC) and a project
boss (say RSE lead). In those situation the company boss gave me the raises,
and the project boss evaluated my performance for my raises and gave me my
assignments. I sometimes had several projects in on year. That seems to me
to be the existing RSE mode - two or more bosses. Whenever my company-boss
gave me conflicting assignments than my project boss, we had a meeting and
the problem was resolved. If the conflict continued, then I would step out
of the meeting and let them slug it out. I did not care which direction
things went. I would just work on another lower priority task until
resolved. It always got resolved.

I do remember reading a mailing list comment that made me think it was
attempting to change the priority or process for some documents. If so, then
a document showing the processing flow and how exceptions work. That would
include the process used to resolve those exceptions before bothering the
editors that do the work.

Were they getting direction from more than one IAOC individual at a time? If
so, would only one agreed on individual at a time in the IAOC be the point
person for the RSE maybe solve the problem? And perhaps that IAOC individual
needs approval from the IAOC committee and the RSE manager before asserting
an exception to editors. In that context the RSE manager would be
effectively on the IAOC for that process role.

Are there a lot of exceptions? If so, maybe one (or few) assigned to deal
with the exceptions. And everyone else does the normal flow.

Does the existing RSE team have a manager? If so, then everyone else takes
direction from that manager or team leader.  And maybe rotate the lead in
the RSE office if that works. At Sun we had a project motto "no foreign
orders". That means that each individual only took direction from one
person. Whenever possible when asked to change direction, they would be
referred to that lead. And have only one lead at a time. So when an editor
is working on draft-awesome, they would work only on that document, until
redirected by their lead. If your not a lead, you don't interact with the
IAOC (or whoever else).

Document out of band communications, perhaps: Editors communicate only for
clarification and not process issues to the IAOC members or draft authors.
Otherwise, it goes through the lead.

In summary, if possible, isolate the workers from the exception flow and
priority conflicts.

(2) What do they spend their time doing that may cause too many process flow
problems:

I have always been confused about the internal workings of the editors
office. xml2rfc should have reduced the load by minimizing the content
formatting. Is there a written list of the tasks an editor does? There has
to be checklist, even if it is a checklist of RFC's to conform to at any
point in time.

I remember for a while (maybe still) the editors took the output from
xml2rfc and edit that, effectively throwing away the XML original. If so,
why? Does xml2rfc only do part of the formatting work? Bugs? Are the editors
unfamiliar with (or unwilling to learn) editing XML documents to fix the
original? I can see changes to text using that process taking a lot more
time than would be expected and it would lead to frustration when yet
another from above change happens.

What percent of the editors time is spent actually editing documents? What
percent is tracking things down, or what? I would think it would be more
efficient to have editors and one manager or lead. Do some edit only? Do
some research for accuracy and not others? Does everyone do everything for
the draft they are working on?

In my minimal experience with the editors. In person they were great. With
email - I felt like I was bothering them and I often got answers that
confused me more. In one case I was told 'not to bother them again', when I
thought I was answering their question. I guessed they were overworked. I
still felt bad for bothering them.

Would volunteer pre-screeners solve some of the problems? What percent of
the issues that need to be resolved are process flow vs xml2rfc vs content
of the document or drawn images or ABNF or text emphasis is? I am sure they
have a gripe list of repeat problems even if not written down :-)

Does anyone have a flowchart perhaps drawn by dia that shows the flow and
"accountable to who" links?

Do people think that only micro changes are needed? Is the general thinking
that too much of the flow is undocumented and this is causing problems? Is
everyone always in all loops - causing anxiety when hearing about things
that may never happen? If so, have a manager that deals with the process and
editors that are awesome with grammar and readability (unlike me).

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