diff --git a/candidates/2024.2/TC/sbauza@redhat.com b/candidates/2024.2/TC/sbauza@redhat.com
new file mode 100644
index 00000000..8bde11ed
--- /dev/null
+++ b/candidates/2024.2/TC/sbauza@redhat.com
@@ -0,0 +1,51 @@
+Howdy folks,
+
+That's now been a long time I'm thinking about running for a TC seat but I
+never really thought about it until today. Now, I think this is the best time
+for me asking you to accept me as a TC member and I'll explain why below.
+
+First, in case you don't know me yet, I'm Sylvain Bauza (bauzas on IRC),
+working on OpenStack since... wow, 11 years already ? I first started to test
+OpenStack Diablo and Essex for a SME company but eventually moved to another
+(and then another) position and became contributor, first to the Blazar (that
+time named Climate) project and then Nova for 10 years now, eventually becoming
+nova-core and PTL.
+
+Time flies and now I'm still there, happy with what OpenStack became. Of
+course, it changed. But honestly, I haven't seen more operators using it
+previously than now, which means that we succeeded as a team to make OpenStack
+useful for our users. As a Nova PTL for the previous cycles, I know how
+important it is to get feedback from our operators and how much this is crucial
+to provide help for them.
+
+The last discussions I had with the community led to me think that this motto
+needs to be addressed as a whole and not only on a per-project basis, hence
+convincing myself that I should run for a TC seat. As someone evolving from a
+operations position in a SME company to a core developer working with large
+cloud deployments, I wish I could help the TC driving some efforts into
+shortening the feedback loop within the community. I'd also want to help the TC
+provide some guidance on the new SLURP release cadence model to all the
+projects so that we could really achieve a skip-release upgrade that would
+benefit to our operators.
+
+There are a couple of other stuff I do really care and I wish to help them.
+CI gate stability is one of them. Having transient failures close to a
+milestone is not a good experience for us and we need to really address
+those failures as top priorities when they occur. We should somehow recognize
+the very fews who dedicate time on chasing those issues and fixing them, as
+their contributors are mostly valuable, since not a single code of code can't
+merge when a gate is down.
+
+Maintaining our code is another important aspect to me. Recent experiences on
+not-so-well-maintained dependencies led us force to evaluate all the options
+and those decisions aren't easy to make. As someone caring about maintaining
+our code for stable releases, I wish I could help the TC to correctly identify
+risks and benefits of breaking changes and evaluate the impact it may have
+on our feature delivery.
+
+Enough talk, I'll end up here, saying that after those 10 years in the
+community, I'm still enjoying being part of it and how much I do love working
+with all of you.
+
+Cheers,
+-Sylvain