4 ms·
< "We do require a GitHub login because that is where we keep our issue tracker" The problem with this is that you are de-anonymizing the user when you ask for
by davidhyde 3y ago
< "We do require a GitHub login because that is where we keep our issue tracker"
The problem with this is that you are de-anonymizing the user when you ask for this and the user may decide that proceeding is not worth it. Also, they may find that logging in is a pain. Think of those companies who ask you to login before you can unsubscribe from their news letter. It is unpleasant for the user who is already upset.
I think that the GP made some really good points and may well have adequately explained the following point you made.
Re-quoting:
< "Whatever the reason, nightly and beta failed to be an effective canary."
I think its worth the effort to figure out the reason why nightly is not an effective canary and if it's as simple as the user requiring a github login and not wanting to go that far then that should be fairly simple to solve.
I have a suggestion that may or may not be feasible. Logins are one way to cut down on spam but not the only way. You don't have to have users directly posting to your issue tracker, you could use a website. The concerns you have about telemetry are absolutely on point so this service could simply be an anonymous dumping ground for copy-paste ICE compiler output that anyone, including bots could use. No automation from the user's machine, no telemetry, no metrics. The service would be responsible for despamming / deduplicating the submissions and posting to the github issue tracker using an account not associated with the original poster.
Anyway, you guys do superb work and really think that articles like this are important. Thanks for posting it.
- LightFog 3y ago‘Whatever the reason, nightly and beta failed to be an effective canary’ - Im also curious about this? It is typical to try to move quality ‘left’ - which would imply understanding this issue and fixing it. But the focus seems to be on adding more logging - which will by definition have less impact on the quality of public releases than improving the quality of beta/canary releases will.