<div dir="ltr"><div>I certainly see the value of telemetry in being able to produce a higher quality product through understanding user behavior.  However, I am not sure it is realistic.  My clients are very conscious of intellectual property and data privacy concerns, and for some of them, even discussing the possibility of allowing telemetry in any part of the technology stack would damage their trust in me.  Even if there were an easy opt-out feature, I would be very concerned that I or someone on my team would accidentally build client code without opting out, and I would have to take serious steps to ensure that this could never occur.</div><div><br></div><div><div>I would be thrilled, of course, if such analyses could be easily performed against publicly available code on Hackage, as many tests have done in the past.  This would also provide an additional small incentive for people to open source code that they do not have a strategic need to keep secret.</div><div><br></div><div>MarLinn's idea sounds like a good approach to me, although I agree that it has difficulties.  I think the key would be to make the report produced brief, human-readable, and clear enough that a CTO or other executive could easily sign off on "declassifying" it.  We could then ask that companies voluntarily submit this report if they wish to have an impact on prioritizing the future of the language.  I suppose this is a very strict version of "opt-in", and generally I think that opt-in would be fine, as long as we're very confident that we'll never have a bug that makes it opt-out instead.</div><div><br></div><div><br></div><div>Ryan</div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 9, 2016 at 12:13 PM, MarLinn via ghc-devs <span dir="ltr"><<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Pretty random idea: What if ghc exposed measurement points for performance and telemetry, but a separate tool would handle the read-out, configuration, upload etc. That would keep the telemetry from being built-in, while still being a way to get *some* information.<br>
<br>
Such a support tool might be interesting for other projects, too, or even for slightly different use cases like monitoring servers. The question is if such a tool would bring enough benefit to enough projects for buy-in and to attract contributors. And just separating it doesn't solve the underlying issues of course, so attracting contributors and buy-in might be even harder than it already is for "normal" projects. Close ties to ghc might improve that, but I doubt how big such an effect would be.<br>
<br>
Additionally, this approach would just shift many of the questions over to Haskell-platform and/or Stack instead of addressing them – or even further, on that volatile front-line space where inner-community conflict roared recently. It wouldn't be the worst place to address them, but I would hesitate to throw yet another potential point of contention onto that burned field.<br>
<br>
Basically: I like that idea, but I might just have proven it fruitless anyway.<br>
<br>
<br>
Cheers,<br>
MarLinn<br>
______________________________<wbr>_________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bi<wbr>n/mailman/listinfo/ghc-devs</a><br>
</blockquote></div><br></div>