This seems to be very useful information. I am very much in favor of including this as and opt-in option during the installer.
I disagree with Chris – one should be able to opt-out of this later on in the options page. The polling frequency should be relatively infrequent (once a month?). On Sep 4, 2008, at 10:18 AM, Chris J. Davis wrote: > I am very much in favor of this being an opt-in option at the end of > the installer. I don't think we need to have this be more than a one > time occurrence. > > Chris > > On Sep 4, 2008, at 8:29 AM, Chris Meller wrote: > >> I was playing around with USVN (a web-based Subversion management >> GUI), and one of the installer steps [1] was whether or not to >> check for updates and submit server stats. >> >> I know we've talked previously about asking during install whether >> or not we should check for updates (for paranoia reasons), but I'd >> like to bring up discussion about adding a second option for >> submitting stats. Often there are many things that projects have >> trouble judging the availability of on the average host (versions, >> extensions, etc.), and having some centralized collection mechanism >> would greatly improve our ability to judge the extent we could >> reliably anticipate such things. Ideally, I would also love to see >> us publish these statistics in some manner so that the larger >> community could benefit from our efforts. >> >> A few examples of things this could help with: >> >> - Our mbstring vs. iconv discussion largely centered around which >> extension was more widely available >> - A question came up just the other day on IRC involving a problem >> with the value of $_SERVER['SCRIPT_NAME']. No one really knew if >> that was valid or not - it was set, but not to a value we'd have >> predicted. The reliability of other _SERVER variables is also >> suspect at times. >> - Knowing which PHP versions are in use has a wealth of advantages >> (duh) >> - Database driver and translation usage could help us target >> resources more accurately >> >> Some basic information about your environment could be bottled up >> locally and submitted at the same time as update checks are >> performed (or at any other interval, via cron - it really wouldn't >> matter) and it could always be turned off in the options at any >> time if you'd opted-in during install. For bonus points, I suppose >> we could add the ability to turn on and off the individual data >> points we were collecting if, for example, the admin didn't want us >> collecting $_SERVER['REQUEST_URI'] from its users. >> >> We would need a clear and firm privacy policy, but we were going to >> do that for updates anyway. Most of the data would be pretty >> harmless, certainly nothing I would worry about, and could >> potentially also be scrubbed before being sent (knowing simply that >> SCRIPT_NAME is set but not what it contains is somewhat less >> useful, but still helpful, for example). >> >> This is one of those things that could really turn out to be as >> simple or as complex as we care to make it, I simply wanted to >> throw out an idea and get some basic feedback on it. Opinions? >> >> [1] http://chrismeller.com/dump/1a0b5268efd464c19258455b2bea3cb8.png >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/habari-dev -~----------~----~----~----~------~----~------~--~---
