4 ms·
There was apparently months of internal discussion on this topic [0][1][2][3] (edit: particularly here [1.5] "It's not practical to send all of this metadata wi
by couchand 7y ago
There was apparently months of internal discussion on this topic [0][1][2][3] (edit: particularly here [1.5] "It's not practical to send all of this metadata with every event, especially since we don't know what metadata we'll need ahead of time. In order to do anything beyond surface-level analysis, we need to be able to join on user_id."). In the end, the folks at the very top overruled the (relative) consensus that had been reached by Engineering, Product [4], and Compliance [5] that the tracking should only be done on an opt-in basis.
Paul Machle, CFO, responding in no uncertain terms that the consensus was not acceptable: "I don’t understand. This should not be an opt in or an opt out. It is a condition of using our product. There is an acceptance of terms and the use of this data should be included in that." [6]
The real juicy discussion seems to be on a private repo [7].
The final implementation plan [8] shows that tracking will be non-optional, including for self-hosted EE instances.
[0]: https://gitlab.com/gitlab-org/gitlab-foss/issues/64341 https://gitlab.com/gitlab-org/gitlab-foss/issues/64341
[1]: https://gitlab.com/gitlab-org/telemetry/issues/57 https://gitlab.com/gitlab-org/telemetry/issues/57
[1.5]: https://gitlab.com/gitlab-org/telemetry/issues/57#note_190415032 https://gitlab.com/gitlab-org/telemetry/issues/57#note_19041...
[2]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182 https://gitlab.com/gitlab-org/gitlab/merge_requests/14182
[3]: https://gitlab.com/gitlab-org/telemetry/issues/58 https://gitlab.com/gitlab-org/telemetry/issues/58
[4]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#note_203848357 https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...
[5]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#note_185762038 https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...
[6]: https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#note_203849107 https://gitlab.com/gitlab-org/gitlab/merge_requests/14182#no...
[7]: https://gitlab.com/gitlab-com/gl-security/compliance/compliance/issues/656 https://gitlab.com/gitlab-com/gl-security/compliance/complia...
[8]: https://gitlab.com/groups/gitlab-org/-/epics/1937 https://gitlab.com/groups/gitlab-org/-/epics/1937
- ktsmith 7y ago> Paul Machle, CTO Paul is the CFO.
- couchand 7y agofacepalm thanks for the correction. Edited.
- Aaargh20318 7y agoWhy the fsck does the CFO get involved in what should be an engineering decision ? Why does he even get a say in it ?
- NullPrefix 7y agoObviously the CFO sees that sweet telemetry cash
- apple4ever 7y agoExactly. I worked for a company where the CFO got involved in engineering and operational decisions. And they were always terrible. If I had a CFO who said that, and I was the CEO, he'd be fired.
- flukus 7y agoSurely that's a soon to be former CFO considering the reputational damage he's caused. Gitlab on premise was an easy sell to companies and now they've lost trust and their main differentiating factor from github. How could I possibly recommend gitlab in future with people like this running the company?
- dennisgorelik 7y agoThat is an excellent analysis of how that Gitlab telemetry fiasco was conceived. It is also good to see who was in charge of that fiasco: https://www.linkedin.com/in/paul-machle-445ba41/ https://www.linkedin.com/in/paul-machle-445ba41/