No, it is not. It means effort on our side to triage the data. It means we are possibly collecting personal data from users so we need to be careful about what we do with it. It means people will think “it’s fine, I clicked the button in the crash report dialog, I don’t need to do anything else” instead of creating an issue and giving actually useful details on how to reproduce the problem and being available to answer our questions about it.
We will just be collecting gigabytes of data that no one can make sense of.
If we are to do something like this, we need to think about it the other way instead: why do we want to collect the information? How do we process it? How can it improve the workflow for both users and developers? And then design the appropriate tools to do it. But “let’s put a huge pile of bugreports with no or limited context on an FTP server” is not fixing anything or help anyone.
Building the tool that makes sense of all the bugreports, groups them together, and possibly even suggest exisitng bugreports to look at for users hitting a particular crash is possibly not that “mundane”. And that is the part that would turn mostly-useless data collection into something that can possibly help us.
Personally, I’m trying to do my share of mundane tasks, currently that is reviewing, cleaning up and merging the hundred of patches we have on Gerrit, as well as triaging existing bug reports and trying to sort out what goes in R1 and what can be done later. What’s the point of fixing bugs if there are so much pending changes that we don’t even take the time to review and merge them?