01
Step one: define the listing criteria
Before testing anything, write down what qualifies. Useful criteria include working on named headsets, a stable launch, clear controls, comfort options such as snap turning, a described play area, and an honest store description. Decide which are required and which are bonuses. Example: a rhythm game submitted for a directory must run on two common headsets, offer a tutorial under five minutes and list its seated or standing needs. Anything missing the required items goes back to the developer with a note. A written checklist keeps decisions consistent across reviewers and protects you from favoring familiar publishers.
02
Step two: test with a short, fixed session
Run each experience for a set time, such as twenty minutes, and record the same observations every time: load time, first-minute clarity, motion comfort, bugs, and whether the experience delivers what its page promised. Continue with the rhythm game example: note whether the tutorial teaches the core action, whether track difficulty is adjustable and whether any moment caused discomfort. Use a second tester for borderline cases, since comfort varies between people. Keep notes factual and brief, avoiding scores until the full set is gathered. A fixed session makes entries comparable and prevents long, impressive finales from hiding weak openings.
03
Step three: decide, label and revisit
Finish with one of three outcomes: list, list with a caveat, or decline with feedback. Write a two-sentence summary that states who the experience suits and any limits, such as 'best for seated players with a fast headset'. For the rhythm game, a caveat might note that multiplayer is still limited. Record the review date and headset version tested, then schedule a re-check after major updates. Keep sponsorship separate by labeling any paid placement and never altering the verdict. This leaves readers with dependable entries and gives developers a clear path to improve and resubmit.