There are always positive contributions to be done in this project. If you wish to contribute, we as a team would appreciate it. Here are the guidelines we would like you to follow:
- Contributing to this project
TextTron Snake is free software distributed under GNU GPL vr.3. In order to check the license specification give a look at the license file. Moreover, for checking the authors of the project, you can visit the authors file.
Please do not open new issues on the GitHub repository in order to make questions about the project. Instead, please feel free to send messages directly to the contributors of the project.
How should you make questions? Be direct and clear. Everybody has limited time, making questions that goes straight makes it easier to answer.
If you find a bug in the source code, you can help us by submitting an issue to our Github Repository. Even better, you can submit a Pull Request with a fix.
As a team, we work to fix all the issues as soon as possible, but before we do that, we need to be able to reproduce and confirm it. In order to reproduce bugs, we require that you provide a description of how to reproduce it. That enables us to go straight to the problem and does not require wasting time exchanging information.
You can request a new feature by submitting an issue to our GitHub repository. If you would like to implement a new feature, please consider the size of the change in order to determine the right steps to proceed:
- For a Major Feature, first open an issue and outline your proposal so that it can be discussed. This process allows us to better coordinate our efforts, prevent duplication of work and help you to craft, so that it is successfully accepted into the project.
- Small Features can be crafter and directly submitted as Pull Request.
The first step to making a contribution is creating a branch. The branch created must
follow the naming convention below, where <issue-number> is the number of the
issue that the pull request will solve (e.g. #42).
Branches names should be one of the four following options:
feature/<issue-number>
hotfix/<issue-number>
wip/<issue-number>
coldfix/<issue-number>
The meaning of each possible branch name is as follows. Choose the name that best suits the changes you made.
feature/<issue-number>: Implementation of a new feature, or update of an existing feature. This also covers updates to documentation.hotfix/<issue-number>: Fixes something that is broken in production. Often it is a fix to a problem that users are complaining about.wip/<issue-number>: Work in progress, usually tagged with "DO NOT MERGE" as well. This is for helping with early feedback on some development that will end up being a large PR.coldfix/<issue-number>: Planned fixes, which are announced beforehand.
Also, this project's development workflow is based on the GitFlow branching strategy that is very well encouraged by the community.
Before you submit an issue, please search the issue tracker. An issue for your problem might already exist and the discussion might inform you of workarounds readily available.
You can file new issues directly on the Github repository issues page.
It's important that every pull request fixes at least one issue. You can pick an issue that already exists or you can create one yourself, if you can't find one that addresses your problem. After an issue has been selected, assign yourself so other collaborators can be aware that you are taking care of it.
Before submitting your Pull Request, consider the following steps:
-
Search on the pull request tracker for open or closed pull requests related to the same issue.
-
Be sure that an issue describes the problem you are solving. Discussing ideas or implementations inside the issue page might help to ensure that the implementations have fewer flaws.
-
Fork the courselab/snaskii21 repository.
-
Inside your forked repository, create a new git branch to start working on your changes:
git checkout -b <new-branch-name> develop -
Create your patch.
-
Commit your changes using a descriptive commit message that should follow our commit message standard:
git add git commit -am "<your-commit-message>" -
Push your changes to the remote Github repository:
git push origin <new-branch-name> -
Inside the Github page, visit the pull requests page and select the proper protected branch (e.g.
develop) as destination branch. After a set amount of reviewers with write access have accepted the changes, it will be merged into the respective branch. -
Always keep your branch up to date with the destination branch, so that you do not run into code conflicts.
If you have forked the repository, you should read the github docs page on Configuring a remote for a fork. That is a way to configure a remote that points to the upstream repository in Git and always be aware of the changes inside courselab.
In summary, you must specify a new remote upstream repository to be synced with the fork:
git remote add upstream https://github.com/courselab/snaskii21And then you can use the
git pullcommand to update your fork with the changes from the upstream repository:git pull upstream develop -
Use our pull request template to make your pull request more descriptive.
We have simple rule over how our Git commit messages must be formatted. This format leads to easier to read commit history later on.
Each commit message should be written in the following format:
<tag>: <short-summary>
│ │
│ └─> Summary in present tense. Not capitalized. No period in the end.
│
└─> Commit tag: bug|hotfix|doc|dup|easy|feature|help|invalid|other|src|wontfix
The tag is the same option used as labels on issues. It makes it intuitive to construct the commit message and descriptive for anyone that is reviewing your pull request later.
This project's source code official repository may be found at
https://github.com/courselab/ttsnake
If you have obtained the source from the Version Control Repository, you will need GNU Build System (aka Autotools) to build the project, as described in file README, in the root of the project tree (really, read-me).
You are strongly encouraged to write your contribution and communicate with the developers and contributors community in English, if possible. Do not mind at all if your current skills are modest or incipient; no one expects otherwise --- your coding skills and will to help matter more. Use an automatic translator if needed. Just don't name variables and functions in a language other than English.
- Variables/functions formatting: snake_case
- Structs formatting: snake_case_t
- Indentation: Tabs
- Blocks: Same-line curly brackets separated by spaces
- If-like statements: Spaces before parenthesis
- Pointer asterisks: 'int *a'
- Declare multiple variables in same line: Yes
- One-liners: Break to multiple lines nevertheless
- Line's max-width: 80
Our versioning naming scheme is based on Semantic Versioning.
Code wisdom for this project
- Branch always (create a new feature branch for each modification)
- Commit small (add & commit single changes for better traceability)
- Merge safe (test, discuss, and approve merges to permanent branches)