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?
  • Thanks for taking the time to get this going Cash. My 2 cents.

    1) At least mention to the original developer that this is what they are doing. (If developer doesn't respond well that's fine, but at least send the pm on community site).

    2) The contributor's name must be visible somewhere in the plugin coding. I recently uploaded a plugin that Matt Beckett contributed to. His name is mentioned above the function in the start.php. I also (out of courtesy) mention his name in the plugin's description on community site.

    3) Github sounds like the answer, but honestly, it's quite difficult to get it working. If anyone is planning a holiday soon, come to China and stick get github working on my machine. I'll buy you a nice chicken dinner!!! ;) Seriously though, I can't think of a better method at the moment that wouldn't require a lot of work. I'd love to see something on elgg that worked at least a little like github, but who's got the time right?

    4) If you click on the upload_plugin link and you have no plugins already, it should take you to a custom screen that lists what the community guidelines for plugins are. There are enough community members here to translate it into whatever languages we need and all would be willing to help. Stick a checkbox at the end saying that user agrees to terms. Then go to upload plugin form page.

  • Thanks, indeed.

    If modifications to the repo are an option, we could open up plugins, so that anyone can upload new releases within the existing plugin. Plugin description stays same, releases uploaded by the original developer are official, all others are unofficial. Users willing to download will be warned (similar to recommended releases) that the release is unofficial. Additionally, recommendations/likes for individual releases could be implemented.

    It would also help having two additional elements within plugins (I guess where I am going with all this is that plugins should function like groups):

    1. Pages can be contained by the plugin - authors could add a wiki/documentation, whereas community members could add tips

    2. Development Discussions - unlike comments, these could be threaded and address specific issues, where everyone can contribute.


    If all the above is not an option:

    1. Attempt to contact the original author. Ensure GPL terms are fulfilled.

    2. Add credits.txt to the plugin root and list contributors (the question is does it make sense using aliases?)

    3. I prefer svn and working with git is a nightmare. For as long as there is a decent discussion forum (not paginated comments here you can't follow a chain of thought), we will be fine. The forum can serve as a micro-level trac (guidelines should be visible on how to report bugs).

    4. Disable user plugins by default. Give user a choice to activate the repo and 'become a developer' after agreeing to terms.


  • How about plugin takeover? If a plugin has a issue or is outdated, we can set a timeline for quarantine period.

    A developer ask for a takeover in a plugin. If the plugin has isssues or is outdated, the takeover process begins.

    1. Contact the plugin´s author and wait for response: Wait 15 days (Example, ok?)
    2. Inform the community that the plugin is in a taking over process: Wait 15 days. Other developers can contribute with the code.
    3. Give temporary access to the new developer, taking over the repository: Wait 3 months.
    4. After 3 months, give permanent access to the plugin´s repository.

    A similar process exists in Drupal community. I dont know if works well, but seens to be a good idea.

    There are good plugins here compatible only with 1.5, created from users that gone away ages ago.

  • A note: Ismayl´s suggestion, allowing "official" forks with a warning in plugin´s repository is a good and versatile idea!

  • Yes, expanding the plugin repo to work more like groups would be a hugely beneficial system.

    I honestly don't wanna work with github or svn. I would rather have a "simpler" system within the elgg framework to do this kind of thing. At the end of the day elgg is fully flexible enough to deal with what github or svn does. I'm not saying let's build a replica of those websites, but we could certainly get a basic concept running without too much difficulty.

    official/unofficial releases are a great idea. All within the plugin's "group". 

    @all: I believe Ray J means unofficial forks.

    The above mentioned concept would also make things a hell of a lot easier to find.

  • 1.  I agree with Trajan, the developer should be contacted before someone even starts on a fork for a bugfix release.  If it's a fork to create something entirely new, that's fine, but even then a quick pm to the original developer seems like it would be polite.  The dev may just incorporate the changes immediately and release an official version with credits for the contribution.  That's a much better scenario than having multiple versions by multiple developers floating around.

    2. I'm not picky about how you go about giving credit to contributors, as long as there is some recognition (thanks for the mention, Trajan).  A contributors.txt seems like the least intrusive way to list contributions.

    3. Ismayils idea of some sort of wiki/discussions that are on a per-plugin basis would definitely be worthwhile.  I'm still not a fan of random forking, but abandoned plugins should have some system to allow for takeover.

    4. There is documentation for such things as expected coding practices, and the example plugin tutorials.  Somewhere in there should be a link to the community best practices.  Also, although I'm not sure about requiring people to necessarily click through it like a EULA, having it on the plugin upload page somewhere is also a good place.

  • About sending patches, I contacted the Ip Tracker developer (Slyne?) asking for changing a few lnes in their plugin. In two days he released a new version with my requests. Its the correct way.

    Feel happy to see that the community is envolved in making a better ELGG.

  • Duplicated versions of the plugins is going to confuse many users. So the users can contact the actual developer to upload a corrected version.

    The individual plugin page can have a section where other users can upload their corrected/improved version, which will be visible only to the plugin author. The plugin author can review it and approve so that it will be available as a latest release.

  • @Purus: Hmmm, like a github without github. :)

  • @purus and what if the plugin owner no more come online or look after his plugin?

Feedback and Planning

Feedback and Planning

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