As the Growth team [transition](https://gitlab.com/gitlab-org/gitlab/-/issues/364312#transition-coverage-areas) is nearly here, I wanted to hand off the GLEX issues that the ~"group::adoption" team finds important, that will need to be prioritized. | Priority | Issue | Extra | | ------ | ------ | ------ | | team-tasks~3857370 | https://gitlab.com/gitlab-org/gitlab/-/issues/334590 | ------ | | team-tasks~3857529 | https://gitlab.com/gitlab-org/gitlab/-/issues/350944 | https://gitlab.com/gitlab-org/gitlab/-/merge_requests/82392 | | team-tasks~3857543 | https://gitlab.com/gitlab-org/ruby/gems/gitlab-experiment/-/issues/64 | ------ | | team-tasks~3857370 | https://gitlab.com/gitlab-org/gitlab/-/issues/361792 | ------ | | team-tasks~3857523 | https://gitlab.com/gitlab-org/gitlab/-/issues/365378 | ------ | ### Why #### https://gitlab.com/gitlab-org/gitlab/-/issues/334590 There's a medium to mid term risk in regards of if FIPs compliance is rolled out on dotcom without proper communication and planning. All current events on experiments using the MD5 context key strategy will no longer be linkable together with new events that use the SHA2 strategy. #### https://gitlab.com/gitlab-org/gitlab/-/issues/350944 There's mild risk here, and it's just messy. Not addressing deprecation warnings is just not good practice, but I don't need to explain that to anyone. This will eventually impede the ability to upgrade to later versions of the gem -- including for security patches and potentially future FIPs compliance changes. #### https://gitlab.com/gitlab-org/ruby/gems/gitlab-experiment/-/issues/64 No notable risk, but it's an interesting one and we should probably just try to solve it to be nice to people downstream. #### https://gitlab.com/gitlab-org/gitlab/-/issues/361792 Somewhat significant risk here, and it relates to https://gitlab.com/gitlab-org/gitlab/-/issues/334590 -- current MD5 keys are 32 bytes long, but SHA2 keys are 64. Our current schemas only permit 32 bytes, and so these should be updated to use the 1-0-3 schema which permit the long SHA2 keys. If FIPs compliance is rolled out on dotcom, all experiment schemas on events would be considered invalid because the 1-0-0 schema version doesn't allow for the longer keys. This also should be communicated downstream to verify that the data structures inside snowflake/etc. allow for the longer keys as well. #### https://gitlab.com/gitlab-org/gitlab/-/issues/365378 No huge risks here, but it's clearly something that's part of the FIPs initiative and we should do our best to support that. As far as I can tell, it's maybe a mid priority because nothing would be potentially breaking with it -- but it could potentially keep gitlab from reaching full FIPs compliance -- in which case it might be more important. Someone more versed in that area would be useful to loop in.