Answering a personal request on general@ usage: 1) we discovered from our internal discussions that the topic is sensitive and want to be transparent with our intentions to collect user data; 2) we want to know more about Apache ways of addressing the problem; 3) we have not got any answer from legal@ and infra@ in this thread, thus I believe this may be more a cultural issue than a legal or technical issue; the incubator is a culture-spreading entity; 4) finally addressing general@ may be my mistake.
I still will be grateful if anyone shares their experience on best practices on how to collect user errors to improve product quality. 10.06.2013 12:05 пользователь "Alexei Fedotov" <alexei.fedo...@gmail.com> написал: > [added general@ for vivid discussion] > > Hello Sebastian, > > I'm glad that the statement that this infrastructure is needed is not > questioned. > > We technically can use either CGI script, or existing Confluence API. > The intention for using Google Analytics is minimum effort. AFAIK, > many Apache projects do use Google Analytics already. > > The goal for the request is to avoid inventing a project-wide policy > where foundation-wide policy is needed. > > With best regards, Alexei > > -- > With best regards / с наилучшими пожеланиями, > Alexei Fedotov / Алексей Федотов, > http://dataved.ru/ > +7 916 562 8095 > > > On Mon, Jun 10, 2013 at 7:03 AM, seba.wag...@gmail.com > <seba.wag...@gmail.com> wrote: > > Hi Alexei, > > > > what about a simple CGI script that takes the input and send an email to > the > > mailing list? > > I think some more simple approach would do the same and does not have > such a > > deep impact on the whole infrastructure. Some legal and privacy aspects > are > > still tbc. > > > > However no matter what we do it is unlikely that including the actual UA > > code or any kind of real pwd / hash in a release is a good idea. It is > quite > > easy to manipulate that. > > > > Also the question rises if the OpenMeetings server is in a public > network at > > all. Just sending request blindly without knowing if they ever reach > their > > destination is kind of odd. > > > > It should be some subscribe mechanism where an OpenMeetings admin can > > activate the error collecting. The activation could then subscribe and > load > > a hash that will auth that server for error collecting. > > > > If you put that activation in the installer with appropriate > explenations I > > think it has better chances to find a wider positive reaction in devs and > > users. > > > > Maybe it would be enough to give some kind of more general feedback from > > @legal and @infra and we can then in the OpenMeetings PMC create a more > > detailed spec of that component. > > > > @legal: Do you have general constraints regarding error collecting ? > > > > @infra: What kind of advices can you give us? I guess some CGI scripts > are > > not that big deal. Is there any process who would review and activate / > make > > them executable? > > > > Thanks, > > Sebastian > > > > Am 06.06.2013 19:38 schrieb "Alexei Fedotov" <alexei.fedo...@gmail.com>: > > > >> [added Shane for reputation issues] > >> > >> Hello, Infra and Legal folks, > >> > >> We ask you for advice on the automated error collection > >> infrastructure. Any helpful ideas are appreciated. > >> > >> 1. Our users are tainted with iphones and other reliable and fancy > >> staff. They start wanting openmeetings to work reliably. This makes us > >> think of a global error collecting infrastructure to plan important > >> bug fixes. Here is an example by Firefox [1]. > >> > >> We believe collecting user errors is generally ok if proper > >> preparations are made. Is it generally possible to implement error > >> collecting infrastructure as a part of Apache project? If not, we can > >> try to do it as a commercial company, yet Firefox example shows a > >> non-commercial org can be behind that error collection. > >> > >> 2. Could we use Google Analytics to store collected errors? The > >> general Apache practice is to use Apache infrastructure. Google > >> Analytics allows us storing 50 mln. events for free. The comparable > >> thing won't be free for Apache for sure. > >> > >> Once can use JIRA, or Confluence via API, this will be a heavy load. > >> Are you ok with using third party for storing error & environment > >> messages and associated risks? > >> > >> The code we are talking about is below: > >> try { > >> _gaq = _gaq || []; > >> _gaq.push(['_setAccount', 'UA-13024987-1']); // PMC id > >> _gaq.push(['_trackPageview']); > >> _gaq.push(['_trackEvent', 'Openmeetings client error', > >> message, '', 0, true]); > >> } catch (exception) { > >> alert(exception); > >> } > >> > >> 3. Is it ok for PMC to share Google Analytics id? Should we use some > >> Apache Id instead? > >> > >> 4. Which preparations should be done to start this error collection > >> service in the next release? > >> > >> 4.1. Is it ok just to semi-silently mention in release notes, that > >> errors are automatically sent to the (Google) server right now? > >> 4.2. Or should we explicitly notify each new user that the errors are > >> now to be collected? > >> 4.3. If 4.2. holds, can we ask once per user at the beginning of his > >> session and remember if he agreed sharing error reports? Or should we > >> allow a user to review each error report each time the error is sent > >> (I expect 5-10 errors per standard openmeetings session)? Can we have > >> a checkbox "Remember my choice" or a button "Send error reports > >> always" for those, who are tied of error messages? > >> > >> [1] > >> > https://crash-stats.mozilla.com/report/index/050f1aab-1507-4c8f-a166-9b3322130422 > >> > >> -- > >> With best regards / с наилучшими пожеланиями, > >> Alexei Fedotov / Алексей Федотов, > >> http://dataved.ru/ > >> +7 916 562 8095 >
