Forum Replies Created
-
@hnla It is a good idea, but only works if it is institutional and tech-enabled. e.g. An area on this website dedicated to that pursuit that enables developers to bid on projects and “crowds” to “promise” money (via some sort of escrow or another, simpler system)…it is important to know both – what the developers need for the project, and what the crowds are willing to pay…
@djpaul Don’t imagine they do. I do imagine that sometimes the demand can come from users as different from the usual “build it, and they will come” model.
@hnla As you have astutely noted, this is a plugin request, and hence I am hoping someone might release a plugin.
Anyone?
Another one on my list: Hierarchical Groups with upwards member propagation: https://buddypress.trac.wordpress.org/ticket/3961
Mid July IS the schedule. 🙂
@bphelp 1.8 Beta 1 is out so there’s a real possibility that 1.8 might be released in mid-July as scheduled.
Faint ray of hope that 1.9 might come as early as Jan/Feb 2014 🙂
Fantastic
@sbrajesh Yup, I can see that use case. I meant the plugin is useless for this particular purpose.
As far as Friendship request throttling is concerned, I am about to release a plugin today which does allows site admins to limit the no. of requests sent per minute(or you can set say 30 requests per 60 mins, that flexibility lies with the site admins).
Fantastic!
Thanks @bphelp
The plugin seems like a terrible idea. I mean some particular installation somewhere in the BuddyPress world might need it, but I don’t like the idea of limiting BP’s functionality (potentially thwarting the value of the online community) for everyone to try and stop a few bad apples. What number will you limit the friends to so that spammers are blocked and the community is valuable? 5, 10, 50, 100, 500?
Your original idea of throttling friend requests was far neater and remains superior to this plugin’s concept.
Doesn’t require any change in Akismet.
Akismet plugin will need a little change – it will need to tie reporting to role.
BuddyPress will need to incorporate the functionality of members/users flagging activity, the way users can report messages in software like phpBB.
Nope, flagging by members shouldnt be reported to Akismet directly. As mentioned above, it’s a two step process. Site/Group admin can’t be everywhere, so users should be able to flag items for their review. Site/Group admins should be the ones whose flags ultimately get reported to Akismet.
Well activity is already protected by akismet integration.
Except that there is no good way for members to flag activity.
@bphelp Are you referring to this one? https://wordpress.org/plugins/buddypress-activity-privacy/
The description says
The plugin add the ability for members to choose who can read his activity before it posted (Anyone, Logged In Users, My Friends, Admins Only, Only me, My Friends in Group , Group Members …etc).
Sending friend requests to folks you don’t know is an issue that all social networks, be they Facebook, Orkut, MySpace, Hi5, or even LinkedIn, have to contend with.
That said, I wouldn’t call it the bane of social networking. What really does a purported “spammer” gain by sending friend requests? Annoyance for certain people that they have received a friend request? Unlikely – the text is preset…the spammer cant even include his/her fake links. Also, most folks are now pretty adept at ignoring such messages. And even if somebody accepts the friend request, what does the spammer gain? What does a “friendship” accomplish?
Comments (WP), forums (bbP) and activity feeds do really really need spam protection. I’m not so sure about the necessity for friend requests.
That being said, how do the big boys manage friend requests?
1. LinkedIn: You can only friend people who are 2 degrees away from you OR whose email address you know. Plus, recipients can mark it as spam.
2. Facebook: Members can control whether they want to receive friend requests at all. Plus recipients can mark requests as spam. Finally, temporary & permanent bans – based on proportion of requests marked as spam.Throttling is neat, cool and easily done – perhaps like bbP, site admin can define the throttling parameters for BP friend requests throttling.
Much more importantly, an Akismet-like solution for activity spam would be nice. I would look for a 2 stage process on the manual “mark as spam” side of things:
1. Member marks another member’s activity as spam (this is really a flag that puts the activity in a basket for admin to see)
2. Admin looks through the basket and marks either as spam (in which case Akismet is notified) or not spam.@bphelp I think you aren’t giving the developers enough credit. Version releases have been accelerating
1.2 to 1.5 took 20 months
1.5 to 1.6 took 11 months
1.6 to 1.7 took 8 monthsTrac can be deceptive, but based on current roadmap https://buddypress.trac.wordpress.org/roadmap 32% of 1.8 is completed and 1.8 is due in July (7 weeks from now). Even if that is revised and we get 1.8 only in November, we could possibly see 1.9 as early as May next year (or we may not…this is pure speculation).
Eitherway, most major projects I know close scoping for a version long before a beta of the previous version is released.
@mercime Thanks. BTW #4796 was started by Boone.w.r.t. #5008, the idea is to have widget for “previews” of the different tabs. Site/Group admins can decide for themselves which widgets (or even none at all) they want to show on the member profile page.
In a similar vein, groups could have member widgets too (though I havent requested them yet, and there is no ticket for them). I think it’s pretty reasonable to show some group members on the group profile.
Handsome devil indeed. But his avatar here (the one with one eye) gives the impression that he’s a balding 35-year old). LOL.
Anyway, where’s my guacomole?
import/export functions
Can you elaborate?
Hmm..Boone is much younger and totally not bald…than his avatar leads one to believe…
Thanks @naijaping
Would be really cool if you could submit this as a patch for inclusion in the core.
Chime in here: https://buddypress.trac.wordpress.org/ticket/4132
60% of the plugins listed here https://buddypress.org/extend/plugins are not really BuddyPress plugins
Which is not terrible of and by itself (these are BP-compatible plugins for WP). But I agree, there needs to be a way to separate out “Plugins for BuddyPress” (things that actually extend the functionality of BuddyPress) from “WordPress plugins that work with BuddyPress”
@hnla Ticket updated, in case you’d like to weigh in there.
