I see posts that are in a boatload of unrealated groups fairly frequently. If I can figure out what group it should go in, I edit out the OT ones. But this doesn't scale well. Do we have a software solution? I don't use OG much so I don't know what's all available. Seems like there should be something for limiting how many groups you can post to. Something permission based would be good, too, so admins can override if needed.
Here's the latest example of a post I don't even know what group to edit it down to: http://groups.drupal.org/node/112724 . In case it gets edited, the current group list is:
Groups: Drupal Fit · Using Open Data in Education · China · Drupal For Law Enforcment · Small Business · Titanium API · Drupal.org Testing Infrastructure · CSS preprocessors and compilers · Drupal And Git · West African Drupal Users Group (WADUG) · Guilds · OpenScholar · PHP · Lansing, MI · Federated Social Web · Membership / Association Website Building · Drupal for CBT or WBT · University of Massachusetts Amherst · Nanaimo · Micro Shops · Google Code-in · Drupal.Trade Facilitation-ASYCUDA · Code Review
That's just an example... While it needs dealing with, the purpose of this post is to get ideas of something we can do in general, not just dealing with that one post.
Thoughts?
Michelle
Comments
OG already supports this, and
OG already supports this, and we already limit job postings to 4 groups. If greggles and josh want to implement a limit for story (aka discussion), the URL is http://groups.drupal.org/admin/content/node-type/story?destination
Hm I didn't know there was a
Hm I didn't know there was a limit on job postings. I could swear I've seen some recently that had a lot more groups, but I admit I can not find them now.
Limiting stories
Well, I'm obviously +1 for it. :)
Michelle
+1 too
+1 too
There has been a LOT of this
There has been a LOT of this in the local groups lately with job postings. They will often just get slammed all over a ton of unrelated local groups. I don't really know what the answer is, I mean this is a problem as old as the internets themselves, but for sure it is irritating and getting worse rather than better.
If my queries right, there's
If my queries right, there's currently only one job like that:
mysql> select count(group_nid), oga.nid from og_ancestry oga inner join node n on oga.nid = n.nid where n.type = 'job' having count(group_nid) > 4 limit 5;
+------------------+------+
| count(group_nid) | nid |
+------------------+------+
| 10181 | 3362 |
+------------------+------+
1 row in set (0.03 sec)
Of course, jobs with more than 4 groups quickly get edited and reduced to 4 so an after-the-fact query is unlikely to catch offendors. All the same, if you see this please screenshot and let me know.
How many groups is reasonable for discussions? 5? 10?
I'm tempted to go for a solution that counts the groups (or even better, the number of members of those groups) and if it breaks a threshold then we drupal_set_message an error and say "hey, this looks like spam, are you really really sure this is on-topic for all the groups?"
knaddison blog | Morris Animal Foundation
How many
Given that g.d.o has a policy of broader, fewer groups so there is very little overlap between groups, I think 3 is really enough. I can't even think of a set of more than 3 groups that are related enough that the same discussion would apply to all of them. As long as admins have the power to add it to more, it could always be done on a case by case basis if needed.
I wouldn't expect a warning to do much. It doesn't stop people from creating test pages in the handbook. :(
Michelle
3-5 seems reasonable. But
3-5 seems reasonable. But I'm more in favor of something like the flag module and let the community/groups decide if its spam. this approach also allows for better tracking of users that don't seem to get it, and can then be better managed (even in an automated way).
--
mike stewart { twitter: @MediaDoneRight | IRC nick: mike stewart }
sounds good, but
I plan to roll out flag_abuse "some time soon" which should help with this.
However the problem with this kind of a checkup is that it is "detective" rather than "preventive" and on g.d.o mail goes out as soon as the submit happens. So, the damage is done once the item has even been posted.
I have been thinking more about how we can track "bad" users and also how we can reward good behavior. I don't have any concrete ideas but will definitely be posting a BOF and working session for g.d.o for Drupalcon Chicago.
knaddison blog | Morris Animal Foundation
We could consider waiting 15
We could consider waiting 15 mins before emailing notifications. Some web readers might catch the spam before notifying. Good for fixing typos as well.
This is my preferred approach
This is my preferred approach as well.
Good idea
I think that would help a lot. Those of us who don't use the email notifications forget or may not even realize it's being mailed out and make multiple edits to fix stuff we see after posting.
Michelle
how do we achieve it?
So, on http://groups.drupal.org/admin/messaging/notifications/intervals we set the time unit for "Immediately" to be "15" and "Minutes" ?
knaddison blog | Morris Animal Foundation