Shirakumo

Development and Conduct Policies

General Conduct

In general we expect you to be respectful of team members, outside contributors, and other discussion participants, even if they are not affiliated with us in any way. This includes but is not limited to:

  • Be empathetic and kind.
  • Consider alternate viewpoints or solutions.
  • Avoid pressuring team members into action.
  • Think about problems in a broader context.

In particular, the following are bannable offences which will likely get you immediately removed from all of our discussion forums:

  • Racism, homophobia, or other kinds of hate speech. This includes using icons, images, or avatars associated with hate movements.
  • Right-wing/conservative rhetoric.
  • Sexual advances and comments.
  • Intentional trolling and inflammatory behaviour.
  • Pornographic or illicit material.
  • Otherwise illegal content under EU law.

If you feel unsafe or threatened by another user in one of our discussion forums, please reach out to Shinmera or write us an email at shirakumo@shirakumo.org. If your issue is with Shinmera herself, you may also reach out to any other team member.

Large Language Models

Any code, art, documentation, or other kinds of contributions made fully, or in part, using large language models or generative models operated by or trained by third parties (such as OpenAI, Google, Microsoft, UZH, whatever) will be entirely and fully rejected, and you may be subject to a ban for your attempt at doing so. If you do not disclose that your contributions were made with such tools you will be subject to an instant and permanent ban, and your contributions will be reverted in entirety. This applies even if such subterfuge is only discovered after the fact.

We are not interested in debating the use of such tools, nor our reasons for this hard blanket ban.

Code Style

The following are code style guide elements. We don't include a guide for every language that is made use of in our projects, but where appropriate we will state requirements here. None of these will be exhaustive listings of style rules, but instead note the more frequent stumbling blocks.

Common Lisp

  • No Tabs.
  • No CRLF. Always use LF/Unix-style line endings.
  • All names must be written in American English.
  • The readtable-case has to be :upcase.
  • Always use cond whenever you would have to use progn in an if branch.
  • All constants, including T, NIL, PI, etc, must be in scream-case.
  • All global special variables must have *earmuffs*.
  • All global variables must have +piercings+.
  • Always use setf, no setq.
  • Always use looping constructs instead of recursion for iteration.
  • Prefer < over > when comparing.
  • Use uninterned symbols in defpackage and in-package.
  • In loop don't use keywords for loop directives.
  • All user documentation strings must be in documentation.lisp.
  • All implementer-facing source documentation should be in comments or in sections in separate documentation pages.
  • Documentation strings should follow this format:
    Single summary line
    
    Documentation block wrapped at 80 chararcters, explaining args,
    behaviour, etc. in various sections. Sub-blocks like listings, code
    samples, and so on should be indented by two spaces.
    
    See CROSSREF (TYPE)
    See OTHER-REF