Announcements

Forum: Plugin Enhancements

  1. "I was a genuinely nice person before I joined this community"
    Join Date
    May 2010
    Location
    Austria
    Posts
    3,273

    README: Procon Plugin Policy

    Procon Plug-in Policy
    Revised: February 24, 2013

    These guidelines apply to all existing and future Procon plug-ins (as well as all current and future version of Procon) to be released and/or distributed via the Myrcon website or forums. Existing plug-ins must be adapted to this policy within a reasonable time frame or will be removed from official channels. The Myrcon team reserves the right to change these rules anytime with a notification to plug-in authors within a decent time span beforehand. Failure to comply with this policy will result in removal of the plug-in from Myrcon’s official channels.

    This set of guidelines are not meant to to discourage or prevent people from releasing plug-ins or receiving money for their work, but to serve as a set of rules to ensure quality of code as well as fair rules for all developers within our community and the official Procon forums. If a plug-in author does not want to abide all points of this policy, he is still free to develop and publish his plug-in, but will not be granted permission to distribute it via official channels.

    Although we try our best to review all plug-ins and/or patches, we highly recommend that you take all precautions yourself, such as reading the comments made by others and/or the source of the plug-ins themselves. Myrcon cannot be held responsible for any harm caused by third-party code.

    If you encounter any problems (e.g. malicious code, uncredited copying of code, etc.) with a third-party plug-in or find a violation of these guidelines, please contact a member of the Procon team immediately.

    1) A plug-in author must provide a stable release (no obvious bugs that block usage or testing) of his or her plug-in, which includes basic features and can be used to test the plug-in on a Vanilla server before purchasing it.

    Examples of features that you could restrict from the free version:

    • Battlelog stats querying
    • Support for DLC
    • Advanced sorting methods (e.g. stats based vs random)


    2) A clear statement what the payment is expected or is required.

    Examples:

    • Providing a download infrastructure
    • Programming work
    • Other (extra) efforts


    3) A clear determination between "donation" and "payment" must be present:

    • "donation" / ”freeware plug-in”: a donation is a voluntary support for the plug-in author (not required to acquire the full plug-in)
    • "payment" / “payware plug-in”: a payment is required to acquire the full plug-in. This should furthermore be distinct into:
      • “pay as much as you want”: The user can decide which amount he wants to pay for this plug-in (any amount will be accepted to acquire the full plug-in)
      • “pay a minimum amount”: The user must pay a given minimum amount (or more) for this plug-in (paying the minimum amount or more is required to acquire the full plug-in, everything above the minimum amount is a “donation”)


    4) All initial releases of a plug-in must be posted in the “Plugin Approval” section of the forums and will be checked by the Procon team prior release for distribution. This practice shall prevent abuse of our community (e.g. through distribution of malicious code) and help us check the compliance of the plug-in author with our guidelines. All further updates can be published directly to the plug-in’s thread in the official “Plugins” forums. To prevent the distribution of unchecked plug-ins and/or “payware” plug-ins (see below), each user will just be able to view his own threads within this forum. This also applies to “freeware plug-ins”.

    5) A plug-in author must provide a fully working copy of his plug-in (without any restrictions) to the Procon team for free (for internal testing and evaluation/checks). This copy must also be posted within the “Plugin Approval” section.

    6) Support for a "payware" plug-in will just be provided by the plug-in author (and/or author-chosen community members), no additional claims for assistance towards the Procon team exist.

    7) A clear statement of who the plug-in comes from, be it from an individual and group, is required. If you got inspiration or code from another author, you must credit them in the description. Failure to do so might result in the removal of your plug-in from our forums. This also applies to “freeware plug-ins”.

    8) A plug-in author might post a prototype of his plug-in within the (hidden) “Procon Plugin Tests” forums. A certain amount of users (“Procon Plug-in Testers”) will have access to those hidden threads, allowing a private test without releasing an unfinished and unchecked plug-in to the public. This also applies to “freeware plug-ins”.

    9) Once a plug-in has been approved and was moved to the public forums, a plug-in developer can release updates to the public thread directly without having to complete the approval-process again. The Myrcon staff will take “random samples” of plug-in updates and check it for malicious code or infringements to this policy too, we cannot check every single update of every plug-in though. This also applies to “freeware plug-ins”.

    10) Please try to keep the functionality of your plugin as restricted as possible while still having enough features left to be useful. In other words: don't try to write a "jack of all trades" plugin, but split the functionality up in a multiple plugins or leave this up to other plugin authors. This helps both reducing the load for Procon (having one plugin to run all functionality is more error-prone, results in worse performance for the Procon layer and provides a single point of failure) and gives other plugin authors the opportunity to tune in too and provide some smaller plugins to start with.