Hi Fabiano,
A lot of what Eric and Archana say resonate with me. Here are some additional observations regarding the AC and the community in general. Disclaimer: I have not been in a lot of open source projects, so it can be because my expectations are just too high :)
1. Some of the key areas of the project are under-invested, such as security, performance, stability and production readiness. First of all, from what I have seen, our handling of security tickets lacks a bit of seriousness and sense of urgency. Even though there is a documented Vulnerability Handling https://github.com/kata-containers/community#vulnerability-handling process, I'm not sure if it has been followed. This is kinda ironic considering a lot of the users come to Kata for stronger security. Second, there is no documented performance benchmarking procedure and data. There are many ways to achieve better performance on Kata Containers but they're not publicised. Last but not least, there is still a lot of room to improve the stability and production readiness. We don't have test coverage for a lot of critical path code. One example for lack of production readiness, there still isn't a way to only get the agent error log out of the guest VM. These three aspects are fundamental for attracting more production use cases. I'm hoping the AC can steer more attention of the community toward these three aspects. One suggestion is that we can form special task forces/virtual teams to own these areas so that there is a bit more focus.
2. The community has been quieter than before. The Kata Community is active in terms of new PRs submitted but not so much in discussions no matter online or offline. Not trying to single out anyone, but some of the AC members have been pretty "quiet" too. I think we need more leaders (a.k.a. AC members) to step up and participate in the community more.
3. The Kata Containers project is getting bigger/more complicated with new features such as CoCo and rust-shim. It's becoming harder to keep up with all the PRs. It's not clear how the different decisions are made and what the potential impacts are. It's also not clear who is the stakeholder/decision maker. For example, right now I'm scared to update our downstream to 3.0 because I don't know what the unknowns are and who I can go to if something is wrong. I wonder if we can have a designated owner/POC for each component. The owner can be one person or a team. This assigned "ownership" can also make PRs/issue triage more streamlined.
Thanks, Feng
On Mon, Nov 14, 2022 at 2:51 PM Shinde, Archana M < archana.m.shinde@intel.com> wrote:
Hi Fabiano,
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.
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.
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.
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.
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.
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.
Thanks,
Archana Shinde
*From: *Eric Ernst eric.g.ernst@gmail.com *Date: *Monday, November 14, 2022 at 11:58 AM *To: *Fabiano Fidêncio fabiano@fidencio.org *Cc: *kata-dev kata-dev@lists.katacontainers.io *Subject: *Re: [kata-dev] Elections | Q&A | What are the current pain points with the AC and how to solve them?
Hey Fabiano,
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:
Time zones, daylight savings
Participation - online and offline.
Reviews
Non core-code contributions
Varied views on what is important for the project
(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.
For (3) -- I feel guilty of this, but we need to make sure we all make time for helping with reviews.
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.
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.
-Eric _______________________________________________ kata-dev mailing list kata-dev@lists.katacontainers.io https://lists.katacontainers.io/cgi-bin/mailman/listinfo/kata-dev