[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cross-project-issues-dev] RE: [eclipse.org-planning-council] UDC concerns
|
Mik,
Mik,
I appreciate your concerns and I think the experiences you have had with
Mylyn are making the UDC better. We will need to increase the level of
communication on the UDC and will hopefully do this over the next couple of
weeks.
A couple of things regarding your concerns:
1) I hope you understand that it would be very difficult for us to aggregate
the data from just one company. For instance, if Company XYZ has 100
developers using UDC and sending in data, we do not collect information that
ties all of those developers together. It just looks like 100 different
developers to us. Therefore for scenario #2 to occur we would have to do a
lot of data mining to even 'guess' at a pattern. It might be possible but
we would have to do a lot of guessing and digging to uncover it.
2) Scenario #2 is certainly a possibility. UDC does provide the ability to
filter out the confidential bundles or only send 'org.eclipse' bundles. So
assuming the user opts-in, they could use this mechanism to keep their
bundle names confidential. As I have mentioned we also plan to only publish
reports of the data and not provide access to the raw data. The first set
of reports will be only 'org.eclipse' bundles. We may publish reports with
third party bundles but given the vast number of bundles we will collect we
can only report on those that are statistically significant. In your
scenario I can only imagine a small number of participates would report and
so they would not show up as being statistically significant.
To your recommendations:
1) We already have an FAQ located at
http://www.eclipse.org/epp/usagedata/index.php. We will attempt to link to
it directly from the UDC dialog. It is late in the development cycle so I
know Wayne is anxious about changing the code.
2) We already have a check box to filter non org.eclipse bundles. This is
on the preview pane. When we designed the dialog it was felt if someone was
worried about the sensitivity of what they are sending, the preview pane
would be the place for filters. This sounds like it is not as prominent as
you would like but again it is late in the development cycle and since we
have the functionality, I don't think it is worth the risk of making the UI
change.
Ian
-----Original Message-----
From: eclipse.org-planning-council-bounces@xxxxxxxxxxx
[mailto:eclipse.org-planning-council-bounces@xxxxxxxxxxx] On Behalf Of Mik
Kersten
Sent: Wednesday, June 04, 2008 12:59 PM
To: 'eclipse.org-planning-council'; 'Cross project issues'
Subject: [eclipse.org-planning-council] UDC concerns
This is a follow up to the UDC discussion on the Ganymede call. I'm
positive overall about the benefits of data collection of this sort and have
lead a related effort, which was very beneficial to the Mylyn project [1].
But due to the sensitivity of privacy and different conventions in countries
like Germany, it's tricky to do right. In addition, what today's call also
demonstrated is the importance of getting the communication of what's going
on right. I've expressed similar concerns in prior correspondence with UDC
folks and I want to point out that they have addressed many of them already
[2].
The key concern I have left is the repercussions of developers in large
organizations agreeing to the UDC collection, then down the road having
management notice that transmission of the data was not desirable. Here are
two concrete scenarios, both having to do with the fact that bundle IDs and
other IDs are uploaded:
1) An ISV is working on an Eclipse-based tool that's confidential and won't
be announced for some time. With the current collection policy, naming and
details about the functionality of the UI are present in the IDs collected
and uploaded.
2) A large company has provides a closed source tool suite. Internally it
turns out that a significant number of developers are using a competitor's
tool suite instead, as evidenced by the competitor's IDs and other patterns
in the IDs and logs identifying the large company.
If I was a manager in either of those companies, I would not want that data
leaving my company firewall. So I would put in a policy that we revert to
exclusively using Eclipse Classic, or have an internal distro that removes
UDC from EPP. If I found out six months down the road that most of my
developers were uploading this data to Eclipse.org, I would not be happy.
Then I would probably be asking my lawyers to read over the Terms of Use and
considering whether I should request the Eclipse Foundation to remove my
data in case the Terms of Use are not set in stone.
Both of the above have implications to PR and the perceptions of the Eclipse
downloads, which are largely defined by what's in EPP. Here are some ideas
for addressing these concerns:
* Make a very clear FAQ entry so that developers can make an informed
decision about which UDC configuration to use. I'm guessing that most
companies won't have a policy about UDC like things in the IDE, so the
developer will need enough information to make a decision that's in the best
interest of their company. Link that FAQ entry from the initial dialog,
just as the "Terms of Use" is linked.
* Consider making a check box along the lines of "Filter non org.eclipse.*
bundles. Use this option if using confidential tools". I think that it
would be lower risk to make the user have to opt-in to collect info from all
bundles, but perhaps if worded clearly enough it could work as opt-out.
Mik
[1] http://kerstens.org/mik/publications/mylar-ieee2006.pdf
[2] http://www.eclipse.org/epp/usagedata/index.php see "How does it work?"
--
Mik Kersten
President & CTO, http://tasktop.com
Project Lead, http://eclipse.org/mylyn
_______________________________________________
eclipse.org-planning-council mailing list
eclipse.org-planning-council@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipse.org-planning-council
IMPORTANT: Membership in this list is generated by processes internal to the
Eclipse Foundation. To be permanently removed from this list, you must
contact emo@xxxxxxxxxxx to request removal.
