I was re-reading Veriss ideas on raid rosters and need some input on this.  

My basic idea is it is a widget that allow users to say "these" people are in "this" group.   Maybe its a "PVPers" group or a set  "Raid Team" or a "Friday 10 Man".

But what should this list do (if anything)?   Is it just a quick way for group leaders to know who to invite on raid night?  Or should it have more functional and if so what are your ideas on what it should do?

I must respectfully disagree...  Frankly, we use a script that doesn't even ALLOW members to specify role.  I've used other portal services and they show the member's class and level.  It shouldbe the RAID LEADER's job to tell you what your role is, not the other way around.  If a member prefers a particular role, they can easily specify that in the comments for the event.

Since you've brought up changes to the event UI, I'd like to repost my requests from this thread:

• Lose "role".  We need class and level.  I currently use a script from Mottie to import the class and level information from our roster into the signup table and another script to hide the "role" selection in the signup process.  Many character classes can serve multiple roles and as the raid LEADER, the person choosing who goes and who doesn't, I want to determine what they are going to do.  I need to know their class and level to determine what roles they can fill and how well.  Not all classes "tank" equally, for example.
• Alter the "Confirm All" behavior.  The way the admin's "Confirm All" link currently works makes it unusable most of the time, forcing us to confirm folks one at a time, which is laborious AND defeats the purpose of the link.  Currently, "confirm all" confirms everyone listed as available, including those marked as wait list.  So, if we have 15 signed up as available for a 12-person raid (3 extra), we normally put the extras on the wait list.  If I do that, then hit "confirm all". those "wait list" members are now marked as "confirmed"!  If I DON'T put them on the wait list, all 15 who signed up as "available" will now be marked as "confirmed"!  So, add anyone marked as "wait list" to the other groups (tentative and canceled) that will not be marked as "confirmed" when I hit "confirm all".  That way, I can set our extras as "wait list", then hit "confirm all" to confirm everyone else.
• Character Link: The character signed up with should link to the roster entry details so the raid organizer can quickly look up character stats.
• "Select all" for DKP.  Please add a "select all" option on the event details page and the DKP screen in the follow-up so that no matter which way I enter DKP, I don't have to check every little box. 
• Update signup time when changed.  We give preference to members who sign up first.  We won't want folks signing up for EVERY event as tentative, WAY in advance, then changing to Available at the very last minute.  If they modify their status, change the time signed up to the time they modified it.

Hi and thank you for looking this over.

I had originally envisioned the teams/groups being more static but I see from the responses that many guilds have more dynamic raid rosters that are reshaped for specific events. These ideas were intended for more static groupings but perhaps could be useful for dynamic groups as well. 

For static PVP teams in SWTOR working on advancing in ladder rankings, let's name our example teams the "Dirty Dozen" and the "Huttballerz", the members would not change very often and a specific calendar event could be designated for the Dirty Dozen team or the Huttballerz.  Possibly the members of the team specified could receive a mail reminding them of the event when it is created or updated.  A guild could have different PVP teams working on different schedules, ladders and content.  

For PVE content in SWTOR.  It appears at release that the larger raid/operations groups will be 16 person teams.  Our guild is looking at forming two of them initially, perhaps named the "Red Team" and the "Black Team".  The two teams would have their own raid/operations team leaders with their own independent schedules.  The Quest Admins or Event Admins could designate specific events on the calendar for the individual teams.  The team members could receive GP mail notifications of new events or updates to the events for the teams they belong to.  Team leaders or Quest Admins could send mail or Rallies to "Red Team" or "Black Team" concerning team business.  

Additionally, there are also raids/operations for 8 person teams.  Thus, the 16 person Red and Black Teams would each have two 8 person sub-teams (Red-1 and Red-2, Black-1 and Black-2, etc.) with their own team leaders that could run separate content that doesn't interfere with their main groupings.  Theoretically it could be broken down to 4 person groups but I don't see the benefit of the added complexity to do that.  

At the big picture leadership level, guild leaders could choose a new view of the guild roster that indicates each character's GP User Name, Character Name, Level, Adv Class, Primary Role ("T", Tank, "H", Healer, "D", DPS), and indicate the teams the character belongs to.  Separate PVP and PVE columns indicating the largest team grouping each character belongs to would be very helpful.  The PVE column could indicate the character belongs to the Red team or the Black team.  The PVP column could indicate the character belongs to the Dirty Dozen or the Huttballerz.  This would help guild leaders organize teams, see who's left out, who might work as alternates or standby's, etc.

This was an attempt to clarify my original request as a more general concept without getting too far into the weeds about the details as I did previously.  I'm not a coder so don't know how hard any of this is to do but I truly appreciate that management is looking into it.  This started out as a request specific to SWTOR but it could be useful for other games as well.  

P/S: In SWTOR, designating the the general role of a character is important as the class' talent trees determine if the character is a tank, healer or DPS, not the class or advanced class.  A Bounty Hunter could easily be a tank, a primary healer or DPS depending on how they spend their talent points.  The character's advance class indicates the "flavor" of the basic tank/heal/DPS role but not the basic role which is useful to leadership for specific assignments. There is no way in SWTOR of knowing the basic role a character fills just by looking at the class and advanced class, the player needs to designate which role his character is built for.  

(Edited for typos)

I think this part was fixed last code change, am I wrong?

From an SWTOR standpoint, we may be looking at it from too much of a WoW/Rift/DDO/SWG point of view where the class/advanced class dictates a character's role.  I have trouble wrapping my arms around the SWTOR rather fluid concept as well from an organizational point of view but it is what it is.

I think the member designated "role" (dps. tank, heals) could be separate and not linked to the character's class or advanced class in the database.  The member designates the character's role and if he screws it up and selects heals as a Sith Warrior Marauder then it's on the member for failing reading comprehension.  

As long as there is no "default" selection, the member will probably pick the correct role.  Guild leadership can clean up those few thoughtless errors pretty easily if the member is trying to join a team.  

We can only baby-proof this so much.  Just let the member choose the role from a drop down and let the guild roster reflect that the character is D, T or H (DPS, Tank or Heals) depending on what the member chose.  Trying to keep the columns as narrow as possible because I'm asking for a lot more columns in this roster view.  

I thought the big challenges would be the groups and sub-groups as their own entities within the guild.  I hope this helps some.  

Cheers!