Top-posting to call attention to the most important question in Christian's email - "is that the best we can do?" It appeared as part of one paragraph, but seems broadly applicable to all his other questions.
I might have opinions about his other questions, and all our opinions might be worth talking about, but I think talking about how much the community is willing to consider changing, would be a good first step, no matter what direction we decided to go.
Spencer
On Tue, Jun 25, 2019 at 11:16 AM Christian Huitema <huitema@xxxxxxxxxxx> wrote:
On Jun 25, 2019, at 8:33 AM, Ted Hardie <ted.ietf@xxxxxxxxx> wrote:On Tue, Jun 25, 2019 at 8:01 AM Stephen Farrell <stephen.farrell@xxxxxxxxx> wrote:"The RSE is responsible for the performance of the RFC Production Center and Publisher"The task would look a lot different, honestly, if that part were separated out, and it may be that the community should consider a separation there. It is difficult to be certain, since the large number of other touch points with the current RPC's organization (AMS) may color our thinking, but making this more directly coupled to the LLC as a contracting authority or the stream managers might be a good structural changeYes. That's became pretty obvious to me after working just a few months with the RSOC. In the current structure the RSE is supposedly accountable for the RFC production center, yet has no way to actually manage it. Separating that clearly would remove a big source of stress.The other source of stress is the independent series. I do believe and so many times that this streams provides useful checks and balance against the IESG. It is clearly a source of tension, but that tension should be assumed and managed.The question then is, what is left for the RSE. The RFC Editor report is all about the RPC work. What would it contain if the RSE did not formally manage the RPC? Would the bulk of the RSE work evaporate? I think not.The RSE could actually focus on the series evolution, and there is plenty to do there. For example, we are using a bespoke format in the name of accessibility and long term archival, but it requires specialized personnel and tools which more than double production costs compared to other organizations.We are also handling code snippets and abstract language specifications by including them in our specs. Do this code objects require the same management as specification texts? What about bug fixes?We inherited a structure in which RFC are immutable. This leads to the errata process and long cycles of updates by WG processes. Is that the best we can do?We hold the RFC series in great veneration, but we cannot answer simple questions like who reads it, what is their impact. How can we manage change without data about our results?I would like to see the RSE focus on such questions. And I think removing the RPC management and the ISE tension from the role would help that.-- Christian Huitema
