Category: News

A note of explanation. I first published on this update on Thursday, June 4th, PDT. However, that post was withdrawn out of respect of a request from Linden Lab that I not blog on the change at that time. Subsequent discussions with the Lab led to an agreement that I could blog in full on the matter once the change had been deployed across the grid. Hence this post.

Until now, it has been possible to open the details for any Second Life group you have joined and display all the information relating to that group, including the list of members.

However, with the new update, groups with 5,000 or more members will no longer display the list of members unless:

• You are assigned the Owner or Officer role within the group
• You are assigned an ability within the group which requires the members list to be displayed (e.g. you are able to assign members to assigners roles, or are able to eject / ban people from the group, etc.).

Instead, and until corresponding changes are made to the viewer, all you will see on opening the members list as a message stating “Retrieving member list (0 / XXXXX)” – where XXXXX is the total number of members in a the group, as shown in the images below.

This update has been made for a number of reasons, including:

• Where very large groups are concerned, the full list of members has rarely completely loaded into the viewer – it has only seemed that the list has loaded
• Tests have shown that in order for very large groups (e.g. tens of thousands of members) to load can take on the order of 10 or more minutes, during which time no other activities within the viewer can be carried out
• Opening the members group list for large groups can result in performance impacts elsewhere (notably in group chat, as we’ve seen with changes made to that service recently).

In particular, the update is related to additional changes the Lab intends to make to the viewer-side code for group management, as Oz Linden, the Lab’s Technical Director for Second Life, explains:

It turns out – and this was one of the reasons we made the change on the RC channel – because we weren’t really sure what it would affect. But it turns out there are a bunch of places in the viewer, where the viewer triggers these requests for all the members of a group where it’s not even going to use the data … So some of those requests are kind-of bogus and not helpful, and we’re going to be making a set of changes to take those out, and replace them with something more focused.

Do note, however, that this change is not in any way connected to the recent increase in the number of groups Premium members can join, and it is believe that around 600-700 groups are affected by the change.

The initial deployment of the update on the server RC channels on Wednesday, June 3rd gave rise to some concern, notably:

• The message currently displayed by the viewer suggests that rather than the member’s list being prevented from loading, it has simply stalled or perhaps timed-out, which could result in elevated support calls
• The change breaks a lot of ways in which a group’s members list is used – see BUG-9393
• In particular, the change means that people unable to see the members list can no longer ascertain which owners / officers are on-line and in a position to assist with any group-related issues which might occur.

Acknowledging some of these points during the Server Beta User Group meeting on Thursday, June 4th, Oz said:

 There are some things we need to do in the viewer to make some of these changes clearer… those changes will be made as soon as we can … In the mean time, if large groups want their officers to be reachable, they may want to put something in the description to help with that.

Further to this, and in relation to making information on group owners / officer visible to all members of an affected group, and on improving the currently-displayed message in the viewer, Oz further stated during the TPV Developer meeting on Friday, June 5th:

We will find a way to make that information available in the fullness of time [owners / officers], but it probably won’t be real quick … We’re going to fix the problems, but it’s going to require building some new interfaces for things like, “show me who the officers are”.

There are certainly going to be some bug fixes for the viewer coming quite quickly, quite probably in the next maintenance viewer, not the one that will get released next week [week #24]  but the next one, that will clean-up how things look. You’ll actually get a positive indication that you can’t see this list, or whatever. But we’re still fiddling with that.

Thus, while the changes to large groups may initially seem a little confusing, they are part of a larger attempt to improve group management functions within the viewer, and the Lab does recognise that more needs to be done to make key information within groups clearer to members.

In the meantime, please remember this change only affects those groups with 5,000 or more members, and does not prevent those assigned roles / abilities that require them to be able to see the group’s member list. Groups with less than 5,000 members remain unaffected by the change, and all members will continue to be able to see the group members lists for these when viewing a group’s information.

During the Third-Party Viewer Developer’s meeting on Friday, June 5th, Oz Linden raised the subject of making improvements to the current way in which land bans  – both region-wide and for parcels – are presented and managed within Second Life.

In doing so, he invited open-source developers to work with the Lab to help improve how the ban functionality is presented through the viewer, and how it works in general, indicating that those wishing to provide assistance would be able to work with the Lab to improve the viewer-side tools while the Lab’s developers work on the simulator end of things.

His comments came at the 17:58 minute mark of the video from the meeting, which was recorded by Chakat Northspring, and I’m providing his core comments  in audio and text below for reference.

 

One thing that I wanted to talk about was ban lists; and i’m referring to ban lists for land here. Right now … we certainly don’t have a good mechanism for managing the ban list. That is for looking at it and figuring out who are the least important people on it that you can get rid of to make room for more, that sort of thing.  I am putting out a general call for people to think about, and especially to contribute to implementing an improved ban list management mechanism.

At this point, several suggestions were put forward – such as having a note field in the list where the reason a person has been banned can be recorded, and / or adding a means by which a ban can be specified for a length of time before expiring, etc. Oz then continued:

So here’s what I’m really most interested in getting, is somebody who is interested in doing the UI and front-end work, in collaboration with us doing the back-end work for an improved ban list managed interface. So I’m putting out a call for volunteers and if you volunteer and want to put together a specific proposal,  we will evaluate whether or not we can get that much work done on the back, and how quickly, and do all that good stuff.

So that’s an opportunity to make all land owners think that you’re a wonderful person, and of course it comes with the usual inclusion in the contributor’s list and all that good stuff that goes with that.

Open-source contributors willing to assist in this work should probably, in the first instance, contact Oz through the usual channels to indicate their interest.

Due to a missed communication from the Lab, which indicated a preference on their part for this issue not to be blogged about, this post has been withdrawn, at least until such time as I can resolve matters with them.

Updated: Further to a discussion with Oz Linden on Friday, June 5th, there will be an updated report on these changes available on Tuesday, June 9th 2015.