In order to form a more perfect UI...

Empirical data

We don't actually know very much about how people use monotone in the wild! How silly is that?

Plan: keep a log in ~/.monotone/ of every command run. We should be very careful here to only log information that is not confidential. (E.g., need to check with community whether they consider branch names confidential. If very useful information is considered by some people to be confidentical, then fail safe -- default to not logging it, and provide a way for users who want to help, to enable more detailed logging. Alternatively, only enable the system at all if requested by a hook.)

Log in particular start time of each run, the command run, plus provide a way for code to add arbitrary other things to the log. (Example: it would be useful to log, for each merge, information on whether conflicts were found, and what they are.)

Provide a command to format this as an email message, for the user to look over and then send to some address. Make it clear what will happen to it (e.g., who will be able to see it).

Another thing to log: whether we are running on a tty!

Perhaps have monotone check the size of this file on startup, and if it is growing large, suggest the user send it in? Or possibly simply rotate it every once in a while, throwing out old stuff, so even if the user doesn't send it in, the space use is bounded?

Involve the user

Once we have the above, add several commands:

a way to express displeasure. monotone punish, monotone stab, monotone die, ...?
a way to express pleasure. monotone reward, monotone cookie, monotone kiss, ...?

These commands react appropriately on stdout (whimpering, begging for forgiveness, pleasant surprise, ...?), and record (like any other command) to the log above. Actually, these should take comments on the command line -- part of the inspiration is the social practices around common IRC bots with their "~lart", "~stab", etc. commands, which are used to relieve frustration -- it is very common to see usages like "~lart paypal for sucking and not supporting Poland", "~lart X11 for two clipboards", etc. Take advantage of this and get a few more clues as to what the problem might be :-).

a way to make comments, that's a little less intrusive and ritual-laden as filing a bug report or sending an email to the list. monotone whine, monotone complain, monotone say, monotone suggest? monotone oops, tell people to make a note whenever they make a mistake, even if they think it's their fault? (give your comment on the command line, or else have it pop up an editor a la commit)

Enabling

Perhaps the way to do this is to have the logging disabled by default, but have

the --help for the above commands describe how to turn it on
if any of the reward or punishment commands are run with it turned off, then work as normal, but also print a note saying that we won't know about their issues, and giving a reference for turning on the feedback functionality
if any of the "purer" feedback commands are run with it turned off, then give an error message, and describe how to turn on the feedback functionality

The goal being to have it be as discoverable and require as little thought as possible -- and perhaps catch people right when they are frustrated or happy, and perhaps will be most receptive to anything that suggests how they can help us help them.

Getting the feedback

It is most convenient if the user does not have to do anything tricky to send feedback. Sending email is kind of hard. Perhaps we could use a HTTP(S) POST? (The CBI folks get away with doing this after every program run. There are some sneaky bits too, like the response to the POST can tell the program to switch to a different URL, or shut down posting altogether -- useful if you want to stop receiving information, ever!) Probably we shouldn't do it every program run. Possibly we should do it after any of the direct feedback commands, and have a command that just sends feedback without prompting for a complaint. It might make sense, if the user has enabled this, to just automatically do the POST whenever our local buffer gets large enough... but if the network is down, this could cause monotone itself to misbehave in a user-visible way, which is bad for a pure feedback mechanism.

Testing

What are the implications for testing?

We need some way to unconditionally disable this collection throughout the test suite
We need to be able to re-enable it and force the output into a particular place, in order to test the collection
We need some way to test the feedback mechanism -- how do we test POSTing to a URL? (I guess there are various ways to run a tiny HTTP server, e.g. in a few lines of python, or even something crazy involving bash and netcat...)

Privacy

How much information do we record? Not file contents, obviously. Are file/directory names sensitive? Are branch and key names sensitive? Server names? changelog messages (which may occur on the command line, too)?

Who has access to the recorded data? The two options I see are "everybody in the world" and "everybody who has convinced us that they have some minimal trustworthiness (slightly higher threshold than commit access)". Fancier things seem unworkable...