![]() SpecificationsĪs mentioned before, you are expected to follow these specifications in order to make everyone's lives easier. Suggestionsįeature requests and suggestions should not be made on the issue tracker. When attempting to fix a bug, if unassigned, Developers must assign themselves to the issue. If the bug in question is related to any change that may have been implemented by an active member of the development team, the Issue should be assigned to the person in question. If the bug could not be reproduced, the "Could not reproduce" tag should be applied. They should be tagged as bugs, as well as any relevant sub-categories that apply to them. Bugsīugs must be submitted using the bug template and should be reproduced by a member of the development team where possible. Open issues are categorized into two tags, bugs & suggestions. The only time multiple changes in an MR is acceptible is when submitting bugfixes to the repository. Contributors and maintainers must split up and create multiple MRs for each of their changes where necessary so as to keep them organized as their own standalone feature or change. Merge requests should not include multiple sweeping changes unrelated to each other. MRs should only be approved once all discussions opened during review of the MR are resolved. See Approvals below to determine who/when to approve an MR. ![]() Merge Requests targeting Dev should be set to squash commits and remove the branch when the merge is complete to keep the repository clean.Īll Merge Requests must wait for the CI pipeline to complete before merging unless there is a confirmed issue with the unit tests themselves.Īll Merge Requests require two valid Approvals to merge into Dev immediately, or one valid Approval by a Maintainer or higher and at least 24 hours of awaiting further approval. Merge Requests should include a copy of the changelog entries for that branch in its description Add any tags that apply to your MR, without being excessive. Any MR that is not complete and ready for review should be marked as a draft. No one may push to Dev without a Merge Request.Īll Merge Requests should be appropriately tagged. Merge RequestsĪll Merge Requests (except Dev to Master MRs) must either target a work-in-progress branch, or the Dev branch.Īll features added to Dev must come through a Merge Request. As a contributor, you may only open MRs with changes related to bugs, runtimes, or Accepted Suggestions on the Gitlab issue tracker, which are handled by the development team. Much like Developers, you are required to follow this document with regards to code quality and standards. As well as contributing to the repository, Maintainers are in charge of handling the review of open MRs, as well as the management of suggestions and issues.Ĭontributors refer to anyone outside of the development team contributing to the repository in the form of MRs. ![]() As a part of the development team, you are required to meet the guidelines and standards set by the Leads and the team when contributing to the repository. Maintainers refers to everyone in the development team. The Host is responsible for controlling, adding, and removing maintainers from the project. Wait for the Repository Owner to grant you access.Ĭlone the repository with your git client. This means that a merge request or change may be denied at the end, so understand that creative freedom does not grant you full reigns to commit anything to the repository without review, and you may have to deal with change requests or potential denial of your change.ĭownload and install your git client. While developers have the freedom to work on whatever they want, it falls to the team as a whole to decide if changes to the repository should be merged or not. Here are some useful starting guides, if you want to contribute or if you want to know what challenges you can tackle with zero knowledge about the game's code structure. That doesn't mean we aren't determined to squash bugs, which unfortunately pop up a lot due to the deep complexity of the game. CONTRIBUTING TO CM-SS13 Getting StartedĬM-SS13 doesn't have a list of goals and features to add we instead allow freedom for developers to suggest and create their ideas for the game. Commits before 9a001bf520f889b434acd295253a1052420860af are assumed to be licensed under GPLv3 and can be used in closed source repo. Authorship for assets including art and sound under the CC BY-SA license is defined as the active development team of CM-SS13 unless stated otherwise (by author of the commit).Īll code is assumed to be licensed under AGPL v3 unless stated otherwise by file header. The code for CM-SS13 is licensed under the GNU Affero General Public License v3, which can be found in full in /LICENSE-AGP元.Īssets including icons and sound are under the Creative Commons 3.0 BY-SA license unless otherwise indicated.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |