Dev Contributing Guide#
We are glad that you’re willing to contribute to this project. We are usually very lenient and relaxed with the submissions of PRs, and Issues reports. But there are some stuff that you need to know before contributing.
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#
Kumiko follows PEP8 naming conventions and standards. To sum it up:
snake_casingfor variables, args, kwargs, and filesPascalCasingfor classesALL_CAPSfor constants
Ruff is used to lint and check whether the code meets PEP8 standards or not. In order to learn more about PEP8, see this guide.
Formatting#
Kumiko 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.
Docstrings#
Just like how major programs are documented, the libraries that are custom made for Kumiko 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. Kumiko 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 my_command(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. Though a system like Jira could be used, it would be more efficient to just use the issue tracker that GitHub provides.
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, 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.