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