Re: [Tools-arch] My notes and thoughts from 2020-04-23 meeting

[Jay Daley <[e-mail]>]

Martin

> On 24/04/2020, at 11:46 AM, Martin Thomson <[e-mail]> wrote:
> 
> What I got from this was that there is a desire to understand less of the mechanics of the process, but more of the overall user experience and how the various tools integrate.  More generally, our first task might be to ensure that we have a vision for how the process works and the tools to support that.
> 
> We immediately identified the document lifecycle as central to this, but then we also identified important supporting functions like authoring, discussion (mail), discussion (meetings), management (status tracking, evaluation, review), and finally publication (RPC).
> 
> I might even up-level and say that the business of the IETF is fostering communities that strive to reach consensus and that we use documents to capture the state of that consensus.  That places greater emphasis on the communication channels and less on the document production side of things; documents might be the focal point of our energy, but the means by which we direct that energy is more important: email, GitHub issue discussion, meetings, and side discussions.

This is an excellent analysis that really helps me understand this from a high-level perspective.

> You will note that I did not mention chat.  I think that the current state of instant messaging in the IETF is in dire need of attention.  Jabber/XMPP is dead and we cling to it to our detriment.  That's a shame because the backchannels in meetings can be very effective.  And the efforts I've been involved in have benefited greatly from the chat systems they use.  With QUIC being so active, the slack used there is a great resource.  (I am aware that chat is a known issue, but I wanted to highlight that.)

Now that I can see this in the context of the analysis above, I understand the need and the urgency much better.

thanks
Jay

> ---
> 
> Jay:
> Three levels of focus
> 1. Operational development level - making the tools
> 
> 2. Technical architecture of how those tools integrate
> e.g., datatracker use shared files
> 
> 3. Higher level (main focus of this group): architecture and strategy
> 
> Higher level issues:
> - nobody has done an end-to-end analysis of the process we follow and the tools
>   that are used in that process
> - no big picture plan for integration of tools: how tools chain together and
>   support each other, how third party tools integrate with our processes
> - user experience with tools is inconsistent: we have no idea who each tool is
>   being used for, or the target platforms (mobile, command line, browser,
>   desktop)
> - performance is poor in some cases, but we don't have expectations for this
>   (scale and responsiveness side) Robert and Jay are looking at
>   instrumentation, but we need to know what the goals are
> 
> This group will draw on Robert and Jay for getting an understanding of the
> current situation, make some suggestions and recommendations.
> 
> John: understanding user needs is important; problems come up as a result of
> people not know what the tool is supposed to do
> 
> Robert: we understand the users who are chairs and document authors, and other
> roles that are modeled in the tracker.  What other actors depend on this.
> 
> Jay: Some more depth might be needed here.
> 
> Robert: the datatracker API is primitive, this group might help identify areas
> for improvement
> 
> Jay: Do we want to have a single integrated home for all the tooling?  Something
> that covers the process from authoring, to management, checking, publication,
> approval, etc... ?  Or do we think that there is sufficient diversity of use
> that we just need to have a suite of tools that can be self-assembled.
> 
> MT: some diversity
> 
> Robert: people using word will continue to do so
> 
> mnot: we have removed dependencies on IETF tools for various reasons
> (performance, availability, etc); I have a draft on criteria for using
> third-party tools
> 
> mt: what other tools are involved in the process? other than datatracker/github?
> 
> rsalz: what about the RPC
> 
> John: the RPC tools are mostly just xml2rfc
> 
> Robert: tried to get the RPC to open source their tools
> 
> John: these are a mess of scripts
> 
> Jay: we do need to look at all of this all the way to the RPC.  The IETF really
> does own all of these tools.
> 
> John: not a question of ownership, it's just time (keep the RFCs flowing)
> 
> Robert: document development seems to be the backbone of things.  WE need to
> look at activities around the document.  Having online meetings is another
> important thing here.
> 
> Jay: In the LLC, we have an agreement that some large amount of money might be
> needed to revamp the toolchain.  We need a vision for this that describes what
> excellent looks like.
> 
> Jay: AMS has just two tools: meeting registration and a CMS for fundraising.
> The registration system is being rewritten.
> 
> Robert presents.  (Robert: can you provide those slides?)
> 
> Jay: is this group the sort of team that can advise on how these things are
> deployed?  (mt: thought is that an HTTP 3xx to a specialized file-serving
> service is a reasonable substitute for serving the content directly.)
> 
> Robert: Most of this stuff is operated by SSH to the one big machine.
> Datatracker has a lot of inbuilt operational capabilities so that rarely needs
> manual intervention.  yangcatalog is built to modern standards for operation.
> Wagtail is updated via dockerhub.
> 
> Robert: we should concentrate on how this *should* work in the ideal sense
> 
> rsalz: how do we integrate meetings (increasingly virtual?) into the overall
> production process.  Mobile devices are important.
> 
> Robert: what are the first work products?  no good answer, but a good question
> 
> Jay: we might need to produce more data, we need to know what users access, we
> need to know where that integrates
> 
> Jay: it might help to start a skeleton of things we need to talk about and
> decide
> 
> rsalz: producing documents is a central thing, but there are other processes to
> support that: meetings, IESG processes,
> 
> robert: IPR ownership is another in terms of declarations
> 
> mt: mail is a big deal
> 
> Robert: query: mail is critical and hard, can you take that to the cloud?
> 
> John: there are several services (google does that; fastmail can do that too, and
> they are our friends)
> 
> Jay: we could also pay someone to do a review of this
> 
> John: talk to Bron, economies of scale are massive in mail, so this might save
> money overall
> 
> mt: I'll send notes to the list and we can talk about what our first deliverable
> might be
> 
> -- 
> Tools-arch mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tools-arch
> 

-- 
Jay Daley
IETF Executive Director
[e-mail]