From the article "... To make GitLab better faster, we need more data on how users are using GitLab. SaaS telemetry products, which provide analytics on user behavior inside web-based applications, have come a long way in the past few years. They are an important tool for rapidly improving user experiences because you can understand what users are doing (or not doing) in the app. GitLab has a lot of features, and a lot of users, and it is time that we use telemetry to get the data we need for our product managers to improve the experience."
This doesn't seem like a sufficiently good justification add telemetry features which some users may find objectionable.
Perhaps those resources would be better spent on a feature that let the user who is annoyed by a slow operation to:
- Begin recording user interaction telemetry locally
- Perform the slow or buggy operation
- Stop recording, generating a data bundle file.
- Allow the user to review the data bundle in human-readable format
- Optionally take the data bundle to a less secured system as needed
- Submit the data bundle to GitLab engineering as a well-filed issue
Done that way, I think most users would welcome the interaction with Gitlab. For telemetry, not so much.
This doesn't seem like a sufficiently good justification add telemetry features which some users may find objectionable.
Perhaps those resources would be better spent on a feature that let the user who is annoyed by a slow operation to:
- Begin recording user interaction telemetry locally - Perform the slow or buggy operation - Stop recording, generating a data bundle file. - Allow the user to review the data bundle in human-readable format - Optionally take the data bundle to a less secured system as needed - Submit the data bundle to GitLab engineering as a well-filed issue
Done that way, I think most users would welcome the interaction with Gitlab. For telemetry, not so much.