I don't know what that means, but this is the handbook page on my position: https://about.gitlab.com/handbook/marketing/community-relati...
although I've been needing to update it a bit. My job is to basically relay feedback to the rest of the company, and relay any information back to you all that might be relevant. We don't wanna be out-of-touch with what people are really saying about us, and we wanna make sure you're input is received, so that's basically why my team exists.
My questions come from the fact that you, and others from Gitlab, are coming out of the woodwork in groups in response to public negativity and trying to play it cool, eg "wanna".
At least to me, it feels hollow, just like your response right now. It makes me think that Gitlab knew that there was going to be a backlash, and only sent your team out to mitigate damages. "There is no such thing as bad publicity" sort of deal.
If Amazon did the same thing you were doing right now, everyone would be up in arms.
It is the feedback from you all that is responsible for us rolling back the ToS and reconsidering our approach to this. My job, genuinely, is to relay concerns back to the people who make decisions like this. Sid has said in another comment that he wasn't expecting praise, but didn't expect the backlash to be this bad. If they were I really wish they would've given me a heads-up
I think you're reading too far into it. GitLab announced something and received a ton of backlash for it, so they are understandably trying to minimize damage.
It was more than an announcement. They cutoff access to gitlab and broke automated workflows. It shows that they don't know their customer base that well if they were willing to do that. Surely they knew they'd break automated workflows?
So, either they don't care that they broke those workflows when they made this change, or they didn't know that the workflow breakage would be bad. Both are shitty and implies a lack of understanding of their core user base. So, sending customer reps out like they are now screams to me that gitlab really only cares about presentation.
OK, here's what we're saying (most of which is covered by the GDPR principles):
1. Telemetry of any kind from a self hosted instance of your product MUST be opt in. Telemetry from your SaaS SHOULD be opt in.
2. The type and content of data that is collected MUST be documented.
3. That data MUST only be collected by Gitlab under a privacy policy and if it is collected by a 3rd party, that 3rd party MUST comply with the Gitlab policy. Changing a TOS doesn't cover it at 30 days notice doesn't cover it.
4. Under GDPR, any and all data collected MUST be available on demand to a customer. Even if Gitlab is not EU based, you sell to the EU and are therefore covered by the GDPR.
5. The data MUST NOT be saved if the customer ends their relationship with Gitlab and MUST be deleted on request of the customer if it is not required for the service to operate.
6. Under GDPR, the data MUST NOT be used for any purpose other than the documented purposes and MUST NOT be saved beyond the period required.
These are basic privacy principles that apply to ANY business, given that Gitlab operates on data that is highly sensitive (ie a corporation's IPR for their code, a corporation's requirement to also be compliant with GDPR etc), you should be operating to a HIGHER standard.
Thank you for this! We've been creating a point-by-point list like this as well but your point #2 especially is something I don't think we've included, I'll add it.
