4 Nov 2024, Wicklow MR 1, IETF 121, Dublin
Discuss where to discuss how to handle RFC reader questions and issues, and changes to the errata system.
Jean: This meeting should focus on where the discussion should happen. Because the solution space is broader than just applying errata to RFCs and could impact stream processes for new work, this is beyond RSWG scope. Analogous to the Dispatch process.
Handling of errata that are issues (Not the trivial errata) → WG or RG process.
There are issues at each stage of the current process of handling errata.
We want to encourage discussion before an issue is added to the errata system:
For bigger issues, where should the discussion go?
Roman: This venue would not be the same to talk about both
Roman: RFC-specific. Stakeholders same as for convo #2
Jay: The errata system is an entry point for people who have questions.
Percentage of that needs to go to a different path.
Community discussion
Question + Note
How that conversation takes place is stream-specific.
Mirja: Why is it easier to report errata than to get to WG mailing list?
Interfacing problem - info page.
Alexis: UI comment: new website will have the full name of the WG.
Jay: Not trying to push to the WG because it would lead to trivial and irrelevant questions going into the WG, which would overload the WG.
Mirja + Roman: That's normal.
Jay: It also requires the reader to understand full IETF processes of how to engage and subscribe to lists, etc. How best to support the consumers of RFCs that are not familiar with the reset of the process?
Generic mechanism so that each stream can have the discussion where they want.
Roman: thought this was about where to take the proposal.
Mirja: Every WG has to have a mailing list. It's the default entry point to the WG.
Colin: Go talk to the WG. We don't want to risk fragmentation.
Roman: different audiences.
Confusion for existing artifact that may or may not have a WG.
Roman: Negotiating the front door - seems like it would be the same folks.
Colin: Point people to the WG. then they can point to the issue tracker.
Consumer of an RFC has to find the complex internal process.
Robert: when SIP was new, there was a list (sip-implementers) separate from the WG list for questions, not run by IETF. Giving them the option to discuss those elsewhere.
Mirja: The default is going to the mailing list
Jay: There are consumers of RFCs who are not participants in the IETF.
Roman: dispatch – how to provide input on documents. Wide aperture to the dispatch questions. Some will go to issue tracker or errata system. Two parallel paths: both start at the same front door. So same participation for feedback.
Roman: People want an issue tracker for RFCs?
Alexis: Are they actually asking questions via this form?
Mirja: GitHub is nice for one-word changes and transparency
Jay: Point of the document is to help a reader understand where to go and how to support these people. Bring these things together.
Colin: This isn't an errata problem; this is an IETF problem. Onboarding people into WGs.
Eliot: Boilerplate improvement. Click here to discuss.
Jay: our answer is join the mailing list to ask your question. Seems very unusual.
Eliot: We don't have customer support.
Mirja: Barrier to join a mailing list is low.
Roman: Fractured the pipeline. Inject issues; report issues. No continuity. Trying to unify that.
Jay: Two different sets of people: Those who develop the specs; those who read the specs. Consumers need support rather than expose them to internal IETF processes. They shouldn't need to know any of that. They should be in a stack overflow with a thread targeted to their issue.
Eliot: Issue tracker pokes the WG; you've got questions waiting.
Colin: People are contributing without the Note Well.
Jay: they don't need to read or confirm the Note Well in order for their contribution to be considered an IETF contribution. This is based on firm legal advice. Sending a message – Implicit acceptance of the terms & conditions of the website.
Colin: should be trying to bring these people into the IETF. Fix the processes in the IETF.
Mirja: They are contributors and they don't realize it.
Jean: Concern about fragmentation of the discussion.
Colin: The groups that get a high volume of questions have a way of handling this. Have a discussion venue. For example, QUIC has a slack channel.
Roman: Inconsistency of it is an issue. Wouldn't it be great if it was unified.
Mirja: tools they used; not true for all WGs.
Roman: who does service those requests.
Eliot: we don't have the resources to do that. Existing community members answer the questions. How that information is presented; might be multiple venues. (e.g., email, GitHub). Flexibility in how the WGs, RGs, Indep. Submissions work.
Would be nice to pull people in. Their goal is to implement; they don't want to join the mailing list.
Existing tools. Front-end interface. Pick your target audience; are you responding to them? Can you service the request? how you present it to your target audience?
Robert: Ancillary communities (implementers, regulators, people with questions) -- they are going to build structures. Encourage to make it easy for their structure to continue to exist and be found.
Mirja: 2 problems: Steer people to the right place. For some RFCs, there is no right place. Some WGs still have a ML even though they are concluded. Contact the authors or the AD
Roman: let's avoid flip answers (like from stackoverflow).
Moderation procedures.
Mirja: Separate discussion of errata and how to steer people to the right place. How do we handle errata correctly?
Colin: How do we bring people in?
Eliot: People are lazy about dealing w/ errata.
Mirja: not just lazy; some are hard.
Roman: Pre-sorting. Then wide aperture.
Colin: The interesting question is how to bring people in that have questions?
Jay: Transparency and engagement. Where do you see the resolution of those conversations?
Mirja: Process implication. Discussion needs to go to the WG; should go back for WG consensus. An AD wants expert input, and you still have to evaluate if it's right.
Roman: There could be a new list for homeless RFCs. For example, new-ART-orphan@ is better than what we have now.
Colin: Recent stuff should still have an area.
Jean: Aperture. Perhaps new mailings lists for older documents. Not hearing a lot of support for a major overhaul.
Robert: reinforce idea from the doc: where's the energy to do the work in this space? all-errata dispatch WG or review team. This container [Triage team] can more quickly do the right thing.
Roman: Errata hackathon
Mirja: That container should be the WG. AD contacting the authors. There is one requirement: transparency.
Jay: Does it have to be the WG list to have that ownership and engagement?
Mirja: visibility on the mailing list for what's happening on GH.
Eliot: what does good look like? Think Bigger and More modern. Processes were baked in 1994. How I would design a new errata system. Annotate the page: Make those annotations visible to specific groups. Links to the mailing list on the backend. Prototypes to the community - “Which one do you want?”
Roman: going really small. Hyper-transparent: everything on the list. Separate mailing list. Process all the errata.
See two communities: those that create the RFCs and those that benefit from the RFCs (and don’t participate in the making of RFCs)
Mirja: clunky interface. The transparency level isn't good. AD is responsible. Tooling needs to be updated.
Eliot: what’s the forum to discuss? maybe it’s RSWG because it involves all streams, each group is going to want their own tool.
Roman: If WGs don't want to take care of the errata, then it doesn't work. We can service this problem with incentives.
Eliot: As NomCom member, the word errata never arose.
Mirja: The backlog isn't an issue w/ the community. Missing transparency; control is not in the right hands.
Eliot: you can fix it.
Colin: send the reports to the WG list.
Eliot: Proposed resolution w/ a timer to the WG.
Mirja: Transparency issue.
Roman: I see it differently. In the current system, you can see who has verified something and include a note indicating why. It’s all there.
Mirja: Wouldn't it be better if it was integrated into the Datatracker.
Roman: Would love to have the conversation about how to facilitate for those that want to discuss or have questions, but don’t want to fully participate in the IETF.
Roman: Paul and Orie wanted a different workflow and they were making a workflow.
Narrow focus of the problem statement and solution to handling errata only (and not supporting broader discussions or questions from consumers/non-participants).