Maintainers

A maintainer means a lot of different things. There are Art Directors, Wikitainers, and regular Maintainers. Funky Stations development structure is organized to make sure the flattest possible hierarchy exists.

In order for someone to be a maintainer, they must agree and adhere to these principles.

What is a Funky Station maintainer?

A Funky Station maintainer is someone who is trusted with certain responsibilities. Different maintainers are responsible for different things, but generally, to whatever feature or service they are tasked with maintaining, come the following expectations:

  • A promise to the community that they will manage features with the best interest of the Funky Station community in-mind
  • An expectation that a maintainer will not involve themselves with administrative actions taken against community members or themselves
  • An expectation that a maintainer will discuss features with the community in a faithful and honest manner
  • That anything a maintainer creates is to the best possible quality they can provide
  • That features are discussed with other maintainers before they are fully implemented, and not just the Head Maintainer

The description is kept brief, because a maintainer does not only do things related to game code / content. There are also services that need to be kept updated, servers that need to be checked on, documentation that has to be written, wiki's that need to be kept up to date, etc. It is better to ask a maintainer directly what it is they manage / are working on.

Maintainers can also organize workgroups on their own, for features or initiatives that require a substantial amount of work.

Workgroups

Workgroups are the biggest organizational unit for a feature. Members within workgroups can be players, contributors, even other maintainers, with the appropriate Workgroup Leader being either the Author of the feature in question, or someone else appointed by the Head Maintainer. Workgroup Leaders may not even be maintainers at all, but they are someone who the Maintainers can have a discussion with about the feature in question.

A workgroup is typically formed after a design document that is PR'ed to the Docs repository is accepted by the Maintainer team. Otherwise, Workgroups are organized by Maintainers.

A Workgroup can be made up of hundreds of people, or made up of one.

A Workgroup can also have positions within them, so long as they are approved by the Workgroup Leader.

Workgroup names are typically "[name of feature] Workgroup." For example, if someone was working on the Xenobio design document, the workgroup for that would be the Xenobio Workgroup.

After a feature is considered complete, the workgroup may continue to exist or be disbanded by the discretion of either the workgroup leader, a maintainer, or the Head Maintainer.

If a feature is considered abandoned by a Maintainer or the Head Maintainer, work may either be picked up by someone else who is interested and makes the appropriate contact to the Maintainer, or by a Maintainer. Otherwise, the feature is considered dead, and work is archived.

A Maintainer or a group of Maintainers may choose to sponsor a workgroup and offer guidance and support to a specific feature.

PR Review

Any Maintainer can review a PR for quality, although not every Maintainer can speak for the features involved in a PR. Maintainers are always encouraged to bring up these discussions in the appropriate Discord Chat or on the PR itself. A Maintainer is not to merge a PR unless it is labelled as a critical fix. Smaller tweaks, like balance changes, are encouraged to be brought up to other Maintainers first before it is merged, even if the consensus is just a quick "Yup" or "No".

Any Maintainer may hold a PR to not be merged unless concerns about it are addressed by the rest of the Maintainers.

Some specific reasons for why a Maintainer might want to hold a PR for review could be:

  • Worry about Quality
  • Goes against Funky Stations Design Principles
  • Code and/or Assets may not be properly attributed or stolen

Feedback given on a PR must be addressed with the same level of care given by the author. Focus on the content of their PR when giving feedback.

Who should get involved with a PR

  • The Art Director(s)

They are in-charge of making sure art assets in the game are consistent. A PR may be denied because the art involved may not be up-to-standard.

  • The Wikitainers

They are in-charge of making sure that features are properly documented, and a big enough feature that lacks guidebook documentation or other such documentation will need to be shared with them.

  • Regular Maintainers

A standard Maintainer will check if code or content added in a PR is squared away and given the proper accreditation.

Stance on AI

AI being used to assist programmers with formulas or other such things is allowed. Disclosing that you used AI for said PR is encouraged.

No art made with AI is to be merged.

No music made with AI is to be merged.

Features built with a heavy reliance on AI are not to be merged.

Changing Policy

This policy can be changed at anytime by the Head Maintainer. The Head Maintainer will inform other Maintainers in a timely manner about when these changes are made (typically within a day.)