You've posted here about your current state, your desired state, and your wish to go from the former to the latter. This is problem solving and you're taking action to find a solution, which is everything but passive.
You claim you lack creativity; I'm a disbeliever until you have irrefutable proof of your lack of creativity.
Now...
Contributing to meetings does not necessarily have to be during meetings. The point of meetings is to drive a project or product forward, so that's what to be optimized. One of the most valuable things you can do, and that does not require thinking on your feet, is to take meeting notes/minutes, with action items, and send them to everyone after the meeting.
If you do not have a template, here's one you can use[0], under section 1.1, "Taking meeting notes". If you send this a few times, everyone will get used to the template and will parse the message really fast, as they would with idiomatic code.
You can create a repository and push the notes to version control. They will be rendered in Markdown nicely on GitHub or GitLab.
You can also augment the meeting notes with resources and analysis. Descriptions of different tools that were discussed, alternative approaches, etc.
You can also take the action items and create the issues in your issue tracker, fully explaining the problem to be solved, the preliminary solution, alternative approaches, likely parts of the code/product to change, related issues, when it is due, which milestone does it belong to.
This plays to your strength, as you can do it alone, in a place and time you are most productive. This is also a highly valuable product. The point is to add value to the team and the product.
This is a hack, because often times people do not contribute during meetings because they feel they will be interrupted, talked over, or not have the time to fully develop an idea. If the person in charge isn't attuned to people's characters, and making sure people do not speak over one another, put out decibel bullying or conversation domination, many people will never talk. You do that, you get heard, and then you'll get comfortable speaking. Supposing you want to.
Taking it a step further, you can tackle some of the problems. Say an issue that has different approaches. You can create several branches and implement a solutiong using different approaches, and then bring these to whoever merges the branches. You are then helping do their job which is "choosing" which direction to go. This is a lot of effort but things will move faster when the team lead or CTO or whoever has three branches and proof of concepts and they can just choose whichever they like. However, in doing that one must be ruthless and be totally fine seeing code they wrote, often during commute or the week-end, never get merged. Some will, and it will drive the project further in the right direction, but I digress.
If you do that (just the notes and refined issues part):
- 1. The opinions you were not confident adding will find their way to the team
- 2. During future meetings people will pause the meeting and ask your opinion
Now have the problem of everyone wanting your opinion on everything.