Github - ss14Starlight/space-station-14 GitHub Wiki

About

Github, the platform you are on now, is designed to store software code. Both open source and closed source. Each project/software has its own licenses and rights. In this table of contents, we'll look at licenses, what PR is, what criteries of different SS14 projects can have, and a bit about how to piss off SS14 developers.

Pull requests (PR)

PR - describes its name, this is a request to pull your changes into the main repository.

how to get the PR right?

The first and most important thing to note is to read the description comments(if there are any at all). They can summarize what a particular table of contents is responsible for. I will break down the important aspects of our description point by point:

Title - the title should be simple and easy to understand. It should not be a long description. Good Pull Requests should have a short title of two or three words that clearly describes the meaning. Of course, not everyone adheres to this.
Short description - a short description, a description of what you want to contribute. Why short? This is done so that the Maintainer (Main Developer, who is responsible for reviewing PRs) can quickly understand what you want.
Why we need to add this - a description of why a meintainer should adopt your PR. If you can't explain the reason, it doesn't make sense to make your changes, there are obvious exceptions, for example: Bug fixes.
Media - as well as the short description, is designed to briefly bring the Maintainer into the essence or whoever is reading your PR
Checks - checks created to understand whether you need help from the maintainer to complete your PR, whether you have checked your changes at all (Maintainer can check everything for you, only if he has the desire and time), Media check (created to change sprites for a quick assessment of appearance) and also license check, it is designed to minimize problems from the project, if it turns out that an unscrupulous contributor took code from another project or vice versa, to confirm that your code, which you voluntarily transferred to the project, will be protected by the license.
Changelog - it is worth emphasizing the Changelog, it is created for your changes to be displayed in the game and discord of our or other project. How it is compiled will be described below.

How to design a Changelog using an explicit example

To illustrate, I'm a developer, my Ckey: Rinary, I'm adding crawl mechanics. I'm removing the auto stand up, fixing texture mapping issues when crawling under tables.

:cl: Rinary
- add: Added crawling.
- removed: Removed auto stand up.
- fix: Fixed texture issues when crawling under tables.

Explanation

Author:

the author is listed after :cl:

List of editings:

A list of changes should always contain - at the beginning to indicate that it is a list, followed by a space for the type of change, a colon and a description. Always start the description with Fixed, Added, Removed, Changed, so that the person can clearly understand what has been changed.

Basic criteries for PR design and content

The PR description should fully describe the essence.
PR should correspond to the structure of files, code, so that there is no confusion.

Explanation: The Listing prototype, should be located in the Catalog/some_catalog.yml folder
Explanation: Prototypes of objects, mobs and structures should be in their Entities/objects, mobs and structures folders respectively

Common sense, we would like to point out that this paragraph is added here to note that PR's made for the sake of “fun” will be rejected or considered with the same intention. Your PR should be designed seriously and make changes that are really necessary for the project you are doing the PR for.

Issues

Issues - act as tickets where you can suggest something new or submit a bug related to the project. Issues also have rules and criteria, this article will describe the criteria for filling out an Issue by example.

how to get the Issue right?

As with PR, Issues have comments. Read them to understand the point of each item:

Title - As with PR, the title should be short and clearly describe the issue. For example: AI actions missing
Description - Unlike the PR description, it is best to make this description as detailed and clear as possible. This means that the more clearly you explain the problem, the faster it will be solved.
Reproduction - an important point, supplementing the description, added so that Mainainter can immediately see how to repeat the problem.
Media - as in the case with PR, complements the description, in Issues any video and screenshots are much more important than in PR, because in PR you can always see the changes by copying them to your local Repo. It would also be useful to leave logs or errors.

Licences

About

Licenses in code, like licenses in other cases, are designed to protect the copyright of a particular developer(s). In this table of contents we will look at examples of licenses. What they are and their disadvantages.

Types

Licenses have so-called “types”, nobody talks about them anywhere, as there is no such term in general. But I think it is worth noting the fact that physically they exist. Here is an example: We have an MIT license protecting code and a CC-BY-SA 3.0 license designed to protect assets. code cannot be under CC-BY-SA 3.0, and assets cannot be under MIT.

Examples(Code)

is a very popular and free license, it allows to use, modify and distribute software with minimal restrictions (copyright preservation is required).

AGPL

extended version of the GPL, requires publication of the source code even if the software is used over a network. Designed to corrupt your code(Simply put, using the AGPL, all other projects with the AGPL can take your code, and you can take their code. One of the worst licenses ever)

hybrid license, allows mixing open and closed code, but requires that changes to the licensed code remain open source.

Licence-agreement that governs the transfer of code rights between a developer and a project (e.g., in large open-source projects).

Examples(Assets)

No emphasis will be placed on these licenses. All of them allow to take assets for some conditions. It is best to understand this topic using already existing information on the Internet.

CC-BY 3.0
CC-BY 4.0
CC-BY-SA 3.0
CC-BY-SA 4.0
CC-BY-NC 3.0
CC-BY-NC 4.0
CC-BY-NC-SA 3.0
CC-BY-NC-SA 4.0

Git

Git is software designed to manage versions of code. All you need to know is that every repository, every copy on your computer, is unique. In this table of contents, we will look at some basic tips for using Git, to be more precise:

interface variations
basic commands or actions that are useful in your work.

Interface variations

The first thing to note is that when working with Git, it's best to use the Git interface, as it's easier and faster to work with it that way.

Examples

SmartGit
Fork
Github desktop
GitKraken
SourceTree

Basic Commands

Git clone
Git pull
Git push
Git add
Git commit
Git apply
Git merge
Git checkout
Git branch
Git rebase
Git cherry-pick
Git reset