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?
  • It was just a thought to work upon. Lets hear better solutions.

  • @Purus: I agreed with you, sorry for my smile. :) Its better than github. (I use github, but is confused)

  • It is a complex issue.

    I don't like the fact of seeing some random 'forks' claiming to fix a plugin. Coding takes time. Instead of timeframe may be having a "Request to fork" button that, if the request is accepted, will allow you to release a new version.

  • @rjcalifornia what if the owner no more on elgg and that request will stay pending for the whole life. yes if the owner do not accept or reject in some specific time the request should automatically accepted. but the plugin ownership should not be changed ....

     

  • @imoni: it should never be automatically accepted. If the deadline set on the system for requests to be accepted/declined for forks, notification should be sent to a site administrator who can then manually make the decision.

    Deadline set at a month (for example), I'm on holiday for a month/in the hospital for a month, come back and find my plugin has been forked without my approval...I don't think so.

  • I agree.  Although, we do have to remember that all of our plugins are being released with some sort of GPL type license and legally/actually we can't prevent people from forking.  We need to keep that in mind, and some people are going to do what they want anyway, but we want to reach a consensus on "community etiquette".

    Correct me if I'm wrong, but it seems we so far have consensus on a few things:

    1. It's considered poor etiquette to fork, or patch & release a plugin without first (attempting) to contact the author
    2. It's better to contribute patches to the official plugin, than release a forked version, if possible
    3. It's considered good etiquette to acknowledge contributors/contributed code to a plugin
    4. It would be beneficial to have some sort of built-in collaborative features for plugins on the community site
    5. We need to come to an agreement on a standard definition of an abandoned plugin, and some sort of criteria to allow for a change of ownership should someone want to pick up the project.

     

    I've been working in Drupal lately, and they have a tagging system for the plugin owners.  They can be tagged as "Actively In Development", "Actively Maintained", "Minimally Maintained", "Looking for new maintainer", "Abandoned"

    If we had something like that we could make specific suggestions, eg.

    If it's in development, or being maintained, definitely submit a patch to the dev

    If it's looking for a new maintainer, talk to the dev, and if you want to take it over, go for it.

    If it's abandoned, contact an admin to take over the project

     

    Of course you're going to run into cases where a dev just vanishes but the plugin is still tagged as actively maintained, but in most cases I think that would clear up ambiguity to the point where people aren't having active plugins forked unnecessarily.  In the case of a vanished dev, we should come up with some criteria to follow and have it be partially up to the consideration of admin?

  • I agree with the 5 points that Matt listed. If that is the consensus, we can add them to page on the site. Then we can direct new developers to read them as needed.

     

  • They can be tagged as "Actively In Development", "Actively Maintained", "Minimally Maintained", "Looking for new maintainer", "Abandoned".

    This is what we need to identify the current involvement of users. Good point. :)

  • We need that the last version launched be visible at the plugin repository. Not only the new one but the old too that contain a new version.

Feedback and Planning

Feedback and Planning

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