Update on free software and telemetry (about.gitlab.com)
For GitLab.com users: as we roll out this update you will be prompted to accept our new Terms of Service. Until the new Terms are accepted access to the web interface and API will be blocked. So, for users who have integrations with our API this will cause a brief pause in service via our API until the terms have been accepted by signing in to the web interface.
For Self-managed users: GitLab Core will continue to be free software with no changes. If you want to install your own instance of GitLab without the proprietary software being introduced as a result of this change, GitLab Community Edition (CE) remains a great option. It is licensed under the MIT license (https://en.wikipedia.org/wiki/MIT_License) and will contain no proprietary software. Many open source software projects use GitLab CE for their SCM and CI needs. Again, there will be no changes to GitLab CE.
Key Updates:
- GitLab.com (GitLab’s SaaS offering)and GitLab's proprietary Self-Managed packages (Starter, Premium, and Ultimate) will now include additional Javascript snippets (both open source and proprietary) that will interact with both GitLab and possibly third-party SaaS telemetry services (we will be using Pendo(https://www.pendo.io)).
- We will disclose all such usage in our privacy policy, as well as what we are using the data for. We will also ensure that any third-party telemetry service we use will have data protection standards at least as strong as GitLab and we will aim for SOC2 compliance. Pendo is SOC2 compliant.
If you have any questions please contact us at support@gitlab.com
270 comments
[ 3.7 ms ] story [ 332 ms ] threadGitLab Team" in order to fit into 2k char limit.
EE will respect a DNT header. Not amazing, but certainly not impossible to manage. (But on a per-browser basis is still a hack. It should be manageable by the instance itself. Maybe it will be once they have this ready everywhere.)
I also believe this isn't rolled out for self-hosted at all yet:
> 5d Scott Williamson We are not adding Pendo or Snowplow JS snippets to self hosted versions yet. That will likely come in a second phase of the project, and we will figure out opt in/opt out for those scenarios before launching. The reason we are communicating to those customers about it now is so we don't have to do the privacy policy change twice. So for now it's just .com customers. I will let @Tim Hey respond on where he would like discussion on this to go. [0]
[0] https://news.ycombinator.com/item?id=21339805
Doesn't this make it not "opt-in-by-default"?
> “Freely given” consent essentially means you have not cornered the data subject into agreeing to you using their data. For one thing, that means you cannot require consent to data processing as a condition of using the service. They need to be able to say no. According to Recital 42, “Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment.”
https://gdpr.eu/gdpr-consent-requirements/
Hopefully that's a mens rea on violating GDPR.
> The primary responsibility of the new growth team is to run experiments
Ah, the new growth team. I guess that explains it all. They hired "growth hackers" now.
EDIT: interesting bits from the thread under that link:
> Luca Williams (PM/Fulfillment): The general consensus I've heard through many conversations and discussions from an executive level is that opt-in is not preferable. Opt-out is the default.
And that's precisely why GDPR happened. Because executives of companies think "opt-out is the default".
> Dennis Tang (Frontend Engineering Manager): Correct, you could still call it an opt-in though, as in they're "opting-in" not to see the notice again...
That's in context of calling a TOS change notification popup dismissal 'technically opt-in', but it's a pretty mind-mending way of interpreting what "opt-in" means.
> https://gitlab.com/gitlab-org/gitlab-foss/issues/64341#note_...
That would suggest they already collect a lot of data, but keep it anonymous. The proposal in the link would essentially turn it into instant GDPR violation.
--
I've mostly only skimmed the thread, but it seems to me that a lot of words were written about whether or not they should include a detailed opt-out feature, with apparently no one realizing that GDPR would require this to be opt-in.
https://www.gdpr.associates/dutch-dpa-microsoft-breaches-dat...
frontend devs urgently need to learn to write more robust code.
I’m not really sure why they’re thinking this is a good idea.
If I tell the legal team that our source control software is sending off data to the vendor and some random (unspecified?) third parties, they’ll have a fit.
Frankly, I used to work at a DoD contractor and we ran GitHub Enterprise and GitLab behind secured networks. That kind of expectation -- that the software will never phone home -- was what let us run and justify them in the first place.
Edit: Looks like the comment I replied to has been changed, and essentially removed. I'm sorry if this is now out of context.
It's not even take it or leave it, one has to agree first in order to leave.
It seems whoever approved this, forgot why people arrived to GitLab from GitHub.
i wonder if their projections for enterprise aren't adding up, or Hub has started to eat their lunch enterprise wise with new features that Lab hasn't copied yet, or API integrations, or something else
Let people speak, and listen.
While I’m here. You also keep talking about opt-out functionality, but the only way this is going to go over reasonably well is if the whole thing is opt-in.
Choice is good, more things like this mean that there's less of a differentiating factor between hub and lab.
(I was going to post a wall of text about maybe "compassion fatigue with users privacy at odds with debugging" or "the rise of the marketing department" or "monetization strategies"... but the four words above are more succinct)
It can be sometimes, with a kludge. Or by understanding the internals of the toolchains you use. But not all toolchains _can_ be run under another operating system. Or can only be run by violating the rather expensive support contract.
Well, the market share numbers tell a very different story.
Sure, percentage wise, the majority of desktop computers are on Windows.
My point was that 'we' didn't accept Windows telemetry. Some people did.
This would be a better link.
Gitlab may have some watertight contract with pendo but that doesn't mean anything to me as a user since I cannot see what is transmitted and how often that is done.
Compare to how canonical does this: tell user we are about to send data and show them what is being sent.
Blocking service until the user consents is illegal under GDPR, especially when the consent is requested for data collection that is not essential for providing the service, such as telemetry and analytics.
https://gdpr.eu/gdpr-consent-requirements/
> “Freely given” consent essentially means you have not cornered the data subject into agreeing to you using their data. For one thing, that means you cannot require consent to data processing as a condition of using the service. They need to be able to say no. According to Recital 42, “Consent should not be regarded as freely given if the data subject has no genuine or free choice or is unable to refuse or withdraw consent without detriment.”
https://about.gitlab.com/privacy/
> Third party tracking services gather certain simple, non-personally identifying information over time, such as your IP address, browser type, internet service provider, referring and exit pages, timestamp, and similar data about your use of the Website. We do not link this information to any of your personal information such as your user name.
They don't have to link your IP address to your name, because the IP address itself is already an identifier and so considered personal data.
[1] https://ec.europa.eu/info/law/law-topic/data-protection/refo...
The _PAID_ self-hosted instances will have non-optional telemetry that loads remote javascript inside an enterprise? Any enterprise that seriously wants to self-host will look at this statement and flip a table.
The business has to be sold on Gitlab by the developers.
Are you aware of the privacy concerns surrounding reCAPTCHA? https://en.wikipedia.org/wiki/ReCAPTCHA#Criticism
> We are not adding Pendo or Snowplow JS snippets to self-hosted versions at this time. We are carefully considering the appropriate opt-out functionality for telemetry that will work best for our customers, and we will clearly communicate to those customers when any change is made.
In other words, it's not that self-hosted will not be affected, it's that self-hosted will not be affected yet. That's an important distinction.
A lot of services, newsletters, promo, telemetry, are by default opt-out. When you install some chat app, it also syncs some data (e.g. contacts maybe?) and then you can go in the settings and opt-out for that sync..
Let's be real here, the difference between opt out and in is probably several orders of magnitude worth of data. It's like, would you rather have a Megabyte of telemetry to analyze or a Gigabyte?
Since a few weeks, our hackerspace - which used to publish all door unlocks on IRC with the nickname of the person unlocking it, by default - requires opt-in for nicknames to be published.
People recognize that this is an important social function of the space, because it ties together the IRC channel and the physical space, and thus the vast majority(!) of members have explicitly opted in.
This whole narrative that "if you make it opt-in, not enough people would ever do it" always conveniently leaves out that that's only true for things where people don't want to opt in, ie. usually things that benefit the service but not the users.
Small companies are generally more trustworthy, until they come to a position of dominance, where they are just there to squeeze.
Our enterprise security people would complain about data exfiltration risk. GitLab would only survive if the security people approve it & that is a LOT of extra work for the internal team that keeps GitLab sold within the company.
There's your problem. This should be entirely opt-in.
Blog post isn’t the best way to collect feedback. Just ask your customers directly.
10 bad title on internet is enough to screw your reputation on 10m developers that probably don’t even follow up the story or even don’t bother to read anything beyond Reddit titles and comments. But then you have 10m developers telling their managers “Oh Gitlab isn’t good”.
We're in the process of taking a 50user Premium (aka self-hosted) GitLab subscription, don't make us reconsider and search alternative means.
[0] https://edps.europa.eu/press-publications/press-news/press-r...
[1] https://tweakers.net/nieuws/158892/
ps: SOC2 does not inspire confidence as the whole of EAA needs to follow GDPR.
This doesn't seem like you're pumping the breaks "completely".
It's baffling to me that you would try to run telemetry on self-hosted PAYING customers. Seems totally backwards.
This means they would have to change the ToS before trying to implement it again, which means the current result isn't moving the goalposts at all and is not a step forwards to the original solution.
See: https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/... and https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/...
I don't know what did you expect?
Of course the feedback is negative. You obviously knew it would be because you made that blog post in the first place. Three months from now you'll have made some cosmetic changes while still collecting basically all the data you wanted. Eventually you'll be ramping up to roll this into your enterprise offering. I'll do another round of source control tool research and hopefully be able to move gitlab to the NRND list in internal documentation.
That's how it will go, because that's how these things always play out. The world will keep spinning.
I see only one option: remove all telemetry and make a blogpost about why that idea was bad that you will not implement it. And even doing so harm is already done. Now you can minimize harm by making such post as fast as possible.
Nevertheless I do think this is different since management defers decisions about software versioning and life-cycle management in general to developers. I do think this will cost them some hard earned customers.
Certainly a bad move and I doubt it will amortize.
However, I'm relatively sure that this is due to the efforts of our very talented Windows Systems Administrators. Nonetheless, it's possible.
How in the world can you possibly call it "putting users first" to take users' money and use it to pay someone to do things that don't benefit those users? Seems a lot more like you're using the company money to pay for things you want someone to work on, not your users. How can that be the company's top priority and the first hire?
(throwaway account because Drew holds grudges for years when people question him)
[1]: https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...
I'm extremely proud to be sponsoring Simon's open source work, and I'm looking forward to sponsoring others. I don't intend to turn SourceHut into an Uber-esque business where a veritable army of developers is sitting around and doing nothing. Most SourceHut users who have been keeping abreast of my plans have known that I wanted to re-invest the profits in open source, and this is how I've chosen to do it. This does benefit SourceHut users, by enriching the open source community in a way no other company is doing.
>(throwaway account because Drew holds grudges for years when people question him)
I don't know where this came from, but it's not really appropriate. It seems more likely that you have a grude with me.
>I don't know where this came from, but it's not really appropriate. It seems more likely that you have a grude with me.
Reality: you've treated many people harshly over the years for disagreements, questioning, or what have you. There's a reason a few people come out of the nooks with anon accounts to speak up about this.
To me this whole debacle feels like a forced error. Gitlab needs to find a way to profitability - fine, I am very much in favour.
But I can't shake the feeling that somewhere, someone, has made the mental association that "more user tracking == more money". It's worked for Google and Facebook, and it looks to be working for -vomit- modern infosec industry, where ever more aggressive end-user surveillance seems to be the easiest way to get two or even three bites of the apple.
And that is why this whole thing feels like a re-enactment of a South Park episode:
Because from what I have read so far in this thread and the early linked issue, it does feel like shoehorning invasive user tracking has been a foregone conclusion and figuring out a justification has come second.It's so much more than that. They need a way to justify their $2.75B valuation, and to keep going up. Profitability is a walk in the park in comparison.
It's hard to trust VC backed enterprises nowadays because even if founder is nice it is pretty challenging to go against investors. It's not asways a bad thing because it creates many opportunities for us, small/solo companies, when we can exist to provice stellar services for our customers.
Do I have to agree to the TOS at this time?
Safari has already removed it in version 12.1 (https://developer.apple.com/documentation/safari_release_not...), so if that's the only opt-out mechanism there's no way for Safari users to make that choice. That probably includes all iOS users, since all iOS browsers just wrap Safari.
I wouldn't be surprised to see other browsers remove it eventually as well. Like Apple says, it ended up doing the exact opposite of what it was supposed to -- almost nobody obeys it anyway, and it hurts the privacy of people that try to use it by contributing an uncommon factor to their browser fingerprint.
https://www.vice.com/en_us/article/ywen8x/13000-projects-dit...
I'm self hosting my projects on one of my servers but I have some projects on GitHub because I want them to be public. I copied them on GitLab one year ago and switched origin. I feel like I won't keep using that service now. Bitbucket is quite a pain to use so it's not an alternative.
https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...
An article next month is going into detail on stability, but the short of it is that if the service meets your needs now, it's ready.
[1]: https://lobste.rs/s/zxokqi/finding_new_git_host#c_viqwir
An equal and opposing argument:
Email patches? You’re going to make me send an email patch? I can’t tell if you’re joking or serious... you’re... serious? Shall I write my patch into the computer via morse code as well? How could you possibly expect someone to take the time to jump through all the hoops that your massive ego and nostalgia for the past requires?
Oh wait, that sounds arrogant and childish too...
(This subthread reminds me that I meant to make an account there and start migrating some of my projects.)
https://sourcehut.org/blog/2019-10-15-whats-cooking-october-...
I've always been of the opinion that email works better for me, and I think that too many people write it off without giving it its fair chance, but I've also conceded that many people enjoy the web-based workflow and I've been working on tools to accomodate them.
People started boycotting GitHub before GitHub even did anything wrong.
1. https://news.ycombinator.com/item?id=19182956
2. https://tech.slashdot.org/story/13/12/14/1618239/github-take...
To me, not knowing when or why my software might be dropped is a fatal flaw for a service that exists to serve source code.
edit: Ah I see you work for Microsoft. In that case it's not surprising you are stating that there are no reasons to leave
Although I should say, I am pretty pissed off about them blocking Iran. Would've rather seen Microsoft apply for a sanctions waiver for github.
Acquisitions happen all the time, but how many of those acquiring companies experience an almost immediate "mass exodus" of users? (I'm sure there have been others in recent history but I'm having trouble thinking of any at the moment -- other than GitHub, of course.)
Perhaps you should ask yourself why?
Why would all of those people immediately up and leave and boycott GitHub, especially "before GitHub even did anything wrong"?
Microsoft has certainly pulled the wool over the eyes of many... but some of us have both 1) been around for a while and 2) have a very good memory.
---
By the way... you aren't exactly "new" here, so surely you're aware that it's considered appropriate to disclose any relevant affiliations when commenting?
I spoke out against people moving out before I joined them. I certainly don't try to hide where I work :)
Thank you though, I'll add it to my bio.
From inside GitLab Slack:
5d Scott Williamson We are not adding Pendo or Snowplow JS snippets to self hosted versions yet. That will likely come in a second phase of the project, and we will figure out opt in/opt out for those scenarios before launching. The reason we are communicating to those customers about it now is so we don't have to do the privacy policy change twice. So for now it's just .com customers. I will let @Tim Hey respond on where he would like discussion on this to go.
5d Support Engineer Thank you @Scott Williamson, I was hesitant to ping you as I know your time is valuable, but I'm glad that I did. :thank_you::thx::thankyou:
5d Tim Hey Hi @Support Engineer Looks like @Scott Williamson just beat me to the it. :sweat_smile:
5d Support Engineer You both are amazing and I can't thank you enough.
5d Tim Hey Also if you are interested in the being part of the discussion when we build out the opt in for scenarios like this I'd love to include you. I believe Lee was interested.
5d Support Engineer I'd love to be involved! If there's an opt-in or opt-out, it invalidates all the concerns I voiced here. Knowing this, I fully support the decision to add telemetry to self-managed and understand that it would be incredibly valuable for growth.
41m Support Engineer @Scott Williamson @Tim Hey @supportmanagers We have a lot of upset customers thinking that GitLab self-managed telemetry will be mandatory for Self-Managed GitLab moving forward (no opt-out/opt-in) . We need an official response and Zendesk template to help manage the influx
It may not be mandatory now but, by agreeing to the new Terms of Service, it can be mandatory at any time in the future without being notified/needing to agree to the change (since it's already in the ToS). This Slack conversation is just as short-sighted as the blog post.
I'm surprised the proposal to allow third-party scripts (something GitLab doesn't control!) to run on customer's closed environments made it out of a 30-minute meeting.
I've always been curious how this happens. How can a group of people who should know better just ignore or not realize the backlash that will come. There was not a single person who raised a red flag?
You might want to pass on that the current opt in/out scenario won't work everywhere either.
Safari 12.1 removed the DNT header[0] because it was only being used for fingerprinting.
https://developer.apple.com/documentation/safari_release_not...
In retrospect, it's hard to imagine this working out any other way.
Can it come in an ∞th phase instead?
HN is a good opportunity to reach out, so I will use it: there's some kind of dark pattern employed during this Terms-Of-Service switch.
GitLab does not allow to login without accepting the new TOS, which means that I cannot remove my account without accepting the new TOS.
I didn't use gitlab that much anyway, but the TOS change just reminded me about the need to close the account... yet "you must accept the TOS to login" does not allow to remove the account. So, accepting the new TOS is kind of forced upon if you want to find your way out (in other words, it's made inconvenient and we-will-drag-our-feet otherwise).
Can someone take a look into it? I received two template-responses from email support, but no action.
My support request is 136340.
This was initial response from GitLab to my request (let's call it Template1):
> We understand that you want to completely remove your GitLab.com account.
> Due to the complexity of servicing these requests, we're asking our users to
> please email gdpr-request at gitlab.com.
> Please ensure that you:
> - send the email from the address associated with your GitLab.com account
> - include the GitLab username you'd like removed
I did send an email to that address repeating my request, but shortly after I received this response (let's call it Template2):
> We have additional updates with regards to our TOS and Telemetry services
> below:
> We understand that the recent announcement regarding the update to our Terms of
> Service, specifically in regards to Telemetry, can lead to questions you have
> about how it impacts your usage of GitLab.
> To answer those questions and gather feedback on this recent update, we have
> created this Issue with additional clarification. As we firmly believe that
> everyone can contribute, we want to assure you all feedback you provide via the
> Issue is both welcome and appreciated.
> Kindly advise if you would still want us to proceed with this request.
I repeated my request, reaffirming that I want to remove and erase my account. In response, they sent "Template1" email again.
Edit:
to be fair, it's been less than 24 hours since the request, and the repeated template-response from GitLab may have been a hiccup on the support side.
But the whole new TOS switch could be handled much better and without dark patterns, i.e. during login, two buttons:
[Accept new TOS] [Decline and erase account]
However, right now there's simply no option to handle account removal conveniently when I want to decline the new TOS.
Actually, that's still a GDPR violation. A user cannot sign away their rights in the ToS. From https://gdpr-info.eu/art-7-gdpr/ "Conditions for consent":
If the data subject’s consent is given in the context of a written declaration which also concerns other matters, the request for consent shall be presented in a manner which is clearly distinguishable from the other matters, in an intelligible and easily accessible form, using clear and plain language. Any part of such a declaration which constitutes an infringement of this Regulation shall not be binding. [..] When assessing whether consent is freely given, utmost account shall be taken of whether, inter alia, the performance of a contract, including the provision of a service, is conditional on consent to the processing of personal data that is not necessary for the performance of that contract.
In other words, if Gitlab ties the consent for telemetry together with access to the service itself, the consent is considered not freely given and therefore not legally binding at all.
At this point I would simply wait the 30 days or whatever they have to respond and if they don't, complain to your data protection commissioner. They could get hit with a big fat fine for it, so its in their interest to make sure they respond correctly and don't send you around in circles.
That only applies to Personal Data. It doesn't close your account or delete your source code. etc.
I believe this is what Discord does. If you delete your account, or if you request it to be deleted, it does not delete your comments, your name changes, your profile photo gets removed, but the comments are still there. Are they not considered personal data? Call me paranoid, but I do not believe that your comments actually get deleted even when you delete them either, I would say they just get hidden.
Regardless, happy to clarify whatever I can.
And, of course, helps them make more money so they can hire more people/stay alive/etc.
I've always disliked GitLab as a company - they seem to be too full of themselves.
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.
1) 99% of users who have a bad experience are not going to be bothered to figure out how to record, review, and submit their session for the benefit of the service provider. If a page has issues loading, they're just going to give up and move on to the next thing.
2) User tracking isn't really related to performance in the first place. If some server side operation is failing or taking a long time to load, engineers will find out (and probably get paged) with user-agnostic internal performance metrics.
3) User tracking isn't just about finding out what's broken with the site, its about understanding how the site is being used in general so that you can validate your assumptions and make product decisions backed by data.
It means that they are fine with these issues and don't need to have them fixed.
GitLab, you're not a cut-throat company run by the Ferengi, desperate to eke out a tiny bit of extra profit by whatever means necessary. You have what it takes to do it right and set an example for others.
Compared to direct user feedback where a user might use some functionality twice a year, but rank it high as something that needs to be improved because it's sort of backwards. Instead of improving the performance and flow of the functionality they use hundreds of times daily, because they're reasonably happy with how it works. It's not that you don't want to fix the former, but it's obviously not business critical to perform often, and it's not considered high priority yet.
Disagree. User feedback, however biased or incoherent, is a direct representation of real people with real issues. Telemetry is a stream of context-free data from which you need to infer the hidden user feedback. Telemetry data seems to me to be much more prone to finding in it whatever it is that you want to find, or all the other failure modes that happen when people who analyze it have more skills in statistical tools than in doing science.
> Compared to direct user feedback where a user might use some functionality twice a year, but rank it high as something that needs to be improved because it's sort of backwards. Instead of improving the performance and flow of the functionality they use hundreds of times daily, because they're reasonably happy with how it works.
And all I want, all my life when using software, is for companies to fucking listen to that. If I say I'm reasonably happy with things I spend 95% of my time, then I am reasonably happy. I want you to fix the 5%-time case.
There's no direct relationship between how often you use a feature and how critical it is. To give a simplified example, when I'm using 3D Studio Max, 99% of my time is spent modelling, and only 1% (or less) is spent on saving the file. And yet, without that feature, I wouldn't even buy the program. This is of course a silly example, but most software has plenty of very important features executed very rarely (and some that are executed rarely because the experience sucks). Relying only on naive telemetry analysis is going to lead you to misprioritizing work on improving the product.
soo much this!
Sometimes a user might think they need feature A to make task B easier when in reality instead of doing B they actually want to do C but they never thought of it that way.
If you implement A, you take on maintanance burden when C would be way easier to implement and potentially much more useful for the majority of your users.
Which is exactly why I said both matters.
Isn't there a decent amount of psychology research showing this isn't the case. Not with happiness with a service in particular, but that we poorly report on our internal state and often are biased by factors that impact our self reporting but not our choices. What people say and what people do do not always align and thus it is possible for there to be a gap between what people want and what people say they want. If you try to meet the latter you can end up losing out to someone who tries to meet the former.
Now, that is research on average people (and particularly average college students), so when dealing with software developers talking about software issues it may not apply.
A typical story relevant here is that of a news site boasting about a rise in daily reads, where they define a read with being on a page for 3 seconds... that is clearly a meaningless number that maybe just means users are skimming through all your articles in hope that not all you have is terrible (could happen if you had some good content or a loyal audience)
And most importantly, even if my self-reporting isn't accurate, you don't know better, and telemetry won't tell you. If I say that I didn't press this button because it was red, you can doubt the accuracy of my report, but you don't get to conclude that my real reason was that the button was square and not round, or that it was on the left and not on the right. Or that the button is useless. Telemetry will only tell you I don't press it. Or perhaps you can run an A/B test to learn that I press the button when it's blue and round and on the right side (but you may miss the fact that I pressed it out of confusion, and reverted its effects three screens down the line).
Software developers are no different than real people, except that they have much more experience with computers - which means both familiarity with the UI and the ability to instinctively form a mental model of what's happening underneath, which sometimes leads us to intuitively avoid doing things that would break the application :).
--
[0] - https://wiki.lesswrong.com/wiki/Egan%27s_law
[1] - Plenty of motivations could be embarrassing, or weird. E.g. for a long time, I avoided using GNOME desktop and related software, simply because I had a visceral revulsion towards their logo, which featured a footprint. It's a kind of motivation that did affect me, but I wouldn't be too willing to reveal unless asked directly.
[2] - Also people sometimes report on motivations behind what they want to do, but not on the incentive conflict they're facing, and they then proceed to do something you wouldn't expect. This leads to silly arguments like "something is good because of revealed preferences", which latch on the difference between expressed preferences and observed behavior, completely ignornig the fact that observed behavior is heavily incentivized, essentially making people go against their preferences.
yes, but it does let you know where to place the ads and “special offers”
> That is simply not true... but telemetry is something you can trust far more than user feedback
nutin said
We've had a customers insisting that a particular feature was very important for them, however telemetry showed that they used that particular feature last time more than 26 months ago, and they discarded the resulting document anyway. Drilling down revealed that everyone thought that everybody else was using it sometimes, while the one user that had a need for it actually had a different and far more efficient workflow.
My point is that my department have telemetry, the support team and PO have user feedback. If those two versions of the truth does not match up, we discuss it, often involving some users. Neither is perfect, and if you have to choose, obviously listening to the users seems preferable. Just remember that if Henry Ford build what people asked for, he would have made faster horses (quote is probably not even from him, but it gets the point across).
To improve and make innovation you need many things, but especially empirical (telemetry), observational (watch the users), and anecdotal (listen to the users) evidence. Only with that you can make an informed decision.
You can drive far by only using gas pedal and take the foot off it to decelerate. Does it mean that brake pedal is not important, because usage telemetry lists it as "rarely used, user does not know what he wants" ?
This is actually awesome, and a very rare thing as far as I can tell.
https://news.ycombinator.com/item?id=21274511
Ok so GitLab dotcom promises to honor DNT, which is good.
> GitLab Community Edition will continue to be free software with no changes.
So GitLab CE is not "affected" at all, which is better.
I've never used the Enterprise Editions, but what's to stop enterprise ops/sysadmins from just blocking the third-party requests at the DNS level (regardless of the DNT promise)? Another HNer mentioned this re: air-gapped deployments.
So in a purely practical sense, is the only noteworthy takeaway simply an extra production config step involving DNS?
For paying Gitlab customers, this sums up the general opinion well.