10 Things that deprives Elgg community from activity


... But, in spite of the fact that this is the only official community, there are a certain things that I felt prevents people to communicate with each other to squeeze more juice out of the fruit. I have tried to find out the ten reasons for such.

  • Elgg receives most of the criticisms from the people who love it and hang around it.

    Help on the elgg community, I believe, is always oferred to those who seek for it. :) After all, we all love Elgg.

    @Ismail: This is precisely what I hinted at. ;)

  • Guys, I am bit novice here, with only three plugins and less than one year of community.

    But I came from Drupal universe and I learned to respect some ELGG solutions. But Drupal community should be a example to be followed. The plugin´s page has a LOT of search options, a issue tracker inside the plugin´s profile and a filter for Drupal´s version.

    ELGG should be better in two aspects:

    • Help the new users to find good plugins, saving time to newbies. Maybe sorting for "last update" status and so on.
    • Documentation: When I was a newbie here, I find a bit difficult to learn how the things works. Maybe a "start here if you dont know elgg" could be usefull. A page showing the basics of ELGG, how to download and enable plugins and links to the more need resources. Weeks ago I didn´t know that ELGG has a trac to open tickets!

    Since the core team is small and heroic (3 guys only), the community (Ourselves) should help with the improvements. I have a idea for a "version notification plugin" that send a e-mail to the user when a new version is released. A simple "call to home" once a week. I am thinking to implement in my plugins, but I need to read some GPL therms to be sure that a "call to home" is not against the terms. This "auto update" feature should be good to ELGG, becoming a standard to new plugins.

    Well, we need to work and help and ACT like a community. Cash was correct when said "You want a better community? So help us to make a better community".

    I would like to finish saying how a community should work: When I started developing my plugins, a old user pvt me offering help. We had LONG talks in the last months, and he helped me a lot, with technical resources, testing and a lot of friendship. Their name? Dhrup.

    A community must work in that way. We must help others developers and not be jealous if a developer make a better job than us. "Community" guys! "Opensource" guys! :)

    Ps.: Excuse my english. Here in Brasil english is obrigatory in scholl, but I was a BAD student. :)

  • All great comments, guys. Thanks for making this a positive thread.

    @Ray - If you implement a call home, make sure that it is opt-in. People don't like the idea of having their servers call home without being asked! I thought about how to implement that here. As close as we've come, if you follow a developer, you get an email whenever a new version is released of their plugins. The part where I'm stuck is how to correlate the plugin on the user's site with the plugin project on this site. Maybe a hash of the manifest file?

    @Rodolfo - I'm definitely interested. We would need to define what a moderator would do and then code up something to give additional access.

    @Ismayil and others - Maybe a thread to discuss/plan this in the newly renamed Elgg Feedback and Planning group?

    @Ismayil - being a core developer is just like being a plugin developer except on a different scale. You generally only get positive feedback with the excitement of a new release. Thank you for your kind words.

  • @Cash: Good idea. I will make some tests and try to show a "almost done" solution to you. But I though in a more simple solution. A webservice where you pass the plugin´s name, version and elgg target version. The webservice just say if there is a new version that fits the requirements.

    Something like: Call the webservice with "spam_login_filter:1.7.3b:1.7". The webservice can send a response like "For ELGG 1.7, there is a new version (1.7.3c)" and a link to direct download.

    And yes, the information can be stored in manifest file. And to be reusable, the webservice should be a elgg plugin, storing plugin´s information in metadata. Let´s make some tests here.

    Ps.: We need to take care with server loads, because the webservice will run a full ELGG engine, without authentication.

    Ps2.: Another approach is subscribe a plugin in ELGG community. If a new version is released, the site can send notification to subscribers. But we need some customization in ELGG´s community. What you think?

  • When a new plugin version is released, it will be better if the new version is listed on top of the "Latest Plugins" list. Sometimes it gets difficult for the newbie(like me) to get an updates on the new version.

    Although we get update, when we friend the plugin creator its not possible to friend all the fantastic guys out here.

  • 'Call-Home' / Auto-Updater --

    Should be not much more complicated than storing and comparing :-
    <name>Overly Sliders</name>

    If different -- inform user that there is a different / later version available -
    And allow (Auto) update.
    Repository can store an extract from manifest of same data.

Shouvik Mukherjee

Entrepreneur, Developer, Linux Lover, FOSS Supporter