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

[Doug Royer <[e-mail]>]

> 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