Open Stack

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 at gmail.com>
Date: Monday, November 14, 2022 at 11:58 AM
To: Fabiano Fidêncio <fabiano at fidencio.org>
Cc: kata-dev <kata-dev at 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:
1) Time zones, daylight savings
2) Participation - online and offline.
3) Reviews
4) Non core-code contributions
5) 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.katacontainers.io/pipermail/kata-dev/attachments/20221114/3feb388b/attachment-0001.htm>