 Hello everybody, welcome and thank you for joining this presentation on the NodeJS Diagnostics best practice documentation. Before we talk about what decision is all about and what is the stated purpose, what are the expected outcomes, etc. Let's provide a brief introduction about the speakers. Myself Girish Panuthu, I work for IBM. I'm an architect with one of the team called IBM Pruntimes. That's responsible for developing and supporting language runtimes such as Java and NodeJS. I'm also a member of the NodeJS Technical Steering Committee. And I'm Mary Marconi, I work at Netflix as a senior performance engineer for the NodeJS platform team, where we work to provide a curated and managed NodeJS experience for the NodeJS developers across Netflix. I'm also a NodeJS TSC member and TC-39 delegate. All right, so this is what we are going to cover today. We provide a bit of introduction around the NodeJS project and the community. We talk about the diagnostic working group, what are the stated purpose, what are the activities we perform in the working group, etc. Let me provide a bit of introduction around the user journey. What is the user journey around? What are the governing principles or the philosophies around the user journey? How the user journey is driving into the best practice documentation effort? Then we also provide an introduction to the tooltales and how that is going to drive into the user experience around the NodeJS diagnostics. And finally, we look at where do we stand in terms of the current status on the best practice documentation effort? What are the challenges we face and what is the support that we need? How people can get engaged? What are the different initiatives where people can start contributing and make the best practice documentation a great success? Here is a very short introduction around the NodeJS project as well as the community. Well, I'm sure there is no need for providing an elaborate introduction about what is NodeJS, etc. But I'm just providing a one-liner here for the sake of completeness. NodeJS is an open source cross-platform JavaScript runtime. But then what is V8? V8 is also an open source cross-platform JavaScript runtime. What's the difference? NodeJS is customized for optimally running in the backend as opposed to running in the browser. And that specificity or that key differentiation makes it one of the very favorite runtime for hosting most of the modern workload that runs in the backend, including the cloud, the analytics, the AI, the mobile and the IoT, etc. Now coming to the NodeJS community, it is governed by the OpenJS Foundation. What is OpenJS Foundation? It's the governing foundation or the premier home to a number of open source JavaScript projects, the entity that actually runs this conference too. The community is very much active with a number of active contributors and collaborators, as well as a number of working groups, which are essentially special focus forums as such. We put extra effort and we put high standards on OpenJS inclusivity and diversity. And these are something which we constantly put a lot of effort on to keep high standards. Okay, so what is diagnostic working group? Actually, we started as two different working groups. We're back in 2015. One is the post-modern working group that largely concerned around the dumb debugging and the second one being the tracing working group, which was mostly focusing on the runtime tracing. Eventually, around 2017 or so, we felt the need for merging both the working groups, because we found that. There is a high degree of overlap in the objective as well as the way we work in both the working groups. So that's how diagnostic working group was born. What we do in the working group, we make sure that there is a great user experience derived out of the NodeJS diagnostics. So we are active in developing as well as attaining maturity to most of the LTS-grade diagnostic tools, such as S-Incodes, profiling, tracing, and dumb debugging tools such as LL-Node, FFDC tools such as diagnostic reports. So each of these tools expose unique features or value adds in the overall diagnostic story. Now, in terms of the activities, we generally meet once in two weeks as a working group, but we work and collaborate offline, largely. A few years ago, the working group started to investigate ways to ensure diagnostic tools were properly supported and documented, as well as ensure stability across major Node versions. We soon realized that thinking in terms of two, stability would be challenging, because several diagnostic tools Node rely on come from dependencies, such as V8. With that in mind, the working group decided to shift focus from tools to user journeys, with the goal of allowing the project to guarantee coverage of diagnostic use cases across Node measures, even if that man changes to the tooling every once in a while. The shift to user journeys also allowed us to better define supported workloads and deployment models, as well as help us better understand which use cases should receive long-term support from the project. We started to explore and document potential user journeys during meetings, and as we dive deeper into each user journey, we started to align existing tools to use cases, and not the other way around. As well as identify two tooling gaps for certain use cases. We also started to use those user journeys to write guides that we will leave on the new Node website. These guides, also called best practice documentation, are step-by-step procedures on how to debug and troubleshoot Node services. Those are being written based on user journeys, therefore the guides and user journeys are aligned. Those guides will also provide instructions and prerequirements to use diagnostic tools in production environments, since some tools require Node process to be preemptively configured in a certain way. And because of the range of tools conveniently available to users, those guides are also loaded with case studies on different tools applied to similar issues, with observations on when each tool is preferred over the other. Okay, now it makes a lot of sense to talk about the diagnostic tooling tiers in the context of the user experience with the Node.js diagnostics. What is tooling tiers? Simply put, it's a classification based on certain value parameters that we attach to the known set of diagnostic tools. What are those value parameters? Such as how efficient the tool is in terms of debugging a specific use case, and how much is the maturity level of the tool in terms of, say, for example, the stability index, and what is the overall adoption story of the tool in the user ecosystem, and how well the tool is maintained by the tooling owners, etc. So these are some of the value parameters that decide what is the current tier of the tool. How does this classification help at all? So in two ways, number one, it helps the releases to understand where do each of these tools reside in terms of the stability index and various parameters that I mentioned, and take calculated decisions around inclusion in certain releases based on the long-term support strategy. Number one, number two is it helps the contributors to the tooling to understand which tool reside in which state in terms of various value parameters, and where to actually apply the focus where they get maximum value addition based on the current classification indices. We constantly review the list and the state of the tiers of various diagnostic tools and make amendments based on the perceived change in state of any of these parameters. So where do we stand with respect to the best practice documentation work? Well, we have some initial structure in place. We do have documents for few use cases that are ready to consume. For example, the memory, the profiling, the abnormal termination, etc. These are ready to use already. We are working on other use cases such as crash, hang, tracing, etc. So as I said previously, for each of the use case, we could have as many tools as relevant. And from those perspective, we can bring in more real world stories here, as well as the demonstration of different tools that solves the same problem in different ways. In that way, that would enrich as well as improve the consumability of the documentation if we have different tools telling the same story in slightly different manner. All right. So this screenshot of the top level work item that shows the current backlog. Basically, item number 439 in the diagnose report. I believe the list of items that we see here is the current state of affairs as of today. This slide shows the full structure of our best practice documentation. As you can see, we have a top level folder for each of the identified symptom or the use case, whatever we want to call it. And under each such top level folder, we will have a readme file that explains the specific use case and a setup instruction that explains any special setting that's required for your production box of your system towards containing that specific use case or the production anomaly. An investigation flow that shows how the case study will be carried out and the case study documentation itself. And finally, we can have as many steps. The biggest challenge the working group is facing today is lack of progress. The working group is small and the current members of the team will have to take the specific use case through different tools. So this will be on a best effort basis. We can have a specific use case with a single tool versus another use case with, you know, five or six different tools attacking the same use case through different angle, etc. The work group is small and the current members don't have enough bandwidth to push the work further. Besides that, the user journeys and best practice documents still lack a more diverse range of workloads covered. Part of this problem is due to the small number of folks involved and due to the lack of involvement from a broader community, which resulted in only a few workloads covered, those from companies currently engaged in the discussion. There are several ways to help us in this work if you are interested. The meetings are open to anyone who wants to join and meeting dates are available in the Node project calendar. Or, if you prefer to work more asynchronously, the user journey document as well as the best practices guides need more reviewers. And since not everything covered in user journeys became best practices guides yet, helping with writing new guides based on the user journey documents is also a great place to start. And if you operate Node.js in production or if you face some nasty bugs in the past and believe there are gaps in tooling, bring us real world stories so we can incorporate more workloads and types of issues in user journey documents. Last but not least, if you're also passionate about open source, collaboration, Node.js and diagnostics, you can join the working group and help us drive new work. Thank you so much for listening to our talk and we hope to see you on Meetings or on GitHub.