These are all of the sites we use for Space Station 3D.
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).
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).
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 (CC BY-NC-SA 4.0).
For posting development tutorials, tests, new content, art, etc..
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.
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 (ress3d.project@gmail.com)
Where you can subscribe to us and donate a small amount each month. This money gets forwarded to the PayPal.
Info for SS3D management staff.
Documents relating to the management team.
Outlines our community rules and how to moderate them.
(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..
Don't be a dick
No NSFW content or other forms of degeneracy.
There are 3 distinct areas of responsibility: designing, implementation, and management.
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.
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.
An idea is placed into the design board's backlog and prioritized.
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.
Documents should be in-design at least long enough for most of the team to contribute.
Controversial pieces should be open for community involvement and discussion so that they can influence the outcome. This could be done by vote or announcement in Chat.
Once the document is complete it is put into review, where any final problems are discussed.
Any existing problems can be mentioned in the wiki document, in a separate section.
[optional] The community can vote (in Chat) on whether or not to accept the feature.
The review finishes when a majority vote passes on the decision.
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.
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.
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.
Team members decide when to move the (top prioritized) tasks from 'backlog' to 'available'.
Tasks could be moved to ensure the available column has X amount of work in it.
Any team member can assign an available task to anyone, and move the task to in-progress.
Any team member can review a task that has been completed.
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.
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.
Do NOT enable the "Install on all spaces" option in the integration menu. It will break the current integrations and mess up a bunch (made this mistake once already). Each space must be enabled individually.
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.
Do NOT modify files directly on github unless you know what you're doing! It syncs BOTH ways!
If you add another space, follow the doc here to sync it. https://docs.gitbook.com/integrations/git-sync/enabling-github-sync
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: