Community Best Practices for the Plugin Repository

There have been a lot of discussions recently over when to fork a plugin and how it should be done. The terms of this site do not say anything about forking plugins, but it is clear that the community has certain expectations over how this should be done. Let's discuss this.

Some questions to get this started:

  • What should a developer do before uploading a modified version of a plugin?
  • If a member contributes code to a plugin, how should the developer of the plugin recognize that contribution?
  • What can be done to make it easier to work together on plugins?
  • How should we encourage new community members to follow whatever best practices that we arrive at?
  • Another 5 cents. I had a short discussion with @imoni in repose to his request to fork hypeAlive to make it work with Facebook Theme and I made a suggestion that he seemed to agree with.

    In 75% of cases, there is no reason to fork and redistribute an entire plugin to 'fix' it. 'Fixing', as with regular plugin development (where individual plugins extend and overwrite core functionality of Elgg), can be done with overloading specific views, unregistering/registering page_handlers, actions and hooks in a good'ol Elgg-way. If any minor modifications are necessary in the core of the plugin being forked (for instance, to modify manifest.xml), then simple instructions can be added with what hacks need to be inserted into the original plugin (considering that those plugins are abandoned most of the time, one wouldn't expect updates that would overwrite such hacks).

    Of anyone willing to 'fix' anything, I would expect a certain level of responsibility, talent and knowledge, including that of how things work in Elgg and the ingenious API Elgg makes available to us. If someone decides to do a favour to this community by releasing a fix, it is fair to expect that such fix comes in a least intrusive manner. Think of a plugin you are trying to fix as a read-only folder.

  • I think Matt's 5 points are good as well.

  • Just a few cents about community work: Matt asked me about a official 1.8 version of the antispam plugin. Since I have few time to my ELGG hobby, I made a few basic corrections, uploaded the sources to github, Matt forked it and made the dirty job. Now I will test and polish the code and release a new version, thanks to Matt.

    Etiquete is the word, but we need to teach to the new developers how the things works.

    BTW: Thanks Matt.

  • That's a good example RAY J.

Feedback and Planning

Feedback and Planning

Discussions about the past, present, and future of Elgg and this community site.