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

[Adrian Farrel <[e-mail]>]

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 <[e-mail]> On Behalf Of Doug Royer
Sent: 02 April 2020 03:56
To: [e-mail]
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?
> 
> 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 ...

>> 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.

(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).

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

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