FY25-26 SDS2.2.7 / SDS 2.3.3 Application Permissions
Product Requirements Lite
STATUS: Starting Feb 18-19, 2026
| Reviewer | Date approved |
|---|---|
| Karen Hernandez | February 23rd, 2026 |
| Balthazar Rouberol | February 24th 2026 |
| Mikhail Popov | February 23rd, 2026 |
| Sam Smith | February 24th, 2026 |
Objective/Hypothesis
If we confirm role-based needs for GrowthBook users (humans, automation scripts from WMF, affiliates with established trust, and prospectively, vetted NDA end users), ensure automatic de-provisioning of stale users with regular report back to DPE, and update documentation to describe the role-based approach and user expectations regarding permissions and system interaction, user onboarding will be more predictable, and we'll have some additional guards to avoid exceeding our paid licensed seating.
How does this objective/hypothesis relate to organizational goals?
This hypothesis supports the fiscal year 2025-2026 annual plan for the Product & Technology department to deliver on SDS objective 2 KR 2, which states:
SDS Objective:
Product managers can quickly, easily, and confidently evaluate the impacts of product feature changes in Wikipedia
Key Result:
Before the end of Q3, results for at least one web experiment can be analyzed and viewed in GrowthBook.
This work is anticipated to have the possibility of crossing quarter boundaries given its start time and time left in FY25-26 Q3 (end of March). This is fine. This is one logically connected set of process and technology problems to solve. And, the technical system design sprint for the integration of GrowthBook and Test Kitchen (occurs early March 2026 ahead of full integration) may show needs that imply things about application permissions and automation we hadn't conceived of; although it's unlikely to cause a sea change in what we already understand as the work ahead.
Why do this?
The GrowthBook role structure is useful for avoiding mistakes. And we want to manage our paid license seats, while also ensuring users utilize the system effectively.
Breakdown of the high-level pieces of the work involved
- IM(s) for heads up to people that we'll be arranging some discussion about role needs, inbuilt roles of GrowthBook, etc.
- Meet people about role stuff in GrowthBook
- Define any group adds/modifications for SSH or LDAP or both for seating caps and for role-specific needs (we've IM'd about the need most likely for group membership that strictly avoids exceeding caps)
- Identify strategy for automation IDs and their API keys (admins can make and toss API keys in the system, but we just want to put a little shape around this)
- Automate deprovisioning of stale accounts
- Automate recurring informative notification about licensed user seating (EDIT 2026-05-29: this is a dashboard, actually)
- Write/update wiki documentation - for users and for operators. This includes access request process, pointers on understanding responsible use of system, and how to do operator things. There's more, but those are the basics.
[N/A] Possibly define any farther future things to consider in light of what we may discover (although we don't anticipate huge surprises; but you never know)
- IM notify people of what's in place
Scope/success criteria
At the end, wiki pages are updated for users and operator SOP, and automation is running healthily.