I checked FPCA and it looks like I also have to sign it so that it is possible to include the test cases as Content Contribution, so I have signed it.
I don’t think I can commit to doing enough QA work to belong in a dedicated group.
Also, it appears that special link can be used to get raw markdown content of the test cases message.
It’s fine, we frequently have people who sign up and do nothing at all. 
Database entries are pretty cheap! It’s mostly just a sort of ‘make you have to do something to try and avoid spam’ bar. I’ll add you in a bit. edit: I’ve added you now.
Ooh, that’s handy (not just for this case). Thanks.
Thanks! Now I am able to login into Wiki without issues.
I will familiarize myself with procedures and then attempt to move the test cases there.
I have added the test cases to Wiki, but I don’t see Test Cases tab for present mesa builds. Are test cases picked up by new builds only, or have I done something wrong?
All of this got me thinking. @pemensik has mentioned discoverability.
I see a way to track mesa builds with RSS. If I am interested only in Fedora version I am currenly using, is there a way to get notifications for f43 mesa builds only?
Going further, lets imagine a non-very-technial person using Fedora for gaming, audio/video/picture editing, CAD, education, etc. without knowing particular packages affecting their use cases. Nevertheless, they may be interested in testing such packages in advance, on their own schedule, to make sure that nothing unexpected happens and their workflows are not going to be disturbed.
It may be beneficial to have an easy way for end-users to get notified (if they opt-in) on new updates-testing builds affecting applications they rely on. It is likely non-trivial to implement a system like that, but it may be something worth considering strategically.
Basically something like
$ sudo dnf check-update --enablerepo=updates-testing
accenting affected user-facing applications and providing better granularity.
Ideally, as a notification not relying on user logging into their PC to receive it.
I may be misremembering, but Gnome-Software and KDE-Discover are doing not that great with regular updates, aren’t they? Bundling most of packages into “System” category, not displaying affected user-facing applications, giving no option to update/downgrade packages affecting single user-facing application etc.
So I have browsed bodhi source code and it looks like test cases are fetched on non-automatic update creation/edit.
Corresponding MediaWiki API query returns the pages, so it should be ok.
Also I see that RSS or any other kind of server side notifications for (transitive) dependencies are non-trivial to implement indeed, so something to solve that client-side appears to be much more feasible.
It’s done at update creation time, so only for new ones.