This really needs to stop.

Discussion in 'Plugin Development' started by Nijikokun, Aug 3, 2011.

Thread Status:
Not open for further replies.
  1. Offline

    Don Redhorse

    hmm I started that thread IIRC... let me look.. was is this one?

    well but if you look at this: you could at least have subforums for the different kind of main structures like MECH or similar and one subforum for each of the bigger and more complex plugins.

    of course there are pros and cons, but release threads which are 200 pages long and contain troubleshooting, configuration and so on information is just only CONS... no pros.. a little bit more structure WOULD help in my opinion and btw: fill isn't comming anymore... iirc this was also posted in the above mentioned thread..

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  2. Offline


    Tahw era uoy gniklat tuout??
  3. Offline

    Don Redhorse

    well as long as it is an api which can be managed by plugins and it covers one of the most important features a multiuserserver system needs ... permissions... phrase it this way... the api needs to be supported..

    otherwise we will see 2 plugins coming up... one which does x but doesn't support the bukkitperms and one which does x but does support the bukkitperms.

    honestly API's are the most important thing we should have for the most basic things for something like bukkit.. and those API's should cover: permissions, help, aliasing

    this was / is one of the biggest problems we have / had with bukkit... that we did / need to rely on plugins to cover this

    If you want to change something on the API do a pull request and make the change work for all of the users not just for people using a specific plugin... at least when the change is necessary... which is again something for debate I know..

    Fine with that.
    AARRGGHhhh.. NO!!!!!!!!!!... I don't want to change the plugin as a serveradmin everytime somebody things he can make a plugin better by adding some stuff... make a pull request... this is I'M very sorry to say an idea which is not good.
    well THAT is an good idea... like I said already before WE need API's for common things (perhaps in bukkit, perhaps as a plugin) and than people should use those API's.

    It would be best if the more common things would go into bukkit and some not so common things would be coded by TEAMs... or developers who are open for contribution or don't look at developing an API as a 1 day job..

    well I don't think the badge is the problem.. a person who resurrects a plugin should have a badge..

    I think why / when the badge is applied or removed and why / when a plugin is pushed into the released forum is the issue and that alot "developers" are not using / allowing pulls / forks because they don't want or don't know how.

    I run a lot of old plugins which are inactive but still work and are NEEDED for the server, but nobody picks them up. Some people go a long way to pick up old plugins... look into code they didn't write and make changes to it.. and some others just create a new one which does the same, but uses a different config, a different database etc..

    Every developer should be allowed to create his own plugin, but if it is only a minor change to an existing one it shouldn't be pushed into the release channel but that developer and the developer of the old plugin should be guided together to enhance the original plugin.

    So both developers have the prestige, but there is only one common project.

    hm... isn't there a saying "with high powers come high resposibilites"?

    if you are a mod you need to work... MORE... that's why you are a mod... if you don't have the time to be a mod... quit.. easy as that.

    I was a Sysop (aka Moderator) for a quite big company and posted around 400 messages every week helping people running that companies software... after I didn't have the time anymore I did quit... now I'm not a sysop anymore.. yes that did hurt my ego and I still would like to have the added features and possibilites I had at that time.. but I don't have the time to do the job correctly anymore.

    So saying that a change means more work for the Moderators is not a valid excuse... either get more or moderators who have more time.. both should be possible.

    Ofcourse if you keep everything micromanaged you can't allow that... which comes back to another observation I make a lot of times... there is almost NO interaction in important threads from moderators or bukkit staff..

    like in this one...

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  4. Offline


    @Don Redhorse just commenting on a few things that you said. Thanks for showing me the thread about the "progress" of Fill. I never saw that and now everything makes a little bit more sense. Also you said something to the effect of "resurrecting an inactive plugin should get you the developer tag". Although this probably should happen, resurrecting is an extremely vague word in this instance. Does this mean that the entire name space was changed and the latest release number was slapped on (absolutely no real code changes). Or does this mean that nearly everyone except for the core concept of the plugin was recreated? Chances are, it is somewhere in between. Do you have any recommendations for drawing the line between "thank you for resurrecting this plugin, here is your badge" and "thank you for changing the namespace and compatible version number, have a good day". Also, the reason that none of this has been done (more mods, stricter submission rules, etc) is simply because nobody has had the nerve to put @[InsertUsefulPersonHere] in any of their posts. However, that is about to change.

    @Plague @ChrizC @TnT For starters, nobody is going to expect you to read the first 8 pages.

    Here is a summary of the last 8 pages of comments and the original post: Plugin developers who have made real, unique plugins are very angry because the purple plugin developer tag is now being given out to people who have "made" a plugin when in reality, it is just a repeat of an existing one or a stolen one with minor rebranding. Server owners are also upset because they need to search through a huge list of duplicate plugins and hope that the one plugin that they found will actually be a good one and that the author of it will continue supporting it (usually, developers that do the bare-minimum to change a plugin so that they call it their own cannot provide support for the plugin simply because they don't know how to).

    Around the last 2 or 3 pages, people have finally started throwing ideas on the table. Currently, the most supported one suggests using a "new developer area", stricter plugin submission RULES, and more moderators to actually approve these plugins. As a side note, if there is a problem with a lot more moderators, a mini-class called "Plugin Reviewers" could be created. The new developer area would be designed for new developers to get into Bukkit developing. people could freely post their plugins in this section, kinda like the WIP thread now, and others could critique them so that the plugin authors could get better at coding. Eventually, if the plugin dev thinks that their plugin is ready to be submitted, they can move it to the submissions section and see if a Moderator/Plugin Reviewer will accept it. This process will be far more intensive than the "correct post formatting" system that is currently in place and it will be possible because there will be a much larger group of people helping out with this. As @M1sT3rM4n suggested, the new plugin review process could be more like this:
    2. Screening process:

    -2.1: Check for related plugin​
    -2.1.1: If there's a match, compare features and if they are too similar (60%+) then reject and refer them to other plugin developer for possible fork (if inactive).​
    -2.1.2: If no significant match or if new features are so innovative that it's fantastic, prepare for release.​
    3. If accepted, release and bind the developer to a 1 month support agreement, meaning if they don't offer constant support for the plugin it will be marked as inactive (same system as now)

    This, in conjunction with the "new developer area" would allow plugin submissions to get rejected while still allowing those plugins and those plugin developers to grow and learn.

    Any questions or comments? Also, there are some other ideas floating around, but they haven't caught on as much.

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  5. Offline


    I don't have any answers for anyone at this time. The simple rules for getting the plugin dev tag is that they have created a plugin that is being used. I will bring it up with the mods/team and see if we should change this criteria.

    As for plugin overlap, I do not see this as necessarily a bad thing. I have often found I would prefer to use plugin X over plugin Y, even though the features seem very similar. Maybe plugin X has a more active dev? Perhaps plugin X doesn't cause compatibility issues, or require additional plugins to work. While we definitely reject blatant plugin rip offs, I'm not convinced rejecting similar plugins is a good idea. That being said, I understand this may lead to confusion over which plugin to use. We will discuss this matter as well.
    Don Redhorse likes this.
  6. Offline


    The issue is, and I've been saying this for a long time now. BukkitPerms doesn't support what I need. It doesn't have builtin groups, it doesn't have builtin prefix/suffix or option nodes etc. If I want to utilize these features I have to hook in alternative plugins already. Why would I switch when the API doesn't support what I need and what I'm currently developing on does? It just doesn't make sense.
  7. Offline


    I saw a post where someone suggested getting rid of all the similar plugins. CommandBook and Essentials are smiliar! Oh no! Get rid of commandbook!

    No, we all know they both have their qualities, and one would prefer a plugin over another. If all the similar plugins are rid of, essentially, people using bukkit aren't given a choice. Bukkit would basically be saying: "Here, you're allowed to use x plugin to set your spawn, and x plugin to change the chat format, etc".

    The only exception I can think is Permissions. I really hate the fact there are 2 main permissions. The PermissionsBukkit and Yeti?Permissions. It's still up to the users choice on which one they want to use though.
  8. Offline


    I think the idea is to remove plugins that are downright worse than others. If plugins are competitively similar, alternatives are a bonus. If one plugin is horrid, it's a waste of plugin searchers' time.

    EDIT: Tag @TnT
  9. Offline


    As TnT said the situation now is due to the rules being set the way they are right now.

    Your idea looks good to me, but this will have to go through the staff as a whole. I for one always welcome strict plugin requirements. But having plugins do the same is not necessarily a bad thing. Maybe a voting system would be good to reduce the "searching" problem of new admins.
  10. Offline

    Celtic Minstrel

    Why do you need built-in groups? Maybe you're just blinded by what you've done; maybe you don't actually need groups. In most cases where groups are needed, you can either check permissions instead (preferably of the form group.GroupName to encourage that de-facto standard) or become a permissions manager. So, again… for what purpose do you need to know what group a player is in?

    Why do you need prefixes/suffixes? What's wrong with using bInfo? Is there a problem with creating your own prefix/suffix system just for your plugin? (Probably yes, but who knows.)

    This lack I can understand more, but… there are other ways to handle this. You could put it in your config file, for example. You could even use your config file to link each option to a custom permission. That said, in many cases this is probably an inferior method. Still... I should also add, why do you need options at all?

    I imagine server owners will stop using Permissions and switch to PermissionsEx, PermissionsBukkit, or bPermissions. Isn't that a good reason? Of course, it's not currently the case though.

    Anyway, my point is, re-examine your assumptions. You may find that you don't actually need some of the things you think you need. That said, I'm also curious about your reasons for needing these things.

    Instead of voting, what about a ranking system where someone can rank a plugin on (for example) a five-star scale? Bonus if they're required to provide a two-or-more-sentence reason for the ranking, which could give you a way to weed out troll votes.
    Don Redhorse likes this.
  11. Offline


    Please remember that this thread is aimed at changing the way that plugins are submitted and approved (please move any comments about the new permissions system elsewhere).

    Also, I like the idea of a ranking system more than voting (I am assuming for popularity) because an old plugin will have tons of votes which will always make it "first" on the list compared with a new plugin. With a ranking system, new plugins that are very good and achieve a very good rank and be "comparable" with older plugins because time is no longer a factor in how popular your plugin is. (I know the last sentence is a little misleading, but you know what I mean).
  12. Offline


    The only way I could see a system like that work, would be to only allow it to include positive votes.

    You can 'like' a plugin, for example, but you can't dislike it. The moment a negative option comes into play, users will start thumbing the plugin down just because the developer refuses to take an absurd request...or because they're just plain douchebags in general.
  13. Offline


    I completely agree with this. I think a lot of people are extremely spiteful because some developers don't always accept feature requests. I think a positive-feedback-only system is a much better option.
  14. Offline

    Celtic Minstrel

    Well, it's not a like/dislike system I was proposing. With a ranking system, a vote would essentially be a number, and all votes would be averaged. I think it's still abusable in the way you mention, but I don't think it would have as noticeable an effect as a straight like/dislike system. Still, that's why I suggested requiring votes to be accompanied by a reason, to give moderators a chance of weeding out troll votes.
  15. Offline


    @Celtic Minstrel
    1) Groups are very useful to an admin because he can just promote someone instead of assigning all the necessary permissions to someone. (vice versa for demotion)
    2) Prefixes/suffixes are technically part of a person's permissions. If you don't need them, don't use them.
    3) Option nodes make it easier for plugin devs and server admins.
    4) I'm not a plugin developer, but doesn't it make more sense to develop a plugin for a preferred permissions system that does what you want?
  16. Offline

    Celtic Minstrel

    @Wakko – Thanks, but for #1 I was thinking from a developer standpoint, so your answer doesn't really fit the question. :) For #4, I think it makes more sense to use an API you are given for the things that it's good for.
  17. Offline


    @bothofyou, try not to change the subject! ;)
  18. Offline

    Celtic Minstrel

    Sorry, I just tend to respond to whatever's there regardless of whether it's on-topic. If @Sleaker cares to move the conversation to a more appropriate place, I would be happy to follow, or if he chooses to ignore it, then I'll probably forget about it soon enough.
  19. Offline


    I'm aware that you weren't proposing something similar to a like/dislike. I was just using an analogy, so to speak. Even when it comes to 1-5 stars, the same concept applies. One way or another, people can mess up your ratio by being spiteful.

    If we're going to have any rating system, let it just be straight up 'likes'
    So if a plugin gets a lot of attention, it could get 20 likes, where as another plugin might only get 5.

    But the better one wont 'lose' its 20 likes just because one person thinks MySQL belongs in a chat formatting plugin.

    Actually, if they just displayed very clearly in the plugin list how many people have liked the main post, that would probably suffice.
  20. Offline


    I agree with the likes idea over the rating system. As you said, it prevents angry people from ruining plugin reputation. Even though older plugins will have lots of likes, it is still possible for a new plugin to take the lead if it really is better. I also think that simply displaying the number of likes that the main post got as the sort order when you search for something is a great idea. It lets popular plugins show up at the top, and it is ultra minimal work for someone to change the website to display something that has already been implemented. With the rating system, a completely new system has to be created, tested, and implemented. With the "publicly display likes" system, the only change would be displaying and ordering plugins in a search based on number of likes.
  21. Offline


    My jaw just fell on the floor. What? Customization is, in my opinion, the most important element to a plugin other than having it work.

    Maybe I mistook your meaning, but having hard-coded prefixes and so forth doesn't make much sense to me.
  22. Offline

    Celtic Minstrel

    My meaning was simply to re-evaluate whether you really need these things. Maybe you do; I can think of good reasons for options, at least. There was also an element of curiosity in wondering what he's using options for.
  23. Offline


    I agree with niji though I am looking through open source plugins and learning from them and adding more to them if needed. Being an opensource community really helps me learn and lets me see how different people code different ways. I don't plan to release anything unoriginal if I do release a plugin on here if that gives any relief :p
  24. Offline


    I've read the resumé of @Supersam654 and all comments below.

    I also agree that the plugin submission should be more restrictive. But there should be a lot more criteria than just "same features". A ranking system would be essential to make things clearer for server admins. It won't be a solution for the plugin submission.

    All developers that have some experience can quickly spot a bad made plugin. Those plugins would be thrown into the WIP category. I think this is a way to do:
    if ( post_layout_is_ok() ) {
        if ( features_allready_exists() ) {
            boolean wellmade = code_review();
            if (!wellmade) {
    The reasoning is this:
    • If your plugin has a new idea, we don't really care on how well made it is. If it really suck, either you will improve the quality of your work, either someone else will fork your plugin or built a new one with the same idea.
    • If your plugin has quite the same features as another one, it really don't matter but you will have to at least have a descent made plugin and some special features (this can also mean removing some features).
    • If your plugin has the exact same features, check how well made it is. Perhaps the other one with the same features is not so well made and thus this plugin could be a really good alternative. Encourage the formation of a team and/or forks but don't throw good work and good developers away! And if it offers the exact same features and isn't even well made or the plugin is so basic that the code is the same, move it to wip.
    All this relies on "well made" plugin which I refer with a code review. Yes this is some subjective criteria but, come on, everybody here can spot if something is odd in a plugin by just looking at it some minutes. And moving a plugin to WIP doesn't mean you can't argue with the code reviewer (everybody makes mistakes).

    The code reviewing team doesn't have to be extreme on how good looking the code is. Just refusing the noob plugins is ok. Spotting huge beginners errors isn't so hard.

    With this I think everybody would be happy. A ranking system and a more restrictive plugin submission :)
  25. Offline


    Thank you for looking at my "resume". I really want to know what you are talking about :). Also, nice way to show the devs on this thread a visual way to see your idea. Nobody has really brought up the concept of original but poorly coded. I personally think that there is a point where the plugins is just unacceptable and simply "needs improvement". I think that the quality of unique plugins should still be monitored, but I think the rules for them should be far les strict so original content can get to Bukkit users the fastest.
  26. Offline

    Don Redhorse

    hmm I would say keeping the plugin alive and enhancing it.. with FULL recognition of the original makers... we have some developers who do a good job there.. and I think they also have their own plugins.. but would need to check..

    Point is that because this is kinda a community project people come and go, which becomes a problem if other people start relying on a functionality and that functionality is done by a "onemanshow". If the person leaves some other people have to pick it up or you need to look around.

    Looking around is only possible if you let other developers also create similar plugins, a lot of the time they start at the same level but than grow and become different / better.

    Even better would probably be if those developers would agree on creating a team.. developing together and making the functionality surpass the leaving of one developer.

    I' will post something more later..

    The issue is that "you" should enhance the api.

    And with "you" I mean probably we... admins, developers and bukkit team. I'm thinking a lot about it atm (trust me) and I also found that perhaps a different approach on perms is a better way.

    I will write more about it later..

    There is one problem though... an old plugin which has a grown membership will have more / better votes than a new plugin which is perhaps better... so you need to put in aging etc which makes that very complicated.

    It could be used as a basis though..

    I will write something more later...

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  27. Offline


    @Don Redhorse You really don't have to post all your replies to people in seperate posts. You can quote many different replies in the same post.
  28. Offline

    Don Redhorse


    I said I would post something more later, here it is.

    I don't want to highjack the thread so I openened up NEW Threads and linked it here but I still want to give a short summary because a lot of it comes from this thread. Please go into those threads and don't discuss it here, especially as I only posted very tiny information in here.

    Bukkit and the plugins are great and all people concerned (developers, bukkit team, people helping in the forums) are doing a great job. But bukkit is on a rocky road and the usuability for the admin and user isn't at the point where it should be.

    Bukkit has the following issues:

    Permissions... different plugins, different concepts, complicated, error prone and shattered
    Help.. complicated, not to the point, not really translatable / customizable.
    Aliases.. Complicated and plugin specific
    Forums.. Difficult to navigate and missing structures
    Plugins.. Plugin Standards allow for to many issues

    I think the plugin issues can be discussed here but please also look into the other threads as I reference them in the following part.

    Leaving the developer tag aside, I find we have the following issues with the plugins atm.

    a) To many Plugins doing the same thing
    b) Plugins dropping into inactive status because developers disappear
    c) generic names for commands like /help, /give etc which are also used by other plugins
    d) Plugins doing more than one generic function set.. eg. teleport, warp, help, mob spawning, making coffee...
    e) Plugins supporting different pseudo standards or not at all
    f) complicated commands

    Let me explain what I mean with those points and how those could perhaps be solved.

    a) Diversity is fine but becomes an issue when it makes life harder than it should. We had a lot of good suggestions in this thread on how to make changes to the plugin release process and I would like to focus on the following.

    A 5 level approach of plugin subforums, one for approved plugins (plugins which support all the criteria of the plugin release rules), one for plugins (the released plugins forum atm, for plugins which adhere to some standards), one for un-supported plugins (plugins which are not supported anymore but still work, the inactive forums kinda), one for WIP.. (the WIP forum) and one for not working plugins (plugins which are not working anymore)

    PLUS a HELP forum where people can ask for help together with the necessary subforums... see the Forums link please for more info...

    So let's take a look at the rules.

    People suggested to not allow plugins which are the same or even to do a code review. The same plugins are ok, perhaps add the like feature already mentioned but make sure that older plugins age down or reset it from time to time so that newer plugins have a chance to get to the top .. A code review should be done only really if there is really the need for it because there is a suspectable copy job at hand.

    What is more important that the plugins adhere to a good standard:

    the template we already have
    good command syntax (e,g /pluginname function or /pluginnamefunction where pluginname can be a short like dc for default commands)
    support of all offical API's (see more about this in the Permissions, Help and Alias links please)
    dedication to support the plugin
    "customer oriented behaviour" and THAT doesn't mean to support MSSQL for chat programs...
    support forks or teamcreation of developers
    updated FAQ
    only focussing on one functionality (e.g only warp or mob handling, or world handling)
    support in the correct forum

    b) While Diversity is fine people should be guided to fork or create teams to help plugins stay alive, so if somebody creates a new plugin which function is already there and only adds one or two features, the plugin will not directly by moved to approved even if the other rules are met. New programmers should be helped / guided to pick up unsupported or not working plugins instead of just copying that original plugins functionality.

    c) e) and f) could be taken care of by having an Aliases and Help API (see the Aliases and Help links please for more about that)

    d) Plugins which only focuss on one given funtionality are easier to implement and support, especially if you run a lot of plugins. Ofcourse one plugin like essential or default commands which support a lot of functionality makes it easy to run a complete set of features but it becomes complicated when you want to use something else from another plugin. Vildaberper does use a good approach with default commands as all of his commands are customizable, so having the Alias API would make this point perhaps superfical.

    I know there is a lot off room for discussion in this statements and not all of them are without problems in itself. Also a lot of the stuff I wrote here isn't about duplicate plugins or the developer tag, but it is about the main issue the OP wanted to tackle I think...

    making it easier for ALL to use bukkit.

    Please do me a favour and read the other threads too before replying here and try to keep in the thread where it makes most sense... up to know the discussion in this thread was very good and without the normal trolling.

    hmm.. how... still learning..

    EDIT by Moderator: merged posts, please use the edit button instead of double posting.
    Last edited by a moderator: May 18, 2016
  29. Offline


    You hit the reply button, type your reply, hit the reply button on another comment, and type away. I recommend copying your text before you do this because I deleted my entire message the first time.
  30. Offline

    Don Redhorse

    ah ok.. well.. have to check if that works with autopager in chrome..
Thread Status:
Not open for further replies.

Share This Page