We don't have a public-facing bug tracker at this time and I'm not personally aware of any plans to introduce one. Here's some background on our internal process that might be helpful though:
Bugs are filed in an internal system with a Priority, Severity, and Target Release. For bugs that are not S1/P1 (Critical), Target Release often starts as "Backlog" until we perform a more in-depth investigation and see where it can slot in with team resource planning and related items (we often fix batches of bugs in related areas together). At some point, the Target Release gets updated to something like "Forms 11 Update 3". This is not set in stone and often changes.
The releases themselves usually have flexible target dates like "by March" or "sometime in Q3" that aren't finalized until close to when the release is actually ready, and before then are frequently subject to change. For example, if close-ish to a Forms update release we get a few S2/P2 (High) bug reports, we might delay the release a month in order to fit those in. As release deadlines approach, we triage outstanding features and bugs to see what we can squeeze in. Items that don't make it get bumped to the next release (e.g., "Forms 11 Update 4") or put back on the backlog.
I've probably made that process sound more chaotic than it really is. Software development has many moving pieces and shifting priorities and we have processes, procedures, and tooling to manage all this.
You're welcome to check in with Support asking for an update on a specific bug number at reasonable intervals (months, not days) with the clear understanding that both the target release and target release date (if known) are flexible and subject to change (unless we've made a firm commitment in writing otherwise).