- I think we need a centralized bug tracking bulletin that clearly lists open and known issues. Currently, it's exhausting to constantly monitor forums, self-diagnose problems, or attend every event session just to stay informed. It’s highly inefficient for every user to independently discover, research, and submit tickets for the exact same bugs. This transparency would actually be a huge asset to MV's Dev and QA teams. By seeing what's already known, users would know exactly what details to report based on how a bug impacts their unique setup, giving QA better data without a flood of duplicate tickets that aren't linked together.

 - Additionally, a proactive notification system—like a quick newsletter or alert—detailing new bugs that emerge immediately following an update would be a game-changer. Right now, it feels like I have to revert to a previous, more stable release after updates more often than not just to keep production moving.

- It’s difficult to trust new updates. I understand the immense complexity of testing every permutation of builds, libraries, settings, and products, and that QA cannot catch everything. However, even when keeping our setups as close to the recommended stock Foundation Library as possible, we still experience persistent issues. When a new update drops, it might fix old problems, or add a new feature that's great, but it frequently introduces new issues that make it not practical to use.

- New users and veterans alike should be able to trust that the software will work correctly out of the box, or be patched swiftly. Until that level of stability is reached, known issues must be posted in an accessible, common location so we can quickly determine if an update will negatively impact us.

- I would much rather see Microvellum bias the focus towards solid stability and frequent, reliable patches than receiving many new features every month—no matter how cool or impactful those upcoming features might be. Anyone else agree with this approach or have other suggestions?