One of the things we decided would be useful to collect is a list of file extensions in the source directory that were changed since the previous build. The telemetry key I used for this is `file_types_changed`: it's a list of `{ext, count}` like `[{"ext": "cpp", "count": 1}, {"ext": "js", "count": 1}]`. To collect this data effectively we'll probably need to use watchman and have it running in the background.

(In reply to Ted Mielczarek [:ted] [:ted.mielczarek] from comment #0) > One of the things we decided would be useful to collect is a list of file > extensions in the source directory that were changed since the previous > build. The telemetry key I used for this is `file_types_changed`: it's a > list of `{ext, count}` like `[{"ext": "cpp", "count": 1}, {"ext": "js", > "count": 1}]`. > > To collect this data effectively we'll probably need to use watchman and > have it running in the background. Is there a reason not to keep more information, say... the whole set of modified files? Are we concerned about people working on files in security-sensitive tickets, or naming files in a way that might leak features?

It felt a little too invasive, honestly. Plus it makes it much more likely that someone could de-anonymize the data by cross-referencing against lists of files from hg. Our biggest use for this data is to answer questions like "are there people doing non-artifact builds that are only touching content files?".