Opt-in feedback reports

[kevinmartin]

I think a great idea is an opt-in feedback report to improve the platform. This is usually found in higher-level apps like your browser, but I think it could help us out, as well.

These reports can, if implemented correctly, help find memory leaks or bugs in the codebase.

Upon installation, ask the user to send these feedback reports. They would be sent whenever there is a slow period on the system and never in high load.

[rmg]

This strikes me as the kind of thing that would only ever be enabled in development environments, which is going to strongly influence the type of information that can be gleaned.

@KevinMartin can you give any concrete examples of things that can be recorded/reported that would be useful? I can think of a few "fun facts" type stats (number of require()s per execution, functions/file, exit codes, execution time, OS version, node version, compiler version), but nothing that would be useful given the likely small and self-selecting sample size.

[rmg]

Actually, a one-off post install report for runtime details like OS and toolchain versions might be handy for the installer based distributions.

[kevinmartin]

@rmg, I agree with post-install metrics, definitely. I'm not so sure about number of require()s per execution, functions, files, or other "fun facts".

I do believe that at a bare minimum, we should include OS name/version, node version, npm version, compiler version, any warnings given and errors ignored, as well as any failed platform tests run by the installer (ie. make test).

I do agree that the majority of environments will be development, but when asking for the feedback/usage/crash/diagnostic reports, we can ask the user if this is a production or non-production (ie. testing, staging, development) box.

I believe whatever statistic we send back to iojs, that it should be minimal and only important information to help us find insight into lower-level errors.

[jbergstroem]

I like the idea. Make it an optional (open sourced) npm module that people can install; suggest it only being run in production (with examples to avoid dev mode such as env vars) and elaborate on how it works, how it contributes to the iojs and how it as a result benefits that specific user.

I think the most interesting statistics would come from "hot paths"; most common requires, gc, memory allocation and similar. Find usage patterns and make them faster. As long as its always developed and distributed as open source I think experienced developers understand the benefits for sharing their information to this module.

[jbergstroem]

Being part of the build-wc, just getting basic info such as os, iojs version and its built state (read: how did it get installed) would be very valuable information (which @rmg already pointed out) since it'd direct our efforts.

[Trott]

Closing all issues in this archived repository.