CentCom Member Responsibilities

There are 3 distinct areas of responsibility: designing, implementation, and management.

Preface - Terms

Repositories - Place where code & assets are stored (e.g. GitHub).

Task - A piece of implementation work (i.e. coding a piece of a feature or making an asset).

Boards - the primary board is the GitHub implementation board, though we have other boards on Trello for asset todo tasks as well as a management board.

Wiki - Repository's Wiki (this has ben moved here to our gitbook but the term hasn't been updated throughout our documents fully yet).

Chat - The official place where communication takes place, in our case the Discord server.

Responsibility - Designing

The team must collectively agree upon the features of the game before they can be implemented. Additionally, community opinion must be considered during design and designed features must be publicly viewable.

Process

1. An idea is placed into the design board's backlog and prioritized.

2. The most prioritized idea is put into in-design. A wiki document is made for it where members of the team start writing up the design.

   • Team members should not erase text without general agreement.

Permissions & Tooling

The dev board must have columns for backlog, in design, in review, and complete. The wiki must have a section for writing feature designs. The chat must have a way for team members to create votes and announcements, and team members must be able to read and respond to community voices in the chat.

All team members have permission to read and modify the board and the wiki. The public has permission to read the board and wiki.

Responsibility - Implementation

The team maintains the quality of the assets, the GitHub repositories, and maintains the boards both on GitHub and Trello. Additionally, team members can assign people to work on specific tasks.

Unlike designing, this responsibility is more individual - collective agreement is not required for many of the tasks.

Processes

• Team members (somewhat collectively) take designed features and turn them into tasks in the backlog.

• Team members (somewhat collectively) prioritize tasks in the 'backlog' and 'available' columns.

  • Available tasks are ones people can work on, backlog needs to be done but aren't meant to be worked on yet.

Permissions & Tooling

The implementation boards should indicate what tasks are available and unavailable to work on, in progress (and who is assigned to them), being reviewed, and what tasks are complete. Tasks that fail their review go back to being in-progress, tasks that pass their review should be immediately be placed in their respective repository. With GitHub, a lot of the above steps can be automated (e.g. accepted reviews being placed in the Done column). Additionally, GitHub can require PRs for tasks before merging.

Team members have permission to modify the boards, review and merge PRs to the repositories, as well as all public permissions. The public has permission to read the board and repositories, request to be assigned tasks, and submit PRs.

Responsibility - Management

The team chooses collectively who is on the team. There can be some rules relating to promotion/demotion that are generally agreed on.

• When choosing to promote or demote someone, enough time must be given for most team members to voice their opinions.

• There could be an indiscriminate demotion for inactive members after 2+ months of no development (management or submissions) and/or 1 month of inactivity in chat. If a demoted member starts contributing again, they could be repromoted again through the same process as before.

This document outlines our projects income and costs.

(add more to this document later)

Income:

Any money being RECIEVED by the project.

Income Sources:

• Patreon - subscribers.

• PayPal - direct donations.

• YouTube - not set up yet.

Our current income sums up to about $50 per month.

Expenses:

Any money being SPENT by the project.

Expense Sources:

• Website - Currently being paid for by Grimmie.

• Server - We do not currently host a server so this isnt relevent yet.

• Bounties - Bounties are how we pay/tip our developers for contributing certain tasks. See the for more info.

How to set up and value bounties.

(this document needs to be expanded more)

You can find the communities we are responsible for moderating under the Sites & Accounts page, but this also expands to all our sites including comments on our GitHub repositories, Trello boars, YouTube channel, etc..

Rules

1. Don't be a dick

2. No NSFW content or other forms of degeneracy.

Devblogs are usually made by CosmicCoincidence but this page is written so that any team member (or contributor really) can make it.

Currently devblogs are being made quarterly, but as progress picks up again we may switch back to monthly.

Simply put, the idea is to showcase all (note-worthy) contributions during a given period, but it's a bit of a process (you will need to know for this):

Our Website

Developed on our "Website" GitHub repo (see GitHub section below).

The domain name is currently owned and paid for by Grimmie (or Judge on our Discord).

Development

Most of our wiki and documents have been moved here.

The Trello team consists of all of the members of the council. In addition, some more trusted contributed have write access on some boards (e.g. Konstantin3001 has access to the 2D board).

Google

Gmail

ress3d.project@gmail.com

Used for opening other accounts and general emails.

GoogleDrive is used as a dropbox for submitted assets, which are then reviewed and prepared for use prior to being moved into the GitHub project. In addition, CentCom uses the GoogleDrive for hosting other things like artwork and documents.

All assets saved here fall under our art license ().

For posting development tutorials, tests, new content, art, etc..

Communities

Discord is the official method of communication for the SS3D community and devs. This includes posting WIP content for criticism and discussing game designs. There are also many people willing to help in various genres of game development.

CentCom members and mods moderate the Discord. CosmicCoincidence is the owner.

Reddit is for posting announcements, memes, WIP, art, etc..

Currently owned by Grimmie, and moderated by various CentCom members.

For posting devblogs and occasional funnies.

Mostly run by ProbablyNot.

Financial

PayPal is our monetary hub, all donations get funneled and recorded here prior to be distributed to project costs. When donating to the PayPal, you can use the link provided or send money directly to our email ()

Where you can subscribe to us and donate a small amount each month. This money gets forwarded to the PayPal.

Documents relating to the management team.

GitBook Backup repo

Gitbook and Github are automatically syncing, at for all of our current spaces. The syncing allow us to have a backup of our gitbook data in case of a catastrophic lost. Any space added later will need to be configured to sync.

If you add another space, follow the doc here to sync it.

When syncing another space, don't let the root folder by default, otherwise it'll make a mess on github.

Add a folder with the same name as the space you created.

For this space, here's the project directory:

Eligibility

Conditions for a task to have a bounty are :

• It's part of the current milestone.

• It must be clearly detailed. - If it's a bug, some attempt must be done to fix it before.

Bounty price

The price of the bounty will be fixed by a Centcom member, by estimating how time consuming it will be :

• Full new system (90 dollars) :

  • Implementing every aspect of a complete major system design doc.

• Major rework / Major feature (60 dollars) :

Claiming a Bounty

Anyone can claim a bounty. Bounty claimers have to show regularity in their progress to keep the bounty claim. After two weeks of inactivity (no substantial commit or change to a design doc), and if no justification is provided, anyone else can claim the bounty, on a decision of a Centcom member. One person can't claim two bounties at the same time, they can only work on one bounty task at once.

Bounty price modification

Bounty price can be modified when a pull request is ready and only upon accepting a pull request. The bounty price can only go up. As an example, if what was believed to be a simple bug fix, actually needed a major rework, then the bounty price will be adjusted to reflect fairly the work of the contributor. The decision is taken by a Centcom member.

That'll be a thing at some point !