On 2013-09-05 11:42 AM, Wayne Beaton wrote:
If the user initiates an install operation with full understanding that
they are contacting an Eclipse Foundation server to download some
artefact, then it is perfectly reasonable (in my opinion) for them to
expect that we're keeping track of the fact that that thing has been
downloaded.
Doesn't the p2 mechanism do this?
p2 will upload stats even during local-only installation. When I install
a feature from my local disk (or from my company mirror), no
download from Eclipse Foundation servers takes place, so it is not
reasonable to assume implicit consent to provide Eclipse Foundation with
download stats.
Or are you looking for more than that? It's one thing to download an
artefact, but quite a different thing to be notified that it's actually
being used. Is this what you're looking for? Are we talking about a
per-use notification, or periodic heartbeat? In my mind, any ongoing
"I'm using this feature now" sort of thing is very different from a
user-initiated installation/update process.
I am looking for periodic (weekly) heartbeat. I am not sure I agree
there is significant difference between one-time and ongoing reporting,
both cases should be handled consistently and provide a way to opt-in
before any reporting takes place or opt-out, if we decide this is
acceptable.
I understand the desire to make it opt-out. Using an opt-in strategy
severely diminishes the value of the gathered information.
Creation of a "call home" policy is being discussed in Bug 413169 [1].
Based on your direct email earlier this week, I got the impression that
the current policy allows this kind of reporting as long as the user can
explicitly opt-in. If this is not the case, when to you expect
conclusive decision on 413169? Also, can you provide a link to the
policy?
--
Regards,
Igor
Wayne
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=413169
On 09/05/2013 07:44 AM, Igor Fedorenko wrote:
On 2013-09-05 4:00 AM, Markus Alexander Kuppe wrote:
On 09/05/2013 02:14 AM, Igor Fedorenko wrote:
* There will be workspace preference to enable the counting, it
will be
on by default.
Does this mean that the plug-in collects statistics even if the user
does not opt-in to send stats?
No, I think nothing should recoded locally if the user decides to
opt-out.
* When the plugin first starts, it will inform the user about the
counting via a popup dialog or some other UI means and the user will
have a choice to either acknowledge the counting or navigate to
corresponding preferences page and disable counting there.
From what you describe it appears as if "no - do not opt-in" requires
more clicks than "yes - opt-in". If this assumption is correct, then
why?
Quite honestly, I want installation count report to be allowed if the
user chooses not to think. I am open for discussion here and if the
consensus is to make this single-click to both opt-in and opt-out, I am
fine with it too.
Personally, though, I think Eclipse Foundation should allow
installation
report without explicit opt-in but still require a way to allow
opt-out.
This is what p2 is doing since 2010, so ability to opt-out will be an
improvement compared to what we have now.
--
Regards,
Igor
M.
[1] http://bugs.eclipse.org/413169
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
--
Wayne Beaton
Director of Open Source Projects, The Eclipse Foundation
<http://www.eclipse.org>
Learn about Eclipse Projects <http://www.eclipse.org/projects>
EclipseCon Europe 2013 <http://www.eclipsecon.org/europe2013>
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
_______________________________________________
cross-project-issues-dev mailing list
cross-project-issues-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cross-project-issues-dev
