Collect usage metrics

[Nevon]

#279 has highlighted the fact that there's currently no way to know how many users Sagui actually has. Without that information, it's hard to take decisions regarding the direction to move in.

I would suggest adding usage metrics collection (opt-in, with the question being asked on first run) so you can see how many unique users you have, which commands they end up running, what platform they are on and whatever else might be interesting.

You could probably rig up GA for this. I've used Mixpanel for similar things before, and it was quite nice as well.

[xaviervia]

Have my upvote

[pirelenito]

Wow! We should definitely do this! Do you want to dig in the implementation details @Nevon ? 😍

[D34THWINGS]

Could be really helpful !

[xaviervia]

Some ideas:

• Add a .saguirc file on the user home to store the information about whether or not the user wants to send usage statistics.
• Prompt the user for whether or not they want to spend usage statistics when installing
• Default to "no" in 10 seconds or so if there is no answer. Going for a cup of coffee and coming back to find the installation blocked is not a great experience.
• Do it as the last step, do if the user closes the process, sagui works
• Never prompt if the shell is not interactive!
• Make the service where the statistics are collected transparent. Maybe there is a service like this for open source.
• Put the statistics on the Sagui homepage if they are interesting
• Data to collect:
  • Usage of a command
  • Installation of a new project
  • Sagui version

I think that information should be more than enough: it tells what versions of Sagui are in use and what features of it are being used, so we know both when we can deprecate something safely and in what features to invest in.

[xaviervia]

(sorry for the typos, typing from the phone)

[Nevon]

My biggest concern at this point is how to handle CI runs.

First of all, is it valuable to collect data from CI? On the one hand, someone running sagui test from CI is just as much of "a run" as running it manually is, but on the other hand, when you run in CI it's hopefully going to be on a clean host, but we can't ask for permission to collect metrics there, so it would feel shady to collect metrics by default in that kind of environment.

Secondly, regardless of how we want to handle CI, we also need to know if we're running in CI. There are projects that aim to identify when you are running in CI by looking for known environment variables, but that feels a bit hacky. On the other hand, I wouldn't want to require the user to specify some special flag when running in CI. The default experience should just work.

As for services where we can put this data. There is piwiki, which is open source, but it has to be self-hosted and it's not the absolute simplest thing to maintain. I would just throw it into GA or something like that, and then export dumps every now and then if there is a demand to make it public.

[xaviervia]

• CI: to me, opt-in + disabled prompt on non-interactive meant that we would not track CI. I'm actually OK with that. Manual usage statistics are to me more interesting because they are more specific. A single CI in an active project with a peculiar setup could easily skew the whole data set.
• I would love a hosted, free service that is open. I'm not a fan of GA. Won't oppose to GA if we can't find something better though.

[jonotrujillo]

Can you take a look at bower/bower#1102, and think if you still want this? 😬

[xaviervia]

@jonotrujillo great point.

Also one of the core reasons why we wanted this got obsolete once we realized that we can just search for https://github.com/search?q=sagui.config.js&type=Code&utf8=%E2%9C%93

So I guess we can reject this. I vote for that.