'wp + 10k users' ? hah! they who talk

'data designated public/logged-in-users..' ?? u gotta be talking abt DB sharding and that will take some effort. closest built-in to this i have seen is.. my oldd 'distributed elgg directions' prxes @ boston few years back; but never had a chance to devote time to that direction, even tho @conf dinnner a few Devs and approached to discuss actually developing code to support that design ;o(

'roles/perms' in elgg is wayy underdevloepd and not mature yet. my personal appraisal re that 'roles plugin' ? sounds attractivem but.. zero @user-oriented us/ ux, needs far too much 'code tweaking' (not what users want to do), not geared towards plug-and-play, does not (or very) utilize any of the elgg data model that naturally caters to and endears - think @nix`d g:u & 'rwx' ;) -- i see no internal limitations! & the sweet spot ? so simple to implement rbac for elgg; call this attitude just different set of eyes!) to std rbac styled roles/perms functionality. tha's not a step forward in my experience with (substantive) acf.. facilities of mature platforms. whay makes that unsuitable? => the need to code all those extra plugins to support other plugins (groups, profile mngr, etc). an acf by itself should be the be-all-end-all for rbac in elgg not further support code should be necessary! everything you've mentioned above can be coded for elgg's current dm & processes design -- minus the several thousand loc!

@Steve:

FYI http://trac.elgg.org/ticket/4888

I've banned Hannibal Smith because he was a existing member of the site posting under an alias. I'd encourage him to post under his own account if he wants to continue this conversation, now that conversation has been wrangled back to the realm of constructively.

i pitty the fool :)

1. For some time we thought that Elgg would evolve into an "off the shelve social network". As we know most of the time sites need customisation quickly. I suggest to put even more emphasis that Elgg is "social network framework" to be used by developers.
2. Let us "bite the bullet" and start eating our own lunch: close Trac and the Google groups. Let us focus all our communication on Github and Elgg.org.  I will miss both Trac and Google, but it will make life easier in the end.
3. Gradually improve elgg.org to make it faster, easier to navigate
4. Introduce contributor groups on elgg.org: Show the people with real faces, real people. A documentation team, a performance team, an elgg.org team. There are enough people here, let us bundle our efforts.

I agree with points 3 and 4

I agree with closing google groups, it's not used very much and such discussion can take place in the community anyway.  I don't see any value in closing Trac though, it's far superior to the github issue tracker and closing it would be very disruptive.

I don't see any value in closing Trac though, it's far superior to the github issue tracker and closing it would be very disruptive.

We're actually talking about this internally. There are a number of problems with closing trac and we're evaluating if these cons outweigh the pros.

@Brett : Though using git has an advantage that all the development resources can be centralized, keep the trac alive its more comfortable than git.

a rather older comparision chart.. you can add in your own updates ;) however the basics of feature compariisons are there. i'd found this 'somewhere' just dont remember.. (http://www.deanflory.com/ @ the logo at the top!) wonder if he's done anything more current ? soo if y'all wanna read up some realistic compares with no real b/s ;oO hit my server but not too hard ;X

and.. re: "'.. emphasis that Elgg is "social network framework" to be used by developers ' ? not true! theres too many features in elgg that makes it more or less the standard off the shelf pkg. i reckon it is only those super-hungry newbie 'the next facebook' website owner-starters who do/will not pay for really good stuff who usually complain loudest with open source, freebie, cwapz with the atlantic ocean amoeba sob-story shtz..!