Markdown Version | Session Recording

Session Date/Time: 03 Mar 2022 20:00

TOOLS

Summary

The TOOLS Working Group met to discuss and prioritize potential workshop topics aimed at improving IETF tools and infrastructure. The session covered several proposed workshops, including DataTracker refactoring, document publication, mail list archives, search and SEO, and IT infrastructure. Key themes included the need for strong preparation (e.g., mock-ups, prototypes), gathering user requirements over discussing code, and carefully defining the audience for each workshop to avoid "bike shedding." A decision was made to handle IT infrastructure via a separate project team and to poll the broader community for prioritization of the remaining workshops. The anticipated pace for workshops is one or two between IETF meetings.

Key Discussion Points

• Session Logistics and Principles:

  • The session was recorded and will be published on YouTube.
  • The goal was to brainstorm, refine, and prioritize workshop proposals, not to conduct the workshops themselves.
  • Participants were encouraged to add themselves to the attendance list.

• Workshop Proposal: Larger DataTracker Refactoring Projects

  • Scope: Discussions on significant DataTracker improvements, such as moving RFCs to a distinct document type, enhancing the "replaces" mechanic, improving the submission interface (e.g., XML rendering preview), modernizing the agenda interface, and refining role models (e.g., formally tracking shepherds/authors on documents, fine-grained access permissions).
  • Intent: The workshop would focus on gathering requirements and identifying issues from a UI/UX perspective, not on coding.
  • Concerns: Lars expressed concern about "bike shedding" (trivial debates) as experienced with past proposals like making auth48 public. He questioned the value of broad community participation for internal topics like role management, suggesting that insight might be limited to core team members.
  • Refinement: Robert suggested that discussions on role management could benefit from working group chairs' input on desired functionalities. Carson noted that some UI-focused topics would require extensive preparation with prototypes or mock-ups to be productive.
  • Suggestion: Robert proposed reframing the workshop as "how the DataTracker can help you better," moving beyond code refactoring. Carson suggested improving DataTracker notifications, which are currently unselective and hard to find.

• Workshop Proposal: Document Publication / dot.ietf.org

  • Scope: Discussions on authoritative document sources, discovery, storage, search, and accessibility. A central debate is between a metadata landing page (favored by the RFC Editor) and direct content access.
  • RFC Editor Inclusion: Lars confirmed the workshop should include rfc-editor.org. Alice clarified that RFC Production Center does not have a strong tie to the metadata landing page as the only option and that v3 RFC HTML already uses JavaScript for metadata headers. Google Scholar indexing improvements point to the HTML file itself.
  • UX Design: Jay highlighted the exploration of an RFP for a UX design company for rfc-editor.org and potentially DataTracker, aiming to integrate metadata and content seamlessly based on user tasks. Carson supported UX refactoring for DataTracker due to its organic growth and lack of unified design.
  • Alternative Suggestion: Russ proposed a broader, initial "where do people want tools to go" brainstorming session to guide subsequent workshops.

• Workshop Proposal: Mail List Archive Interfaces (mailarchive.ietf.org, IMAP, subscriptions)

  • Scope: User interaction with mailing list archives, IMAP access, and subscription management. Jay proposed integrating subscription management directly into the DataTracker and enhancing mailarchive.ietf.org to include subscribe links and potentially Jabber logs for cross-platform conversation threading.
  • Reception: There was interest in discussing how people use and interact with the mail system. Russ found the Jabber integration idea interesting but noted the UI challenge. He was skeptical about unifying subscription management when searches often span multiple lists.
  • Future Considerations: Robert noted the potential shift to Zulip for future chat, which would introduce new challenges for reconciling threading models if historical chat logs were integrated.

• Usage Data and Analytics (Matomo):

  • Lars inquired about the availability of usage data (e.g., from Matomo) to help prioritize investment in tool improvements.
  • Robert confirmed Matomo analytics would be available for DataTracker, though details on public sharing were noted by Jay as potentially complex due to security models.
  • Lars suggested that core team members could use this data to inform decisions, rather than a broad community workshop on analytics. Jay suggested a general "observability" session on monitoring services (Matomo, Scout APM) at a later date.

• Workshop Proposal: Search and Search Engine Optimization (SEO)

  • Scope: Unifying search across IETF platforms (e.g., DataTracker), developing an interface to guide users to detailed application-specific search, potentially using technologies like ElasticSearch, and tuning for external search engines.
  • Distinction: Lars pointed out that "search" (internal application search) and "SEO" (external search engine optimization) are distinct, though a better internal search could leverage SEO efforts.

• Workshop Proposal: IT Infrastructure

  • Scope: Developing a clear vision and strategy for IETF IT infrastructure over the next few years, focusing on reproducibility, deployment insights, horizontal scaling, and evolving the relationship with AMS from a "black box" contract to one with greater community specification. Key areas include virtualization, build processes, and monitoring strategies.
  • Approach: Robert envisioned bringing in experts with experience in enterprise transformations (e.g., using Ansible) to discuss strategies and technologies.
  • Context: Jay elaborated that the direction is already set to move towards automated builds (e.g., using build languages, GitHub for scripts), new monitoring solutions, and a different virtualization strategy. The aim is to involve community expertise rather than just internal specification.
  • Workshop Suitability: Carson suggested that an IT strategy workshop would need selective invitation to be productive, and a project team might be more suitable for iterative changes.

• Prioritization and Pacing:

  • The current list of workshops represents potentially "a couple of years" worth of work.
  • A monthly pace was deemed too fast. One or two workshops between IETF meetings (staggered, not during the meeting itself) was suggested as a more manageable pace.
  • Jay asked if any proposals could be handled as "business as usual" with regular community updates rather than formal workshops. Russ suggested the mail list archive might be a lower workshop priority given prior discussion.
  • Carson emphasized that workshops should be selective in who is invited, focus on user-driven problems, and not have a "normative character."

• Application-Oriented Features:

  • Tom suggested focusing on application-oriented features. Instead of guessing backend changes, ask what applications people want to do but cannot, to drive DataTracker changes. He gave examples like accessing detailed meeting data (slide change timestamps, speaker feeds from Meetecho) that are not currently available.

Decisions and Action Items

• Decision: The "IT Infrastructure" discussion will be pursued through a separate project team with open project meetings to allow for iterative work, rather than a general community workshop.
• Decision: A community-wide poll will be conducted to prioritize the remaining proposed workshops.
• Decision: Workshops will be scheduled at a pace of one or two between IETF meetings (e.g., one between IETF 113 and 114).
• Action Item: Robert (or Jay) will send out the poll for workshop prioritization.
• Action Item: Capture suggestions for access to information not currently available (e.g., detailed meeting data) in a readily findable place.

Next Steps

1. Send out a poll to the broader community to rank and prioritize the remaining workshop proposals (excluding IT Infrastructure).
2. Based on the poll results, schedule the first one or two workshops to occur between IETF 113 and IETF 114, ensuring adequate preparation time.
3. Initiate the formation of a separate project team for the IT Infrastructure transformation, including defining the scope and involving relevant expertise from the community.
4. Consider a future general session on IETF monitoring services ("observability") to discuss available data and desired visibility.
5. Keep in mind the principle of focusing on application-oriented features and user problems when planning workshop content and development efforts.