Guidelines for lib inclusion on Discord API

guidelines.md

There seems to be a lot of confusion regarding what exactly is required for a lib to be included in Discord API (i.e. get a channel, get listed in #info, and all the other good stuff). I've written all of the guidelines down as they were usually handled in the past and how they should be handled in the future, in my opinion. All of these are just guidelines - if you have a good enough reason to not meet a particular requirement, that's fine.

• It should support the entire documented API featureset (minus voice). You can support undocumented stuff too if you want, but the entire documented featureset is a good minimum that can be expected of everyone who cares about their lib. (This seems more overwhelming than it really is.) Voice support is explicitly not required because there are many technical and non-technical reasons to not have it.
• It should support advanced gateway features such as RESUMEs. There is a rate limit on starting sessions that penalises sending too many IDENTIFY packets, so your library should support resuming sessions. If your lib has some sort of auto-reconnecting feature (it probably should) then that should use resumes if possible; if it does not there should at least be the option to do it manually.
• REST rate limit handling is a must. An implementation of strict internal rate limit handling is a requirement for Discord to consider the library compliant, as not having it is a very good reason for them to deny compliance - after all, they don't want the API to be spammed. We're accepting Discord's stance on the issue here, in part also to protect users, since users using non-compliant implementations and getting banned for API spam have no chance of appeal. Note that there's no specific way you have to implement it, the only requirement is that your lib should not generate 429 responses, and in the rare case it does, handle it accordingly.
• It should be usable by other people. This includes having a decent documentation, possibly tutorials and examples as well. You should also be making an effort to make things like your GitHub readme have good and up-to-date information. (This probably goes without saying but your lib should also be open-source for everyone to look at and possibly contribute to your code.)
• Basic code style and conventions for the language should be followed. This is more or less enforceable depending on the obscurity of the language, but if we have a trustworthy person who knows the language/platform decently well we will ask them to review it. We will probably also have an uneducated look at your code ourselves and possibly ask some questions why particular things are done in particular ways.
• Lastly, you should be a pleasant person to work with. As having a channel for your library also includes access to the private channels we use for internal stuff, and the general trust of all new people, we will likely reject your lib if you've been particularly annoying on the server in the past.

Those are the main guidelines for libraries for languages that don't already have some sort of lib on the server. If you're making a new library for a language/platform that already has existing libs, we will be stricter during the review process and also consider the following points:

• It should support at least the same featureset as other libs of the same language. If there is already a library that covers every facet of the API and you're making a new one that only supports basic REST endpoints and gateway dispatches, we will likely ask you to come back until you've reached a similarly complete status.
• It should show some sort of difference to existing libraries. This can be anything from being somewhat lower- or higher-level to having completely different use-cases. This rule is usually handled very liberally; unless you just make a clone of an existing lib you're probably fine.

Ultimately, it comes down to an informal vote between the admins (Voltana, Danny, meew0). If nobody has any objections we will first give you a private channel restricted to the admins and you to set everything up, then gradually make it more and more public. Once that has happened you're fine to do pretty much whatever, while there's a possibility that your lib will be removed again this has rarely occurred in the past. (Don't give us a reason to!)

If all this has not discouraged you and you feel your lib should be on the server, DM me (meew0) or any other of the admins listed above with some links to and information about everything you feel necessary for the review process. While it sometimes may not seem like this, in general we're excited about anyone making an effort to improve lib diversity!

unless you don't make a clone of an existing lib you're probably fine

Shouldn't this be either "unless you don't make a clone of an existing lib you're probably fine" or "if you don't make a clone of an existing lib you're probably fine"?

You're right, fixed

• Lastly, you should be a pleasant person to work with. As having a channel for your library also includes access to the private channels we use for internal stuff, and the general trust of all new people, we will likely reject your lib if you've been particularly annoying on the server in the past.

Does that mean that my lib won't have a channel forever?

Does that mean that my lib won't have a channel forever?

As long as the admins think you aren't a pleasant person to work with, yes. I don't recall much of situations where admins changed their view too :)