Dev Contributing Guide#
Note to new contributors#
When you contribute to this project, you are subject to the Code of Conduct. Any violations of the Code Of Conduct will be handled as stated. Read the contributing guide. Support is not given if you didn’t bother reading the documentation for setting up any of the requirements, or if you didn’t bother to read the contributing guide.
Before Starting#
Make suer to read these guides listed below (read them in order):
Coding Style#
Variables#
Aimiko uses the PEP8 standards. So any variables should be in snake_case.
See this on an introduction on this style.
Formatting#
Aimiko uses pre-commit hooks to format all of the code. Make sure run git add --all before committing to add all of the files. More than likely you’ll need to commit twice due to the formatting that pre-commit does afterwards. Pre-commit hooks are also ran on every PR except Dependabot updates and merges into the main branch.
Docstrings#
Just like how major programs are documented, the libraries that are custom made for Aimiko also have to be documented. The current standard for this project is to use Google’s Docstring Guide. A handy VS Code extension that should be used is the autoDocstring extension. By default it will generate the docstring in the Google format. Docstrings should be used on all coroutines and methods (excluding cogs), and on classes as well.
Google, Numpy, and Sphinx docstrings are also supported for commands. Aimiko is documented w/ Google docstrings, so please make sure to use that format.
Example Cog:
import discord
from discord.ext import commands
from discord.ext.commands import Context, Bot
class MyCog(commands.Cog):
"""An example cog for demo purposes"""
def __init__(self, bot: Bot):
self.bot = bot
@commands.hybrid_command(name="hello")
async def myCommand(self, ctx: Context):
"""This is an example of a description for a slash command"""
await ctx.send(f"Hello {ctx.user.name}!")
async def setup(bot: Bot):
await bot.add_cog(MyCog(bot))
GitHub Contributing Guidelines#
Issue and Feature Requests Reports#
If there is an issue or a feature you want to be added, use the built-in GitHub issue tracker or open up a forum post within the #server-suggestions channel.
If submitting a issue report, follow the template. Duplicates will not receive support
If submitting a feature request, follow the template as well. As with issue reports, duplicate requests will not receive support
Git Commit Styleguides#
If updating any other files that aren’t project files or not important (stuff like README.md, contributing.md, docs, etc), add the [skip ci] label in the front
With each new commit, the message should be more or less describing the changes. Please don’t write useless commit messages…
If releasing tags, have it in this style.
Release: v[version number],Update: v[version number], andFix: v[version number]. Release is a major release. This means it bumps from 1.0.0 to 2.0.0. Minor means it bumps up the version from 1.4 to 1.5 for example. And fix just applies a patch, which would be 1.4.1 to 1.4.2.