[REJECTED] Xeon_cogs

Applications
#1

Discord Name:
@xeon.__
GitHub Repository (Must be V3):

Description:
Cog to track vouches for specified users with specified roles. Listens for pings in specified channel, sends a message confirming the vouch, and has a simple leaderboard command. Admins can add or remove vouches & configure what role(s) to track in what channel(s).

#2
#3

xeon_cogs

  • Repository Review: Avexiis/xeon_cogs
  • Commit hash at time of review: 347f295af50d3d5caaef5ecd6a341f860261b285

Hi xeon, thank you for your patience whilst I reviewed your repository. If you have any queries about this review, please send me a message on Discord.

General Comments

Repo wide info.json

The info.json file located in the root of your repository contains keys that are only valid for cog JSON files, not repo-wide.
Please read here for more information about the format for info.json files.

EUD Compliance

Your single cog is missing elements required to be fully EUD compliant. Take a look at the given examples below:

Inside your cog class

This will handle logic for deleting user data when requested. Implement user/member data clearing as necessary.

    async def red_delete_data_for_user(self, **kwargs):
        """Nothing to delete."""
        ...

Inside info.json

Along with the other keys, this key should disclose whether, how and/or why, data is stored about users.

{
    "end_user_data_statement": "...",
}

Inside __init__.py

This will retrieve the statement from info.json and store it inside the __red_end_user_data_statement__ identifier.

from redbot.core.utils import get_end_user_data_statement

__red_end_user_data_statement__ = get_end_user_data_statement(__file__)

Review Comments

  • All of your commands are missing doc-strings. The doc-strings should provide a help message to the user so that they understand how to use the command as you intend for them to.

  • setvouchchannel and setvouchroles should probably be put under the same command group (i.e. vouchset) to avoid cluttering and improve UX.

  • L2 - The checks module is deprecated, all of its methods are available through the commands module instead.

  • L5 - The cog class is missing a doc-string. The doc-string should provide a basic statement on what the cog does.

  • L8 - You should pass force_registration=True to Config.get_conf.

  • L76 - You can directly use the member.mention property instead of <@{member.id}>.

  • L95 - This is not an appropriate way to get roles from the user. Instead, you should use an asterisk *, which will consume multiple arguments for the given parameter.

    # Instead of...
async def setvouchroles_command(self, ctx: commands.Context, role1: discord.Role, role2: discord.Role = None, role3: discord.Role = None, role4: discord.Role = None, role5: discord.Role = None):
  ...
  
# Try this:
async def setvouchroles_command(self, ctx: commands.Context, *roles: discord.Role):
  ...

    In this case, roles will be a list of discord.Role objects. If you only want 5 roles, you can do a length check (if len(roles) != 5: ...)
    or you can slice the list to encapsulate the first 5 only (roles[:5]).

Decision

Unfortunately, I’ll be rejecting this application, as it does not meet the requirement of including a cog (or collection of cogs) that demonstrates a sufficient level of complexity to show an understanding of common cog development practices. You’ve shown good knowledge of Red’s Config API, and you have a clear understanding of hybrid commands. However, there are several highlighted points that need refinement to meet our standards for approval.

Please consider reading our guide for developers who wish to submit their repositories for approval status. Compliance with more of these points may stand you in good stead for your next application if you wish to re-apply.

Feel free to submit a pull request to our indexing repository if you wish to submit your repository as unapproved. Unapproved cogs do not go through the formal review process and are used at one’s peril.

#4