Imported from previous forum
It seems to be that the vast majority of members in the list are only shown with their name. For example the Global Exchanges and Markets Committee has 168 members. Only Scott, Jim Northey and I are shown with the company name. Jim Shapiro is shown with his connection to BSE on the main tab where he is co-chair. The reference to BSE (and his phone number and email) is missing in the member list and on the detail if you click on Jim Shapiro. "Deutsche Boerse Group" is shown underneath my entry in the member list and as "Employer" attribute on my detail page.
The old website had name, location and often also a phone number. It also implictly had the email as you could hover over the name and see the email address (clicking it created and empty email with your email program). I believe this is a general problem with the transfer of master data for members of committees and working groups. Please investigate whether this data has not been transferred to the new website or if it is simply not visible. It should be visible to all members of the committee or working group.
The Employer Name is shown if populated within the profile using the narrative populated by the user, and the values from the old site were carried over. BUT their display respects the individual visibility permissions set by the user.
Seperately, the name of the member firm with which the user is formally affiliated will shortly be displayed in the listing element (and subject to FPL's configuration) within the user profile. This improvement is expected within the next couple of weeks, and has alreday beed discussed with the Programme Office. This is derived programmatically from the Employee Group with which that user is affiliated, and will respect the formal taxonomy of the member names (including picking up any subsequent changes to the company name made by the company or its administrator, or changes in member affiliation, without requiring the user to amend the profile data), rather than the "free-form" format populated by the user on their profile, where we cannot impose a strict taxonomy, as the actual employer names may not be reflected in the sites entity data. The "Employer" field can also contain values that are not members or otherwise formally reflected within the site's data, so does not represent a proper managed taxonomy, just a narrative field. The narrative field will be linked to a "search" function, to return any correlated names, whereas the Employer affiliation will link directly to the Entity Profile as a formalised link between the user and the associated member company.
This approach also accommodates the scenario where someone is employed by one firm, but their membership status is by virtue of affiliation with a different member. An example would be where the individual is actually employed by a subsidiary or affiliate, but membership status and associated site privileges are derived from the parent company's FPL membership status. This is a common scenario. There are also circumstances where somone is a consultant, or a Non-Executive Director, for example, and the employer name and membership affiliation differ as a result.
Phone Number, E-mail address, and address/location data are displayed on the user profile where populated, but respect the access permissions set by the user, so will not be visible within the group to "non-admin" users unless they have set it accordingly.
This information falls within the formal Definition of "personal data" within UK and EU data protection regulations (and similar rules elsewhere to which the site is potentially subject, since it targets a global audience), and it is illegal for FPL to display it to any third party without the express "opt-in" consent of the individual, and the ongoing ability to autonomously manage its visibility thereafter- all data elements definitely or potentially falling within he scope of such legislation are therefore defaulted to "Private" where provided, but the user can change this at the individual field level within their profile. Beyond the formal legal requirements, many users are sensitive to the disclosure of such information from a privacy perspective, so it was decided to put control of the visibility of such data in the hands of the individual. This consent was not explicit in the previous site's terms and conditions, and in any case recent court cases have rejected attempts to claim that inclusion within generic "click to accept" Ts&Cs constitutes proper process for the procurement of such consents in respect of personal data.
To secure improved access to such data, FPL would need to solicit consent by suitable communication with the user base, which might include a campaign, or provision of a "nagger" within the site to encourage people to amend their settings themselves (as per sites such as LinkedIn).
All the data from the previous site was migrated, except for a small number of users (which actually includes yourself and many of the Committee leadership, where this information was populated manually by the Programme Office in advance of the migration in order to highlight them as Committee/Working Group leaders etc., and therefore not subsequently migrated so as to avoid over-writing the manually populated data). An unfortunate consequence of this is that any errors and discrepancies arising from that manual process are somewhat concentrated amongst some of the more active and engaged users, so the best resolution is a thorough review of the manually populated data by the Programme Office and by the users themselves. Both admins and users themselves have the capacity to edit it.
You can edit this data yourself by editing your profile, and set the Access Controls as you wish from the drop down selections at an individual field level, depending on your personal view on the sensitivity of the data. The current settings and defaults for these were thoroughly reviewed, agreed and formally signed-off by the Programm Office early in the process, but they are easily changed, albeit somewhat fiddly to execute and reconciled. This means any feedback on settings can be collected and incorporated, subject to it being legally compliant.
Since public disclosure of e-mail details is in contravention of UK/EU law, except by consent (and is also an invitation to spammers by potentially including it in search results), the site provides a mechanism by which "Site messages" can be sent to the user from the profile, even if you cannot see their e-mail details. By default, these result in a proxied e-mail notification to the user that does not require the disclosure of the user's e-mail address, but the user may also elect how they wish to receive these notifications by amending their notification settings.
Thanks, Ken. I agree that more formal rules to govern privacy are an improvement compared to the old site. I think the Program Office needs to make users aware of the change once the formal member affiliations are displayed in the member lists and ask them to change their privacy settings of email, phone etc. if they wish to continue to display this information like they did on the old site. The feature to send a message to somebody else without having their email is an added value and should also be pointed out in such a communication. Please pass my suggestion on to the PO.
Thanks Hanno. As usage patterns emerge and we collect feedback, I think there are a few things we can do to enhance ergonomics for users, "power-users" and admins. The user affiliation display is expected to be relatively soon as its an obvious priority, and we also have some ideas to make it much easier to see the role of the respective individuals with the group.
I think the PO wants to polish off a few of the outstanding issues before communicating more widely, so that the relevant features are all working flawlessly and incorporate the feebcak received to date, but I have no doubts we can address this. I have added you comments to the relevant item within our JIRA issue-tracking platform, and will bring it with PO in todays call.