guidelines git_specification appendices commits

Appendices

Base Logic

This section tells the reasoning behind how the Conventional Commit for worldbuilding Specification are made. In summary, conventional commits definitions and specification must firstly be understand. Then, using inductive reasoning, extracting the pattern and reason of the specification. Then, using analogical and deductive reasoning, applying the pattern on worldbuilding project.

Conventional Commits Definitions

Conventional Commits specification for type fix and feat are:

• The type feat MUST be used when a commit adds a new feature to your application or library.
• The type fix MUST be used when a commit represents a bug fix for your application.

other oftenly used types are recomended by Angular Convention are:

Type [] Must be one of the following:

• build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
• ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
• docs: Documentation only changes
• feat: []
• fix: []
• perf: A code change that improves performance
• refactor: A code change that neither fixes a bug nor adds a feature
• style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
• test: Adding missing tests or correcting existing tests

Breaking Changes ...

Note

The definition of BREAKING-CHANGE for research commit still misty.

Extracting Patterns

By reasoning inductively, patterns of the commits' topic are identified. Since Conventional Commits are made to focus on software developments, the "object" of the commit are the code. Type feat, fix, refactor, perf, and style are changes made on the object of the project, which is the [source] code. Type build, and test are tools to manage the object. Type docs, chore, ci, and revert are the project managers.

The letter counts are also identified with data analysis. The lowest letter count is 2 letter, which is the type ci. The highest letter count is 8 letter, which is the type refactor. The mean, median, and mode are roughly the same, which is 4.

Therefore,

the topic of the commits are:

1. Changes made in the code;
2. Code's tooling;
3. Project management

the name of a commit type are usually 4 letters, with maximum 8 letters.

Applying Patterns

These patterns can be applied by reasoning analogically.

The "soul" of software is the source code. Source Code acts as the absolute foundation of a software project. Every other part of the software—from the user interface to the functioning application—originates directly from these lines of text. Something in worldbuilding have to be the "soul". Worldbuilding builds a world, obviously. lore, characther, magic system couldnt exist if there is the world doesnt exist.

Therefore, analogically, IF the soul of software is the source code, THEN the soul of worldbuilding is the world! ISNT THAT OBVIOUS?.

Applying the commits' topic to a worldbuilding will result in:

1. Changes made in the world;
2. World's tooling;
3. worldbuilding project management

Changes made in the world may include: (1) introducing new entry or framework; (2) making changes onto existing one; (3) Changing directory; (4) Adding sensory aids like illustrations, video, or music; (5) Correcting major meaning

Next is world's tooling. Entries are often be tagged (1) Generate/render the world from source files (2) Prepare the world for readers (3) Resolve/assemble worldbuilding data into a coherent dataset

Data are acquired using materials and methods prepared before acquiring it. Some data needs to process via codes, scripts, or program. Codes also sometimes need to be built/compiled or tested. The data that are already be processed and (then) analyzed/synthesized are then be disseminated. ? Experiments are also conducted not as part of the research, but to test, validate, verificate, and experiment on data and method used in the research. Therefore, from those statements, current best decision of the commit types that represents tools are "materials and methods", "code", "dissemination", and "experiments"

The worldbuilding project management are mostly non-in-universe documents. Management may involve gameplay or story, especially for RPG or writers. Using git repositories will encourage the use of CI/CD. It also giving the chances to revert a commit. This commit types already existed as docs, ci, and revert respectively.

"data acquiring" can use the existing commit type feat, since data acquiring "introduce" something new to the project. "code" can details it change by using the existed commit types feat, fix, refactor, perf, and style as scope or replacing it. Code tools can use the existing commit type build and test.

... code is type to group changes made on code, it's a 4-letter word. Code tooling will be grouped and abreviated as devtool, a 7-letter word. ... This changes made on the world can be grouped into a type called world, a 4-letter word. All proposed commit types above have letters that are not more than 8.

Breaking Changes is retcon!

Considerations

Type Clarity Issues: Should type for research and code must be separated distinguished as much as possible?

Introducing new data is being covered by commit type feat, and fixing data (eg. corrupted data, not its contents) is being covered by commit type fix. expt could also be merge with test since both of type represents "test" in research and code. Doing this can help compactness of the types and reduces choices being made. This scenario is also supported by the fact that some research do not use code to process their data, therefore some commit types will not be used. expt/Experiments also confuses many people since they understand "Experiments" as the main research action of "Experimental research" rather than data/method testing.