MDG plan for a tracking package

community
3

I suggest making it a (y/n) opt-in when using the CLI generator.

It’s how desktop apps handle anon reporting. I almost always gladly say, “YES. Make this better.” I’m sure most of use would do the same. But others don’t want to, and that ought to be respected. Also, MDG should strive for transparency; I think it would only be fair to explicitly disclose what information would be reported. Google Play’s app permission center is a perfect example, everything is very open; no surprises.

@mquandalle

First, unless I’m wrong reading the code, I wouldn’t qualify an IP address nor the application URL as some “anonymous info”.

Yeah, I wouldn’t call that anonymous reporting. Reporting my server’s ip & url would be roughly equivalent to having Webstorm send JetBrains my name and street address. Personally, I would not mind reporting the url/ip, I’m not working on anything which I want to keep secret. Yet, I do have some things private, but I could care less if MDG sees the domain its under next to the thousands of others in some database. If you’re concerned about secrecy, you should have access locked down with a whitelist anyway :closed_lock_with_key: but I digress.

Another suggestion:

That data is pretty basic, you can learn quite a lot from version number and IPs, but that’s nothing compared to what’s possible with just a few more metrics. If you’re collecting data, wouldn’t it be a good idea to collect information about their app? For example, it could report that in the last week my Instance crashed 23 times because of Exception X. That can actually help you find out what’s not working. (sending every stack trace would be way overkill, but keeping some sort of talley of crashes, then reporting ones with high severity and/or recurrence makes perfect sense. There’s so much good that could be done by this.

Imagine these made up scenarios:

  • 65% apps running on windows are getting Exception X, but only 0.03% of linux apps have run into this

    • obviously theres an issue here. Whats going on?

  • 82% of reports of E_NOMEM on boxes with less than 1GB of ram fail somewhere within the mongo adapter.

    • is there an issue with a npm pkg version?
    • Should we make it known that stable instances should have X and Y resources available as a requirement?
    • Is it possible to create a lite-er version of the adapter or have some way to turn on debounce for at-risk systems?

  • Wow there’s 10,000 locally hosted apps from Uzbekistan

    • can we get translations of documentation?
    • can MDG process payments for Galaxy from Uzbekistan?
    • how can that community be supported?

  • 12% of 1.3 users still have iron router installed

    • Should we revitalize IronRouter? (the answer to that question is a resounding no btw)
    • Why the hell are 7% of newly creating apps installing it? Are FlowRouter or ReactRouter missing some functionality, not meeting some use case? Is there a lack of communication of best practices?
    • How many existing projects depend on it? how can we ease the transition?

I can go on and on and on…

Perhaps even make it configurable? I’ve seen OAuth apps where on the “Authorize App Y to use your Account Page” they allow you to optionally limit the scope of what they can access. MDG can potentially use their data mining to huge (financial) potential. If I opt to make the reports very permissive, MDG stands to benefit. Might it be possible to give developers who opt into detailed telemetry a free month of Galaxy, offer a special discounted rate, etc etc? That could be an easy way to get developers to try Galaxy. Getting them signed up like 90% of the battle I would imagine. It’s a Win/Win as I see it.

11 Likes