|
|
|
[
Permlink
| « Hide
]
Honey Fairweather added a comment - 22/Mar/07 04:03 PM
Linked as requested by Torley Linden.
This would be SO cool. It's frustrating for me, and for the members of the my group, when they report that someone is spamming the group IM, or otherwise misusing it, and I can't do anything but ban. I was finally forced to close the open registration on my group, which has sharply slowed down the rate at which new people sign up, even though I tell them in the charter to IM me. I had to do this so those where were banned, stayed banned. If I could lock out the worst IM offenders just from the group IM, or even have the ability to do so, it would be a huge help.
Noise and spam and nonsense in the group IM is a primary reason why people are forced to leave large, popular groups. Any tool that helps to control this would be very helpful. Thank you, Honey, for creating this. Brenda Archer Cross posted from the comments of MISC-64 because I believe these two issues are intrisically linked,,and must be addressed simultaneously.
----------------------------------------------------------------- Alright. my suggestion on how this should work. something I think everyone can agree on. Firstly6, on the side of the group owner/officer. Three new options in the role abilites -Allow this role to send group IMs If a role is not allowed to send group IMs. when they try to type in the group IM box, their message would be discarded by the system(and seen by noone), and they would recieve an automated message from second life "Error: Message failed. You do not have permission to send IMs to this group" If a role is allowed to send IMs, the ability to recieve IMs would be forced on too. So as to prevent people typing aimlessly and seeing nothing, while spamming other roles in the group. If ability to recieve IMs is disabled, likewise, ability to send them would be forcibly disabled too. When not allowed to recieve IMs, that role would somply become oblivious to all IM conversatiohns in the group. Their I window would NEVER be opened by that group. In group info, on the user end. Somewhere near the choose your title menu, there would be a little tick box. This would be to prevent muting of chat in groups which are designed for it. The simple logic being, if a user does not want to recieve IMs, from a group whose purpose is conversation and chat, they should simply leave the group. Of course, the purpose of the group is to be decided by the owner. If permission to recieve IMs is removed from this rle, the option to allow muting, wqould be deselected too. But the user mute settings should stuick. SO that if someone has muted chat from a group, and permission to recieve IMs is revoked, then later reinstated, they would still not recieve IMs. If permission to send or recieve IMs is revoked while a user in that role is currently in a chat session, they would be ejected from the session and given the following error message "You have been ejected from this group IM session. Your permission to participate in IMs to this group has been revoked." Note that it SHOULD be possible to set a role to be able to recieve IMs, but not to send them.. This would allow group administrators to use it as a one way communication tool. In such situations where a group notice is not appropriate. One example I can think of would be a commander of a force engaged in a battle. The group IM could be used to communicate orders to the troops, where a group notice would not be useful as it is slower, and would be unnecessarily shown to offline members. And where allowing the troops to talk back could lead to confusion. If you're pacifist, replace the above with a manager, a team, and a competetive game. Wow, this is a looong comment. Anyways, I'm fairly sure I've covered all the bases here. Pretty much every possible situation that could arise. Needless to say, I'm including the ability to prevent sending IMs, and the ability to mute them, in a single plan, even though they are seprate proposals. I think they would work best in tandem. WorkingOnIt Linden, you want exact implementation, here it is ^^ I agree with the following role permission additions :
-Allow this role to send group IMs -Allow this role to recieve group IMs -Allow this role to mute group IMs (this would be greyed out an non-selectable until "-Allow this role to recieve group IMs" is ticked. I also support the ability for group members to mute group chat. Therefore, lets go with giving the group owners tools to limit who can send/recieve group IMs, and hope that, when this is used to good effect, people will think mute is not needed. However, I would also suggest splitting "Allow this role to send group IMs", into : I suggest this so that it is possible to have 'announcement only' groups without worrying about spam from replies. I would also suggest adding : I suggest this because it makes sense to have a new permission added for voice chat, which is going to arrive here eventually. I very much agree that ejecting someone from a group should terminate their ability to send messages to that group, and kick them from the group chat session if they are already in it (with an "AvatarName has been kicked from the group" message). There are a few more links related to this topic, which I have posted in my reply to your thread, at http://forums.secondlife.com/showthread.php?p=1551641 Angel,
I have to disagree with you a bit. Being able to mute the group chat temporarily or selectively, under the member's control, can be very beneficial for certain types of groups. If this feature was available, I certainly would turn it on for the Everyone role of my group. It's true that there would be a certain percentage of the group who never get IM and never get Notices, but that doesn't bother me in the slightest, as they still can visit the group website and get announcements there. Having to be certain all members of the group get a message isn't necessary in my group. It's too much manual work for me as a group owner to move a thousand people to the right role of being able to receive group IM or not. This feature, to work for me, needs to be user driven. As I said above : "I also support the ability for group members to mute group chat".
My point was that attempting to limit group members' ability to mute the chat is ultimately futile, as people will make modified versions of the open source client which bypass this restriction. well its abit good idea, but...
I rater see a button in the info about group that you can mark to disable group chat just for that group (seperate for every group), some groups are good due to product update, but again there are active people talkin on the group channel, so adding a button in info about a group that you can mark to disable gettin chat from that group would be allso be good good. made one here https://jira.secondlife.com/browse/VWR-1450  vote for it if you like the idea Hmm. I think I would rather see role-based IM sessions and/or notices so you could, for example, open a session and chat with only the group's other officers. In any case the basic requirement of finer-grained intra-group communication options is a good one.
Add new role abilities: "can send to group IM" "can receive group IM". Also give each user a checkbox: "Receive group IMs", similar to "Receive Group Notices" that is already there.
JZZ It SHOULD be able so each and every one in SL (those with NO admin rite to the group) can choose to resive or not to resive group chat.
i agree - ir more annoying because i getting spams from other groups and it time to the group had controls on IMs and etc so making more controlled group - follow the rules and controlling the spams and stupid people off the IMs would reduce people getting the IMS
for example - i have group for dragons - so only members who has TAG would allow chat or owner checks each message - screening the group IMS so it should slow down the stupid people using IMS and also you can disable group IMS - only notices can sent out - so it good idea Are you there, Lab? It's me, Wildefire. Please implement this measure. Amen.
Okay, I'd like to summarize what I think is useful and easy to use:
Following group roles to add:
Additional button for each group member to toggle:
Explanation: For "Create", "Answer" and "Receive" the following should be enforced. Also "Create" will include "Answer" and "Receive", also "Answer" will include "Receive". All these settings can be enabled by default for compatibility to already existing groups. For a quick implementation of this permissions, the "Receive" permission can be implemented later. It would really help, when "Create" and "Answer" permissions exist, and the "Receive Group IM" setting for every resident is available to opt-out of Group IM. IMHO, it would really help, when that "Receive Group IM" setting was available alone already. There should be no way to enforce a group IM session to open at a resident and the resident should also have the ability to mute people that are part of the group IM session, as that isn't possible currently anyway. Also every resident should be able to mute everyone they like. I propose an additional setting that allows muting of names, that contain "Linden" as a word, as an additional preferences setting. IN ADDITION...
I would like to ask that in addition to the ability to ban someone from talking in a group, even though they are still a member, as well as the ability to mute group chatter while still remaining as a member, I would like to see a feature where a "Group Message Window" exists that can passively sit in the background and color-coded, timestamped messages appear there live. People can be having a conversation in the group, and the messages will PASSIVELY update on this window, and group announcements will have one color and appear with a timestamp, and group votes/proposals will appear as another line with a different color.. and admin control messages (for actions the group admins take) could appear with yet another color. The user, when they have the time, could then go to this window and peruse the conversation as they see fit, and add to the conversation live if they wish. In addition, a marker that indicates they are an active listener to the conversation, or that they have left the conversation but are still viewing past messages from before they left will also be present on this window. The lines that represent timestamped proposals and announcements could be clicked on so the entire message could be seen. When the person is busy in this window, or any other windows or dialog boxes in Second Life, an action-event should be generated so programmers can create animation overrides that show the users status as "Busy In-Game" (as opposed to "away from keyboard") so that a persons friends will know that the avatar is active in Second Life but is busy doing something in group chat, inventory, preferences, or something similar. Some groups are intended for new people (anyone) to join and ask questions.
Those group owners probably would still allow anyone to join and send a group IM, so the individual opt-out "receive group IMs" would be necessary. Upped priority to critical, because it is in the most-requested features by vote count, and has several clear applications (such as preventing IM spam on big groups, a major problem).
This feature is also necessary for SL to scale into the future (a future where SL is bigger will have bigger groups, and bigger groups = more spam problems). In addition, standard countermeasures which people suggest (such as making the group invite only, and only inviting people once they accept a "no spam" rule) won't work in many cases (such as groups for newbies and clubs, which simply won't work if they are hard to join). I oppose this feature, as it unnecessarily disenfranchises people in groups, makes them subject to the will of a handful of group or land barons, and destoys the free nature of Second Life, putting power into the hands of the few concerned with building a security state.
If you do not want someone's IMs in your group, you have a simple solution: you make a group that is closed, by invitation only, and you expel that person. If you insist on keeping an open group, and you wish to have anyone join it either for the sake of business or project convenience, or to be able to show that you have the biggest group in Second Life cough, then you have to live with the fact that people will put IMs to it. The problem is hugely exaggerated. One can always close the window and ignore it. If it's an open group, you can leave the group if IM spamming happens to occur occasionally – and rejoin. Second Life doesn't scale by having power to mute and ban put into the hands of the few who claim to have "big groups" which they secure by requiring that people use their sim join a group to remain under their control. People join groups in order to prevent their prims from being autoreturned, not to have their voices silenced. One can maintain a police in the lease in a rental, for example, telling people not to spam the group, and evicting them if they do. This works fine, and when people sometimes have urgent emergencies, like a griefing attack or announcement that a sim crashed, it's good that they have a voice for those rare occasions even in a group calling on people not to chat in the group. By implying that the future of Second Life scales only with tools, and never with policies, it is laying the groundwork for a vast 3-D Metaverse in which tools made by a tiny handful of coders who can mute the voices of the many and even erase their view get to decide the fate of all. That's unacceptable. I don't know how on earth you people think you have popularity for an idea merely because it has a 100 odd votes on the cumbersome, obscure, arcane, and little used (except by tekkies) JIRA. This is a very necessary spam prevention measure for large groups, with multiple roles. Roles in a complex group are not trivial to set up, and people who leave a group lose their group assignment when leaving the group, so leaving the group due to spam is not an option for those in an important role position.
At the present time, anyone who joins an open enrollment group can spam the chat with unwanted advertisement. In fact in some groups the spam traffic is so immense it causes people to unjoin, and never to return again. The spammers are destroying group based communities, causing them to become invite only rather than open enrollment. This defeats community building - group IM is indeed the most important method in SL to communicate to a large number of people (thousands) at one time, but group admins need better tools to moderate large groups. Simulators can only support a few dozen avatars - only group IM can support thousands in a chat session. (though that's bugged too - different issue though) I would also support adding "allow user to start a group voice chat session" to a related Jira. How I would suggest implementation is as follows: Make "allow user to send group IM" a default for everyone. Allow the group admins to uncheck this option - this can be useful in setting up a spammer ban IM list, or for those people who you would want to just give a temporary suspension to. Or to temporarily halt the chat during a flame war. This would be incredibly useful for me, where I would not want to ban my general users from chatting but use mute in selected circumstances to deal with abuse of group IMs. And please, allow this to take hold in the current IM session. a huge bug is that the spammer continues to spam advertisements even when they have been ejected from group. This would allow me not to have to eject them from group, but just mute them from sending any more spam over the group. Spammer and grievers abuse (large) groups
Even when some griever or spammer is ejected, they can go on with there flooding and spamming (lag) Everything that will stop this is very welcome It would be useful to temporarily mute group IMs.
Group use is very different though. Some, like rentals, might be closed, and fair enough. Some though are help groups, and need to be open, and allow IMs so help can be given by members, but people abuse it spamming. If the group is closed, then someone may not be able to get immediate help if the group owner is in a different time zone. Really, I'd be looking more at having a ban list for open groups at least. You do need to wake up to the fact this thing is global, and not just time zone, but if people are 12 hours apart, may never catch up with someone else in another time zone. But it would be very nice, if you could get this all working as fast as it did before you moved it external, which is what you promised: faster not slower lol. We just need something basic and functional.
Such as adding the following to Groups > Roles > Allowed Abilities: ---------------------------------------------------------------- It deserves a "Instant Messages" category of its own because it doesnt really belong anywhere else. It would also make it consistent with the "Notices" category which has a Send and Receive option. The "Instant Messages" category should be placed directly above or below the current "Notices" category because it's all communications related. Regarding Prokofy's rant. What you're really arguing for then is that group IM and group notices should be tied together and the owner must have no choice in this, even if they only require one feature. This is ridiculous. Many businesses require group notices and they shouldn't be forced to put up with persistent IM spam when they don't even require the IM feature at all. IMs is only one of many practical uses for the group system - we should not be forced to use it. If you're worried about it being abused by allowing some people to talk while muting others within the same group then how about a single "Allow Instant Messages" option. This could be placed in Group Preferences (owner options side) or in Roles. Personally I would prefer Roles because that would allow group owners/admin to chat, and if group members arent even aware of the chat then what's the harm. But I would be 100% happy either way. "By implying that the future of Second Life scales only with tools, and never with policies" You're the one that made that sweeping assumption. We just seek a practical solution to one ongoing issue. All very well having a policy but spammers will take no notice of it. It's like asking for no e-mail spam filtering and to adopt a policy instead. It's just not practical. We need tools and options to deal with people that deliberately abuse systems. There's just no way around that basic need. "I don't know how on earth you people think you have popularity for an idea merely because it has a 100 odd votes on the cumbersome, obscure, arcane, and little used (except by tekkies) JIRA." Ironically you're the only individual I've seen argue against this feature so what makes you think your opinion weighs so much. I've witnessed many many people express need for this option since i Joined SL. The Lindens admit it's a much requested feature. If you can't even see this then why are you bothering to post. Anyway, to clarify... Add the following to Groups > Roles > Allowed Abilities: ---------------------------------------------------------------- Doesnt get any simpler than this and it would make 99% of the people complaining about this happy I'm sure. This is really all it boils down to without overcomplicating things. If someone is not a member of a Role which has this option ticked then they can't send or receive IMs. One of my groups is in the 4,500 to 5,000 members range.
This is despite it being invite-only and having a L$95 join fee. My staff put substantial effort into making sure people don't spam this group, because a single spammer can annoy hundreds of my guests. Nevertheless, it happens, and when it does happen, even ejecting the offender doesn't solve the problem, because they can continue to spam the group until they relog. We need the ability to limit sending/receiving of group instant messages by role, and we need it yesterday. We have it for notices, and having it for instant messages is long, long overdue. This problem is, I suspect, one of the things that is preventing SL from scaling upwards in terms of users. It is the nature of life that people will gather together. People attract other people. Groups, like sims, need to be able to handle large groups of people in one place. And they need to do it in a way popular spaces are easy for their owners to manage. The fact that such high-density spaces are either impossible (avatar limits on sims) or very difficult to manage (large groups) could be one of the things preventing SL from being more widely popular. Adding the ability to limit IMs within groups is hopefully easier than re-designing SL so that it becomes possible to have many avatars in one sim. So, please, add this feature. It won't solve the scaling/density issues, but it will help. This is very specifically not a duplicate of MISC-64 - I am the Reporter of both JIRAs.
MISC-64: group member controls receipt or not of IMs 1) is to give all users choice, as they have with notices Hope this explains. Honey I support this one whole heartedly. Without this spammers have and continue to abuse large groups with complete disregard to the rules in the groups. It would make things far easier on the moderators and the users of a group who do not appreciate being annoyed from people who should have no right to be sending out group chats. The only people I can see objecting to it is the spammers themselves and SL would be a much better place without their filth.
gasp They're adding group moderator tools to the release client!
http://wiki.secondlife.com/wiki/Release_Notes/Second_Life_Release_Candidate/1.21#Moderation_for_Group_Text_and_Group_Voice
Ignore the previous version of this comment – you CAN turn it off by role! YAY! I won't change the status on this JIRA as I'd wager it will only fully kick in when all the chatters are in 1.24 regions. Plus it's just RC0. But this is great! Wow, thanks for alerting us Jen! As original author of this bug report (17! months ago), I'm testing now to see if this is really fixed and have already toggled off group IMs and voice in my group Fashion Consolidated which is plagued with spam. It's looking generally good so far, with the following provisos:
1) When testing bear in mind that the role toggle seems to stop a member initiating a new group IM session - users with the group's IM window open when the role is toggled will still be able to chat until they leave - but won't be able to re-join in theory. The intention of this JIRA wasn't the same as SVC-2820, which is a request for a personal toggle to turn off viewing group IMs, rather than admins stopping people sending IMs. It would be nice if this JIRA was implemented as a way to still allow admins to send (emergency) group IMs to all members, but in the meantime, this looks like a sledgehammer fix for spam so far, with the proviso that I'm still testing now in smaller groups which aren't complicated by (all the other (P.S. It would be really nice if Linden employees communicated regularly here - we hear very rarely, and when fixes like this with massive potentially positive consequences are implemented silently in RCs, but are applicable to all group members regardless of their viewer versions, this is big news, particularly after 17 months wait. Please talk to us!) More feedback: this new feature in 1.21.0 (95157) doesn't cleanly fix this problem, and a small percentage of users are breaking through it.
Honey Thanks so much for the testing, Honey. I bet a lot of this inconsistency is due to the continued rollout of 1.24 today. It also may be dependent on who's using the RC or some combination interaction thereof
 , as described for other features mentioned in the release notes.
I'm planning to wait a couple days to see how this plays out after the rollout is done and the RC is more widely adopted. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
New Feature
Open
Critical
New Feature -> Dialog -> Group Information -> Members & Roles -> Abilities -> Send IMs
) group bugs.