<html xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:10.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style>
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt">Hi Fabiano,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Eric has made some great points on how we can improve our community. I agree with him on those and also don’t see a lot of challenges with the architecture committee itself, but our overall community participation
 can be improved a good deal.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">There are quite a few participants and development efforts going on today in the Kata community along with greater end-user adoption. While this is obviously very positive for the project, it also makes it
 highly difficult to track high-priority issues and features that need attention in terms of agreed direction. While it has been pretty useful to have an issue for every PR raised, it also sometimes makes it difficult to find issues that are raised by our end
 users (Maybe we can solve this simply by making good use of github labels in the future). While I can urge everyone in the community to be proactive about this including myself, I have been trying to see if we can take any concrete steps to address this. I
 feel dedicating 10-15 min every AC meeting to triage over high priority issues opened over the last week could be a useful step.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">I also feel the PR review rota process needs to revisited to make sure people listed on the rota process will dedicate the necessary time to review not only PRs but also issues opened that week. We used to
 be quite diligent about this earlier, but not as much recently. We also need to make sure that not it is just not handful of partcipants taking part in this. Same goes for the release process, as Eric as pointed out. While it is not just a couple of companies
 involved in the release process any longer, I do feel there is ample scope for improvement here.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Another area we can improve is in getting consolidated feedback from customers using Kata in production. I think we do need to revisit this from time to time to get valuable feedback from customers in what
 pain points they see with Kata. I don’t fully have a picture on how best this can be done, but perhaps making sure we have a session in our bi-yearly PTG to invite some of our end-users beforehand would be a good step. This is something we can ask OIF to help
 with.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">For the Kata AC itself, I  believe we can do better in terms of having some more cross-project presentations on our AC call, for eg having virtiofs folks come in and talk about some of the recent work they
 have been doing in their project.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">These are some of the things that I can think of currently to improve the community health. I’ll send a follow up email if I think of anything else.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt">Archana Shinde<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal" style="margin-bottom:12.0pt"><b><span style="font-size:12.0pt;color:black">From:
</span></b><span style="font-size:12.0pt;color:black">Eric Ernst <eric.g.ernst@gmail.com><br>
<b>Date: </b>Monday, November 14, 2022 at 11:58 AM<br>
<b>To: </b>Fabiano Fidêncio <fabiano@fidencio.org><br>
<b>Cc: </b>kata-dev <kata-dev@lists.katacontainers.io><br>
<b>Subject: </b>Re: [kata-dev] Elections | Q&A | What are the current pain points with the AC and how to solve them?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">Hey Fabiano,<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">I don't feel there are that many challenges with respect to the architecture committee *itself* to day, as we haven't had a ton of need to specifically exercise it. I think if we step back and look at the
 Kata Containers community itself, I can think of a few areas we can highlight as challenges:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">1) Time zones, daylight savings<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">2) Participation - online and offline.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">3) Reviews<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">4) Non core-code contributions<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">5) Varied views on what is important for the project<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">(1) is mostly a joke, but seriously.  For (2), this is somewhat a response to (1). We have contributors spread across all timezones, which makes regular live collaboration a challenge. For me, I know I can
 either stay up late and catch our friends in APAC, or wake up early to get more cycles with our EU partners. I think that while the AC meeting calls are a great forcing function to meet, we need to make sure we are effective at getting attention and collaboration
 on issues offline as well -- for example though GitHub issues. This should be the primary communication as it'll allow for the most community equity (time and langauge), as well as a good forcing function to ensure we have a higher level of collaboration in
 place so the AC calls are as effective as possible.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">For (3) -- I feel guilty of this, but we need to make sure we all make time for helping with reviews.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">For (4) -- we have been very reliant on a few heros to make sure our "less shiny" code that keeps the project stable is maintained. While it has improved, I worry that we need to have more contributors to
 our CI and CD infrastructure. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">For (5) -- As each group has their own use cases for Kata Containers, there are naturally different views on what is top priority for the project. As an example, I am very tied at the moment to the Go implementation
 of the kata shim - as a result all of my development and fixes are against this. Knowing I will need to migrate to another implementation in the future is a stress-point for me, and a risk for my usage. Having said that, I know *not* migrating is also a risk,
 as a large percentage of our users are focusing on the rust shim.  This is a trade-off, and knowing that we need to plan for and accommodate such conflicting priorities is a big part of driving this project.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:11.0pt">-Eric<o:p></o:p></span></p>
</div>
</div>
</div>
</body>
</html>