Creating & Maintaining a Resource

May 4, 2017
Creating & Maintaining a Resource
  • Creating & Maintaining a Resource



    This article expresses only the personal opinions of the author.
    For information on the official plugin rules, and creating your own resource, see this wiki article instead.
    1. Choosing a name
    Choosing a name for your resource is something important. It will also be the name that shows up on the "Recent Threads" or in the resource section. Advised is to choose the same name as the Jar file you are uploading. This way server admins can easily find the plugin when they want to update it. If you have a premium plugin most developeres tend to add information like sales, ... in the name. This is something you can do but make sure the name does not become too long because keep in mind that the thread name will always end with the prefix [PAID] what makes it longer as well).

    Make sure your name is unique, it helps to identify the plugin. Examples of something that can be confusing is this:
    [​IMG]


    The name should reveal what the plugin does or what the main features are without being too long.

    2. Choosing a version format
    Choosing a version format is also something very important. A version should be simple Major.minor.release format. Using the upload date as the version is not recommended as it can be hard to identify mayor or minor changes. Make sure to keep the same format on every update.

    2.1. Major
    The major version should only be changes when you rewrite most of the code. In most cases you should rarely change it. Examples would be:
    "You have a simple plugin that sends titles that you made for the protocol hack, you want to upgrade to full 1.8 but not support the protocol hack anymore". Take Minecraft as an example: the Major Version (1.X.x) should not be changed unless major aspects of the game change (for example, you no longer make progressbby mining, hunting, farming, etc., but through completing quests).

    2.2. Minor
    This is when you add new features

    2.3. Release

    Increase this when you have bug fixes.

    2.4. Build
    Should not really be used, usually used when you for example compile with another api version without changing anything or if you clean up your code without really fixing or adding anything.

    3. Posting a new resource update
    Resource updates are only useful when you clearly mention what exactly is changed. You have to uncover the good (new features) and the bad (fixed memory leaks or other bugs) that occured in previous versions.

    Server admins usually do not update on every update you post so the update description is an advertisement for people that downloaded your plugin to convince them to update.

    That being said, it is advised to bundle updates. Even if you have a lot of changes spread between various versions server admins are more tempted to update when there are a lot of changes.

    Also, you cannot push "empty" updates (aka uploading the same JAR without any changes, just for the purpose of "bumping" your resource to gain downloads). This is forbidden and the Spigot Staff may take action against you or the resource, especially if it is a premium plugin.

    3.1. Update title
    The update title should contain the version number. The reason for this is because the "Updates" and "Version History" tabs are separated. It is hard for a server admin to know what version corresponds with an update. You can also add this to the description, but posting it in the title will allow it to show up 'nicer' on the main plugin page.

    The title should also contain a small and short description of the changes. 'Bugfixes' (without writing what bugfixes. 'New command' (without writing what command), 'New placeholders' (without writing what placeholders'.

    Example:
    [​IMG]


    3.2. Update description
    The update description should go into detail of the actual changes. To keep the formatting nice it is advised to use lists. Keep in mind that updates will contain a Read more... button, so make sure the main features/information about an update is located on the top.

    [​IMG]


    4. Resource description
    Resource descriptions are something that has to convince the member to download/buy the plugin without having the need to test it. It should contain screenshots (so they can see) or animated gifs. Video's are also advised but make sure the video is about your plugin and not something that is similar to your plugin. The longer and detailed the description is, the more "professional" the resource will look.

    4.1. The head
    The head of the plugin should be something eye catching. A logo is good but not required.
    It should be wise to put information like:​
    • Compatibility with server versions
    • Compatibility with other plugins
    • Test server
    • Possible bugs users should know about
    • A slogan or a "catch-phrase"
    Just things that would be hard to find in your description and can cause plugin users to complain for things that they just did not see.

    [​IMG]
    [​IMG]


    4.2. About
    Tell about your plugin. What does it do, why do you think it is useful, what are the features, where could it be used for. This should be the largest section of your description. You should not go into detail about permissions, commands or configuration yet.

    If you are selling a plugin it seems wise to create an "About me" convince the possible buyers why they should buy a plugin from you. Why have you started the plugin, what use they could put it to.

    4.3. Permissions and Commands
    List all your commands and permissions. Provide information about what the permissions or commands do, who can default use the permissions/commands, ... .

    4.3. Configuration
    Explain how to configure your plugin. Even if you have made a detailed description inside your config it is still advised to show:​

    • The steps you have to take to configure the plugin
    • The default config they can use as reference without first regenerating the configs
    • Possible examples (And the results)
    4.4. The footer
    Both the header and footer are the things most members will notice. Put instructions for reporting bugs in here or some final things you would like to say before they buy/download your plugin.
    [​IMG]

    [​IMG]



    5. Support and responding to critism
    Supporting a plugin is important, not everyone knows how to use the config like you do. To avoid communication problems make sure to ask for:​
    • Error stacktrace
    • Server version
    • Plugin version
    Be friendly, think before replying. Your plugin downloaders might not be friendly but that is not a reason to be unfriendly as well. Calm down, drink some English tea and then respond. Same goes for reviews, reacting bad to reviews (Even if it is the fault of the user) will not help you remove that review or 'hiding it'.

    First contact the user ask them what is wrong, maybe eventually solve it and ask them to change the review (if it was their fault) or create a new review about an update you made (in case it was indeed a bug).

    In some cases the users post a bad review for something that is clearly described or they do not want to reply to PM's asking about the problem (even after months of bumping). In that case you can always report a review, but do this wisely and always try to talk to the user first.

    Try to keep track of problems and list them in your description as FAQ's or make your configuration/installation more descriptive.​
  • Loading...
  • Loading...