Suggestion Plugin Approval on Free Resources

Discussion in 'Community Feedback and Suggestions' started by john01dav, May 10, 2015.

Thread Status:
Not open for further replies.
  1. I'm recommending that approval, similar to BukkitDev, be added on free resources as well as on premium where it already exists.

    Of course, the moderators here already work very hard so it would be infeasible to expect them to approve all plugins. Instead, I suggest that some specific set of users (ie. more than 250 posts and/or positive ratings, at least 5 resources, handpicked by staff, etc.) be allowed to vote on the approval of a plugin. Once a specific number (5, for example, although almost any number could work) votes that the plugin is safe, it becomes public. Once a single user votes it unsafe, a staff member verifies (the user can point out specifics) the flaw, and if it is truly malicious, appropriate action is taken against the user who posted the plugin and the user who found the flaw is perhaps rewarded. Of course, users won't be penalized for missing a flaw and therefore marking the plugin clean because this would discourage checking since accidents inevitable happen. Perhaps if a user repeatedly misses many flaws when most others find the flaws they could be barred from reviewing more plugins in the future. If the staff member determines there is no flaw, they remove the vote pointing out the flaw and can then decide to either look through all code and approve it themselves, or wait for enough votes from others to come in.

    XenForo plugins are expensive, so no custom plugin can be made for this. However, this is not needed as the building blocks for such a system already exist and are used within Spigot. New resource posts can be placed into a separate category that is only visible to the member who posted the resource and another group. Premium resources already do this. Then, simply create a group for the list of members (use the system that gives users access to S&R to add them, if not hand picking the users) that is allowed to approve resources and allow them to reply to the thread. Once there are enough votes, the last voter can report their post and a staff member simply checks for the correct number of votes and approves the plugin while possibly deleting the posts as well. When a user marks a resource as malicious they can reply explaining why and then report their post so a staff member can take the aforementioned action, or if the user posting the resource should be kept in the dark about the flaw (ie. to prevent them from making it more subtle in an update, since updates make the previous version inaccessible (perhaps not to staff members, but I am assuming that staff members can't access old versions either because I can't think of any reason that users shouldn't be able to as well if they are actually saved)), they can report the resource or the first post in the resource's thread that is automatically created.

    The system I am proposing has many benefits. Of course, it helps to filter out malicious resources and plagiarism. Which then, in turn, helps bring more users to Spigot from Bukkit, which even if Spigot doesn't necessarily actively want more users, it will certainly help those users as we all know that Spigot (and many of it's resources) are superior software, especially now that there is no 1.8 version of Bukkit on Bukkit's website. This also helps keep the existing community safe. Lastly, it could also give staff members a good, albeit small, hint on who to pick for the next new staff member, as I am sure more will be needed as the community grows.
    • Like Like x 3
    • Agree Agree x 2
  2. I like this idea. but as you said, with Spigot being the new Bukkit and overall the Minecraft Server Software, Spigot is going to have to bring on more staff, soon.

    but what extended_clip said below me is also true.
    • Agree Agree x 1
  3. clip


    I am not really sure how I feel about this. On one hand I do like the idea but on the other I like it how it is. Depending on people to check free plugins will be more work than is needed. The system right now works and there is a report button on resource pages for a reason. If you feel the need to check every free resource for malicious content or copyright infringement than you are more than capable of doing that already.
    • Agree Agree x 2
    • Like Like x 1
  4. It certainly works, but that doesn't mean there isn't room for improvement -- there always is. I think this is one way to improve the system. Also, people don't like change even if it's good, so that may be part of the reason you're not sure how you feel about it. Yes, I could go into the resources section and start checking, but there are way too many resources for a single person to check. Having such a system encourages more users to check the resources and can prevent a malicious resource from getting on anyone's server in the first place. Lastly, a time limit could be imposed for approval time that the user who posted the resource can report their resource if it isn't checked within, for instance, 5 days. Then, either a staff member could automatically approve it or check it themselves.
  5. saphiria


    Couldn't have said it better myself. They will have to bring on more staff eventually it's just a matter of if it will be for this.
  6. It might also be a problem while evaluating who could "vote" the plugins.

    For me, I dedicated in Bukkit/Spigot plugin programming for 2 years, but I rarely post any resources here...
  7. No, it won't help at all.
    Bukkit still has many stolen plugins.
  8. Elgorond


    I believe the main point is to be free of malicious plugins.
    • Agree Agree x 2
  9. Ok
  10. I've been trying to look at newer plugins myself for malicious code etc. I like that spigot doesn't have much curation and it is up to the community to help and handle. It doesn't take much to just pop a plugin in your decompiler of choice and take a quick look at it. Although I do say for newer members to the community malicious plugins could be a big issue.
  11. Then perhaps applications manually handled by staff for a limited time (like the Wiki Team) would be best.
    • Agree Agree x 1
  12. When looking for plugins you just have to be careful. I tend not to go for plugins that have bad review but that will be the same for most people. If something looks to good to be true then it most probably is especially if they are new to developing bukkit/spigot.

    However the system is working fine at the minute I don't think there needs to be anything changed unless some problems occur. If a system doesn't come in what a random spot check where staff take a look at a plugin and see if anything malicious is within it
  14. That's definitely a good idea!
    • Like Like x 1
  15. jflory7

    jflory7 Retired Moderator
    Retired Benefactor

    Here's my own 2ยข on all of this:

    I agree that I actually prefer a system of moderation over resources being freely uploaded without any kind of approval. Sure, as we all know, even with manual approvals, things will slip by from time to time. But as of now, the best protection you have against a potential malicious resource is by decompiling it yourself to read over it. If you're not that fluent with the API or coding in general, even if you decompile, you might have no idea what you're looking at. That was always one of the benefits to uploading to BukkitDev, was that you knew a human being had read through the code before it was published, and while updates may be slow-going and at times frustrating in terms of waiting around, you would also know that while the odds of potential malicious intent were present, they were very unlikely. Basically, you wouldn't have to do the extra work to check out a plugin's true intention.

    However, in terms of how such a system could be applied to Spigot, I don't think this suggestion is the best way of solving the issue.

    For one, I think if Spigot Resources would truly go above and beyond to the next level, it would need its own independent resource manager, similar to how BukkitDev was to Bukkit. I'm not saying we would need to do the exact same thing, but I don't think our current system could sustain significant change and still be effective. I think if this were to ever be achieved, a web developer would either have to be contracted out for building an entire custom resource manager system (i.e. very expensive if it's done right) or a full-time web developer would need to be hired. At our current size, I don't think such a thing is sustainable in the long run, because if you hire out a contractor, you'll still have to pay someone to fix it and update it when things break or new things are updated, and if you hire out a full-time web developer, you're consistently paying him around the clock for what might not even be much work if the custom resource manager were running at optimal performance. tl;dr: I don't think a custom resource manager is a realistic possibility for Spigot at this time.

    Secondly, I don't believe having users handle resource approvals is a good idea either, not without the implication of them being a full-time staff member and signing some sort of legal agreement to confidentiality and/or honest intent. The best way I can think of explaining this one is an anecdote of a server owner. Let's say you run your own server that has a few hundred active players each week, and a fairly active forum. Pretend that a user suggests that active members in a community should have a partial say in reviewing potential staff members to join the team. By doing this, you introduce potential bias and in most cases, elitism as well. Personal relationships between users are almost omnipresent and seldom can they be avoided. One way or another, the personal relationship between two users could play into whether or not they leave a "good recommendation" for a possible staff member. On the other hand, elitism could come into effect if players write off someone who has joined in the past two months as "unworthy" or "too nooby", regardless of true merit or ability. In a nutshell, I think this sort of thinking can also be applied to handling of free resources by Spigot users. Ultimately, I do not think having users handle resources is a good idea because it would introduce all kinds of biases into the process, and I think it would ultimately create more work than the current system does (and subsequently reduce time spent in other important areas).

    Thirdly and finally, regarding Spigot staff itself as an entity (keep in mind this MY own personal opinion), I am inclined to agree that we do need more staff members as the community continues to grow. Particularly, I personally see a need for new Resources and Services staff to give our two already awesome moderators a hand (and possible some sleep). However, there is a lot to consider for these roles and there is a lot to it. A potential candidate that meets what could be called the basic requirements is far and few in-between.

    Anyways, this is just how I feel about this as a whole.
    • Agree Agree x 1
  16. clip


    I can say that I do go on the resources section (almost) daily and download newer plugins just to inspect them for things such as force op and other malicious content. I have reported a few and I have also pointed out obvious errors to the developers if there was something that I happened to see wrong with the plugin. I know that this is not a requirement for me to do but since I do have the capabilities to do it, I tend to do it quite often. I am sure that i'm not the only one doing this too.
    • Agree Agree x 1
    • Useful Useful x 1
  17. PhanaticD


    you are the hero not that spigot deserves, but the one it needs
  18. You (john) should learn how to make a TL;DR.

    I already suggested this, and it was eventually turned down. If I recall correctly, the reason was as simple as "that's what the report button is for". If you find a malicious plugin, report it. If you find bugs in a plugin, notify the developer.
    • Agree Agree x 1
  19. clip


    You should learn how to reply to who you are talking to because I have no idea who this reply was to :p
  20. Edited my post, it's directed at john.
Thread Status:
Not open for further replies.