✨ Feature Request: Consistent Randomization for Time-Based Meeting Queries
🧭 Summary
When users query meetings with a start parameter, results are returned in a fixed order (typically by time and name). This means the same meetings always appear first, reducing visibility for others.
Request:
Introduce consistent (seeded) randomization for these queries to make meeting visibility fairer, while preserving a stable order for pagination.
🧩 Proposal Options
-
👤 Per-User Consistency (Session-Based)
Randomize order per user/session, using a deterministic seed (e.g., session ID + time window). Ensures pagination and repeated queries are stable for the same user.
-
🌐 Global Consistency (Time-Based)
Randomize order globally per time window (e.g., every 15 minutes). All users see the same shuffled order within that window. Easier to cache and predict.
Both approaches would apply only to queries using the start parameter.
❓ Questions
- Which proposal offers the best UX and implementation trade-offs?
- Should similar randomization be considered for feature-based filters?
- What’s the ideal seeding strategy?
🔍 Example
-
Current:
/api/v1/meetings?start=2024-05-20T10:00:00Z
→ Same meetings, same order every time
-
Proposed:
→ Same meetings, randomized order—consistent per user or time window
💬 Feedback welcome!
Please share your thoughts and use cases.
✨ Feature Request: Consistent Randomization for Time-Based Meeting Queries
🧭 Summary
When users query meetings with a
startparameter, results are returned in a fixed order (typically by time and name). This means the same meetings always appear first, reducing visibility for others.Request:
Introduce consistent (seeded) randomization for these queries to make meeting visibility fairer, while preserving a stable order for pagination.
🧩 Proposal Options
👤 Per-User Consistency (Session-Based)
Randomize order per user/session, using a deterministic seed (e.g., session ID + time window). Ensures pagination and repeated queries are stable for the same user.
🌐 Global Consistency (Time-Based)
Randomize order globally per time window (e.g., every 15 minutes). All users see the same shuffled order within that window. Easier to cache and predict.
Both approaches would apply only to queries using the
startparameter.❓ Questions
🔍 Example
Current:
/api/v1/meetings?start=2024-05-20T10:00:00Z→ Same meetings, same order every time
Proposed:
→ Same meetings, randomized order—consistent per user or time window
💬 Feedback welcome!
Please share your thoughts and use cases.