-
Notifications
You must be signed in to change notification settings - Fork 46
Submitting Pull Requests
This page was written by post-editing, we are looking for volunteers who are fluent in both Chinese and English to help us with delicate human translation.
To ensure that project commits history is specific, concise and easy to retrieve, and to improve the efficiency of collaboration and project management, we want you follow this guide and carefully create a pull request.
Note that FGI members have the right to lower the priority of an pull request or even close it, depending on the extent to which it does not fit the format. Also, we may change the content, title or status of the pull request.
If you disagree with the outcome of an pull request, please reply to the pull request with a request and your reasons for reconsideration.
- Content of Pull Request
- Title of Pull Request
- Status of Pull Request
- Provisions for Handling Pull Requests by FGI Members
The pull request should have a clear subject matter and the changes included should be fully consistent with the subject matter and should not exceed the scope of the subject matter restrictions.
For example, a pull request to add a new game must not contain changes to FGI page style sheets.
The pull request should be as specific as possible.
For example, if you want to submit both a new game and a new author, you should create separate pull requests.
The description of the pull request should state the other active contributors to the pull request in the form of Co-authored-by.
Full format template for pull requests:
[Identifier] Mod or Range: Sub Mod: Summary (Referring)
Common format template for pull requests:
Mod or Range: Summary
Pull requests should be named according to the template above, except for pull requests that are merged using git revert, git merge --no-ff, or "Create a merge commit".
Revert "ci/main: fixup indentation"
Merge branch 'next-sublists'
This identifier declare that this submits will not and shouldn't be committed to main branch.
[DO NOT MERGE] next: renderers/nonl10n/singles: disable privacy-policy page
Unless extra indication, Mod or Range: use path of file, with no filename extension.
The followings are examples of pull request (commit) naming for frequently changed components.
You can add resource like game thumbnail, etc., no need to reflect this in message.
games/Kelipot: new game
games/Dragon_Island: update tags and links
games/Tavern_of_Spear: update link of chinese l10n patch
assets/The_HeartBeat: update thumbnail
games/l10n/zh: Echo: update translation for description
games/l10n/zh-cn: Bakabu: update translation for description
While updating multiple game description files:
games: update author info for 3 games from Echo Project
games: remove deprecated property sensitive_media for all entities
Updating multiple translation files of game items:
games/l10n/zh: add description-format for all entries
You can add resource like avatar file, etc., no need to reflect this in message.
authors/Studio_SelfCropping: new author
assets/_avatar/Zoharwolf: update avatar
When modifying code, if a module contains multiple classes and only one of them is modified, you can use Sub Mod: to specify the name of the class.
fgi/game: GameDescription: initial brief-description support
test/tagmgr: update unit test case
scripts/build-next: do not use uimod plugin
For code in plugin (fgi/plugins/...), the prefix fgi/ in Mod or Range: should be deleted, then make the remaining to comply with file path.
plugins/steam-cdn-unite: add new akamai CDN URI prefix
In the past, the directory fgi/renderers/ once was renderers/, This requirement ensures that the format is the same as the historical message format.
renderers/list: initial multi-klass support
templates: fixup xxx bug
templates/list: use list_item widget
templates/peafowl-private/header: fixup opengraph description escape
Although the styles files stored in webroot/styles/, the prefix fgi/ in webroot/ should be deleted, then make the remaining to comply with file path.
styles/32_game_entry: add workarounds for Mozilla Firefox
If you modified the file in the directory of webroot/base/, the prexix webroot/base/ in Mod or Range: should be changed to webroot/, then make the remaining to comply with file path.
webroot/robots: disallow /classic-ui
webroot/scripts/searchexpr: initial @reverse and @lastmod support
If you modified the file 'service worker', directly use sw: as Mod or Range:.
sw: proactive opaque cache avoiding
File path no need to reflect the variant.
uil10n/zh: add translation for ...
uil10n/zh: add translation for many keys
But, if you modified the file with the suffix _PRIVATE.yaml, the variant should be specified. Meanwhile, use PRIVATE: as Sub Mod.
uil10n/zh-tw: PRIVATE: add hotfix for list-klass-platform-mobile
doc/search_help: add more exampless
If you modified the file that in directory staging-ui and classic-ui, you should use staging-ui: or classic-ui/UI verison code name: as Mod or Range: , Meanwhile, use the remaining filename as Sub Mod.
staging-ui: styles/32_game_entry: add workarounds for Mozilla Firefox
classic-ui/pioneer: templates/pioneer-private/header: fixup build
Never use Sub Mod: in git module changes.
icons: bump to lastest version
If the repositories is maintained by 3rd organization, you can use the following message to indicate an updating to an upstream version. master can be replaced with most of the git referring, which can be branch name, tags and commit hash, but can't be HEAD, etc.
some_thirdparty/some_submodule: bump to upstream master
The treewide indicate the modification covered in whole source code tree, which is not related to specific module usually.
Never use Sub Mod: in treewide changes.
treewide: fixup line endings
treewide: run zhconv
The summary of a pull request must be written in English with a lowercase beginning.
The referring means an address which is related to what this patch modifies, and reviewers can find more helpful information about this modification via these links. See the GitHub documentation Linking a pull request to an issue for details on how to refer.
games/Deers_and_Deackards: new game (#691)
game/TianHeHui: update tags and links (#246)
A pull request that is not ready for review by FGI members should be set to "Draft" status until the pull request is ready for review by FGI members.
- FGI members shall follow the rules in this guide when submitting changes directly to the project repository.
- FGI members shall merge pull requests in "Squash and merge" way, with the exception of all commits that pull request records that conform to the rules in this guide.
- If an action is performed to change the content, title, or status of a pull request that may be contrary to the creator's intent, FGI member shall reply to the creator with specific reasons.
- After closing a pull request that is not closed due to completion, the FGI member shall reply to the creator with specific reasons and the right to apply for reconsideration.