Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Bounty management
How to set up and value bounties.
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.
That'll be a thing at some point !
Info for SS3D management staff.
Documents relating to the management team.
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.
Devblog creation process.
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):
Monetary management
This document outlines our projects income and costs.
(add more to this document later)
Any money being RECIEVED by the project.
Patreon - subscribers.
PayPal - direct donations.
YouTube - not set up yet.
Our current income sums up to about $50 per month.
Any money being SPENT by the project.
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 Bounties page for more info.
John's Salary - We are currently paying John $100 a month for putting is the amount of effort he is, especially considering the latest rework.
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:
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.
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) :
Major rework : Heavy changes on an existing system, full reorganization, significant boost in performance/readability/re-usability.
Major feature : Adding some lengthy and complex classes/struct/prefabs, complex methods.
Minor rework / Minor feature / Major fix (30 dollars) :
Minor rework : Changing a chunk of an existing system, a few classes/methods.
Minor feature : Changing a few classes, adding small classes.
Major fix : Fix impacting multiple systems and hard to solve.
Minor Bug fix / Small feature (15 dollars) :
Minor Feature : Small change to existing code.
Minor bug fix : bug that doesn't affect multiple system, that can be solved in a few changes (usually a few lines).
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 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.