Skip to content

Latest commit

 

History

History
64 lines (52 loc) · 6.28 KB

0010.md

File metadata and controls

64 lines (52 loc) · 6.28 KB
Raw

Cog Creator Applications

OVERVIEW

This policy outlines the process of reviewing a Cog Creator application as carried out by QA.

GOALS

  • Outline the perks of being an approved Cog Creator.
  • Outline the factors that QA will use to review a repository.
  • Outline the situations in which a Cog Creator can lose their perks.
  • Outline the process of creating and reviewing an application.
  • Outline other stipulations of the Cog Creator process.

BREAKDOWN

Perks for Approved Cog Creators

The following perks will be granted to all approved cog creators:

  • Approved Cog Creators’ repositories will be added to the approved category of the Red Index and any other listings of approved repositories.
  • Approved Cog Creators will receive the Cog Creator role on the main Red Server and the Cog Support Server.
  • Approved Cog Creators will be granted access to the #advanced-testing and #advanced-coding channels on the main Red server.
  • Approved Cog Creators will be granted send_message permission in the #v3-burndown channel on the main Red server.
  • Approved Cog Creators will be granted access to the #creator-testing and #cog-creators channels on the third party cog support server.
  • Approved Cog Creators can request a channel in the third party cog support server for their repository.

Requirements for a Cog Creator Application

QA will enforce the following requirements on a Cog Creator application:

  • Repositories must include a readme file that contains the repository name, installation instructions, any extra setup instructions, and any credits.
  • Repositories must include an info.json file for the repo, including the author, name, short, and description keys.
  • All cogs in the repository must include an info.json file for the cog, including the author, name, short, and description keys.
  • All cogs requiring pip-installed modules use the requirements info.json key when appropriate.
  • No cog may contain malicious code.
  • No cog may contain code that could impact the stability of the bot, such as blocking the event loop for an extended period of time, unreasonably high IO usage, etc.
  • No cog may contain copied code that does not respect the license of the source.
  • Each cog must disclose in the install_msg if the cog contains heavy memory or I/O usage, any NSFW material, bundles data, stores data outside of Config, has interactions with outside services, or requires extra setup instructions.
  • No cog may break the Discord Terms of Service.
  • No cog may conflict with any core cogs (E.G., causing a core cog to fail to load) unless it is intended to replace that cog.
  • Repositories must show an understanding of a range of common cog practices. This requirement is to ensure the safety and functionality of any future code created by the applicant.
  • Any unusable or broken commands or cogs must be hidden.
  • The default locale must be English.
  • The main cog class and every command must have a doc-string.
  • No cog may allow for an escalation of permissions. (E.G., a sending a mass ping through the bot without having permission to do so)
  • All cogs must respect the role hierarchy.
  • Any pre-packaged data must be accessed through the bundled_data_path.
  • Any data created outside of config must be stored in the cog_data_path.
  • Cogs must ignore input from other bots unless intentionally designed to listen to certain input from other bots.
  • Cogs must use public methods of Red over private methods.
  • Repositories must be kept up to date with the latest version of Red within 3 months of its release.

Removing Cog Creator Perks

If a Cog Creator is found to be in gross negligence, malicious intent, or reckless abandonment of their repository, the org may remove the Cog Creator status from that individual. Cog Creator status may also be removed if the org can no longer maintain a working relationship with the Cog Creator. A vote to remove the Cog Creator must be called under this policy. This vote will include all active org members and a simple majority in favor is required to remove the Cog Creator. A Cog Creator removed in this fashion loses all perks outlined in the Perks for Approved Cog Creators, including having their repository delisted from the approved listings.

For all repositories on the index, all non-hidden cogs on the listed branch need to functionally work to the criteria of an approved cog on the latest minor version of Red. This means the general functionality each cog is made to achieve must be intact when used in expected ways. Examples of breakage include, but are not limited to: a dependency receiving a breaking update, an API changing its endpoints, or when Red itself releases a new minor version. Individual cogs that are not updated within 1 month of initial breakage will be delisted from the index until they are updated. All other Cog Creator perks will not be affected by a cog being delisted.

Application Process

Cog Creator Applications must be submitted to the "Applications" category of Cog Board. Applications will be reviewed in order of submission by a member of QA. The reviewer of an application has the final word on that application. Once the reviewer has requested changes, the applicant is given 14 days to make those changes. If the requested changes are not addressed, the application will be rejected and the applicant cannot make a new one until 2 weeks after the rejection.

Other Stipulations

  • Only 1 person is allowed to be the Cog Creator for a particular repository. Multiple people are allowed to maintain the repository, however the "main" owner (and the Cog Creator) is responsible for any code on the repository.
  • The Cog Creator status for a repository can be transferred to another user if the Cog Creator requests it.
  • An approved Cog Creator can ask QA to add additional repositories they have created to the approved pool.
  • Hidden cogs will not be explicitly reviewed, however they are not allowed to contain malicious or ToS breaking code.
  • Since the org has the right to remove a Cog Creator at any point, and the org has no direct control over a Cog Creator's repo, Cog Creators can not provide association with the QA review process or services provided by the org. This includes stating that a cog or repository is "approved", or that the org has reviewed any particular code.