Approval Time...

That's not a bad idea, maybe add a bit more feedback to the awaiting approval message too ? Something like the position of the file in the queue would be cool.

Although a priority queue is a great idea, I feel like there will be too many people who go "Oh hey I fixed a minor bug that effects windows 98 server users i better put it in the priority queue because this needs to be fixed asap" when that obviously isn't a pressing issue. What happens when I want my plugin approved fast so I put it in the emergency/priority when it's not?

Exactly what I mean, only in better words If I really want my plugin approved I just DDoS your home network. Same effect, right?

You guys seriously decompile and scan each line of code manually? Holy shit. I hope you guys get paid well.

*thanks*

My file has been waiting for 19 hours

Go to sleep, then when you wake up you will see it approved*

The staff arnt' robots.

* stays up all night making plugin and preparing for release
* submits file, goes to bed
* sleeps for 18 hours
* wakes up
* file still isn't approved.

Except for @h31ix

But you hit the nail on the head: patience is the key.

Where are the messages from the files that got approved within 10 minutes

@asb1230, Btw if you (or anyone else) gets a message saying that their plugin is approved form a BukkitDev Staff.

It would be nice for you to say thank you, They took the time to review your plugin in record time so show some appreciation for the little orange guys. ^_^

BukkitDev staff is absolutely amazing! I didn't mean to complain; I wasn't aware that you guys do this on the side! I thought for sure you did this for a living! You do such an awesome job! Thank you!

The BukkitDev staff do alot for us here and we all should thank them instead of complaining about the wait times but i would like to see some sort of queue maybe one that shows other plugins waiting to be updated before yours or just a number of how many projects are in front.

Maybe I should mail them a cookie?

i do that all the time. When the orange big boys (blue border people on dev) accept my project i usually go "OMG TYYY!!!!!!!!!!!!! I <3 YOU TYYYYY!!!!!!" then i stop in case they get annoyed and resulting in "THE BAN HAMMER HAS SPOKEN"

I always appreciate thank you messages, however ridiculous they are

XD. I Always type the thank you messages out every time just to show how much i <3 bukkit dev's (no homo intended).


I always keep thinking that ill get a message when the new file is approved so once i waited for a week and i was about to rage. I went back to check on my project and it had 100 downloads and i was like WDF?? then i look at the files and it says "uploaded/accepted 5 days ago" *facepalm*

Out of curiosity, does the size of the plugin effect it's place on the queue? Eg, CraftBook is a zip file full of 4 plugins, that all need to be checks every update, so does that make it lower priority?

Nope they are sorted by submission time and we generally work from the top down (oldest first).

Okay, is there any moans of annoyance when a plugin like CraftBook is seen in the queue? XD

Not really based on the size. The others probably have things they don't like, the only thing that makes me moan is 40KB plugins that have just one 5000 line .class file

I'll be sure to send some more then!

Thank you :cookedmeat:

@md_5
You tagged me on dev-bukkit about it too, but I am starting to wonder: How can I make the approval-people's lives easier? In other words: What do they prefer for code style to make approval easier?

• Does including the actual source code with javadocs help? Or do you ignore those?
• Do proper function names and class hierarchy help? Or do you just look for malicious statements?
• Between updates, do you look at a changelog between the two, or do you scan the entire plugin over again? Maybe looking at a changelog (or generate a change log?) is faster, if you didn't?
• Dependencies (BKCommonLib in my case) are scanned over again as well? Or do you compare it to previous (compare hash or size) and ignore it if it isn't the case?

With you I mean the one validating the plugin.

I am going to add BKCommonLib as a separate download location, and I will try to make it as stand-alone as possible, with (in)compatibility warnings if needed. I understand that scanning BKCommonLib (which is 191 kb now...) is a huge pain to do over again all the time. It has tons of classes...

@bergerkiller, Good question.

@bergerkiller I can answer those for me but I think we all do things differently.

• I usually ignore them, it would help if there was a method that made no sense but tbh I doubt I would ever look at the comments.
• Yes ! That helps massively. The review process is essentially looking for malicious statements, but there is no fixed size list of those so you have to at least roughly understand the code to see what it's doing and if it has a good name that helps.
• If I reviewed the previous version I sometimes have a quick look over the new one and then decompile both versions and check the diff in more detail. It depends on the size, a lot of plugins are under 50KB and for those it's not worth the effort of downloading and typing the terminal commands. A lot of the time people will release an update that corrects a typo or something so for those the diff is just one line which makes it very easy.
• Pretty much depends on the size, if it's small enough it's easier to go over it again. For your BKCommonLib I have a .txt file that contains the size and MD5 hash and a script which compares the file in the current folder to those.

@Jacek
Aah that helps a lot!
Anyhow, I am going to clean up/refresh all of the methods and fields in BKCommonLib to make slightly more sense. For example, 'stage' becomes 'lerp', as it is actually linear interpolation, and not even sure if staging is a valid term. I will be moving most 'common' functions to BKCommonLib, which will make it easier for you to check things of course. Instead of having to read ~6 new lines of code I added, you would see a single function call like 'getAttachedBlock'.