diff --git a/candidates/2024.2/TC/sbauza@redhat.com b/candidates/2024.2/TC/sbauza@redhat.com
deleted file mode 100644
index 8bde11ed..00000000
--- a/candidates/2024.2/TC/sbauza@redhat.com
+++ /dev/null
@@ -1,51 +0,0 @@
-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