From 42251ecbe79d82869ed07173a204a8a5619c1d94 Mon Sep 17 00:00:00 2001 From: Hermet Park Date: Sun, 6 Aug 2023 12:31:10 +0900 Subject: [PATCH] Update CONTRIBUTING.md --- CONTRIBUTING.md | 101 +++++++++++++++++++++++------------------------- 1 file changed, 49 insertions(+), 52 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e44aaf00..5972ab88 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -1,24 +1,24 @@ -We always appreciate your contribution. ThorVG doesn't expect perfect patch contributions, instead we expect contributions if your patch makes thorvg better than before. This page guides the ThorVG contribution format.
+We always appreciate your contribution. ThorVG doesn't expect patches to be perfect; instead, we value contributions that make ThorVG better than before. This page outlines the ThorVG contribution format.

## Reviewers -Hermet Park (hermet) is the lead maintainer. Also there are designated maintainers you can request your pull-request for separate modules. +Hermet Park (hermet) is the lead maintainer. Additionally, there are designated maintainers to whom you can direct your pull requests for separate modules. -common: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)
sw_engine: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)
svg_loader: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)
-tvg_saver: Mira Grudzinska (mgrudzinska)
tvg_loader: Mira Grudzinska (mgrudzinska)
-svg2png: Junsu Choi (JSUYA)
+webp_loader: Junsu Choi (JSUYA)
+tvg_saver: Mira Grudzinska (mgrudzinska)
capi: Mira Grudzinska (mgrudzinska)
test: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)
+svg2png: Junsu Choi (JSUYA)
examples: Junsu Choi (JSUYA), Mira Grudzinska (mgrudzinska)

## Self Test & Verification -After updating ThorVG code, please verify your change doesn't break the library. We suggest unit-tests using the Catch2 framework. You can easily run it with build commands as the following:
+After updating the ThorVG code, please ensure your changes don't break the library. We recommend conducting unit tests. You can easily run them using the following build commands:

` -$meson . build -Dtests=true -Dloaders="all" -Dsavers="tvg" -Dbindings="capi" -Dtools="all" -Dlog=true +$meson . build -Dtests=true -Dloaders="all" -Dsavers="all" -Dbindings="capi" -Dtools="all" -Dlog=true `
` @@ -39,69 +39,66 @@ Timeout: 0
[Description] -- [Module] is a sub module majorly affected by your change. Most of times this indicates a sub folder name. -This indicates whom need to review your patch as well. -If your change don't belonged to any sub modules, you can replace with proper name or skip it. -The name must be written in all lower alphabet characters. - - ex) build / doc / infra / common / sw_engine / gl_engine / svg_loader / examples / wasm / svg2png ... +- [Module] refers to the sub-module primarily affected by your change. Most of the time, this indicates the name of a sub-folder. +This also suggests who might need to review your patch. +If your change doesn't belong to any sub-modules, you can either replace this with a suitable name or skip it. +The name should be written entirely in lowercase letters. + - e.g., build, doc, infra, common, sw_engine, gl_engine, svg_loader, examples, wasm, svg2png... -- [Feature] is what major function/feature you changed. Normally this indicates a representive file name. -You can keep the file name, but don't please contain any prefix(tvg) nor suffix(Impl) here. - - ex) Canvas / TaskScehduler / SvgLoader / SvgBuilder / SwRle / GlRenderer / ... +- [Feature] indicates the primary function or feature you modified. Typically, this represents a file name. +Retain the original file name, but please don't include any prefixes (e.g., "tvg") or suffixes (e.g., "Impl") here. + - e.g., Canvas, TaskScheduler, SvgLoader, SvgBuilder, SwRle, GlRenderer... -- [Title] is a brief description of your change. It must be described in one sentence. - - ex) "Fixed a typo" - - ex) "Fixed compile warnings" - - ex) "Code refactoring" - - ex) "Fixed a rendering bug that overlapped shapes inproper way." +- [Title] provides a brief description of your change and should be encapsulated in a single sentence. + - e.g., "Fixed a typo." + - e.g., "Addressed compile warnings." + - e.g., "Refactored code." + - e.g., "Resolved a rendering bug causing overlapped shapes to display improperly." -- [Description] There is no any strict formats, but it must describe what you did in this patch as far as possible you can describe in detail. +- [Description] doesn't have a strict format. However, it should detail what you accomplished in this patch as comprehensively as possible. - If you fixed any bugs, it must contain below: - - what type of bug - - conditions to reproduce it - - root cause - - solution + If you've resolved bugs, include the following details: + - The type of bug. + - Steps to reproduce it. + - The root cause. + - The solution applied. - Or if you add a new feature or function, it must contain below: - - what sort of features - - api full specification (if any api additions) - - any necessity - - condition / restriction - - reference or sample + For new features or functions, cover: + - The nature of the feature. + - Full API specifications (if there are any API additions). + - Its necessity or rationale. + - Any conditions or restrictions. + - Relevant examples or references. - Lastly, please append any issue ticket numbers in this section if any. + Finally, include any related issue ticket numbers in this section, if applicable. -- Here is a overall commit message what we expect to review: +Here's a sample commit message for clarity: - - common composite: newly added path clipping feature +- common composite: Introduced path clipping feature - We introduced new method Paint::composite() to support composite behaviors.
- This allows paints to composite with other paints instances.
- Composite behaviors depend on its composite method type.
- Here we firstly introduced "ClipPath" method to support clipping by path unit of paint.
+ We've added a new method, Paint::composite(), to support various composite behaviors. This allows paints to interact with other paint instances based on the chosen composite method. Initially, we're introducing the "ClipPath" method for path-based clipping. - tagetPaint->composite(srcPaint, CompositeMethod::ClipPath);
+ targetPaint->composite(srcPaint, CompositeMethod::ClipPath); - Beaware if the source paint doesn't contain any path info, clipping won't be applied as you expected. + Note: If the source paint lacks path information, clipping may not produce the desired effect. - @API Additions:
- enum CompositeMethod {None = 0, ClipPath};
- Result Paint::composite(std::unique_ptr target, CompositeMethod method) const noexcept;
+ @API Additions: + enum CompositeMethod {None = 0, ClipPath}; + Result Paint::composite(std::unique_ptr target, CompositeMethod method) const noexcept; - @Examples: added ClipPath
+ @Examples: Introduced ClipPath - @References: any links to the references such as screenshot images. + @References: [Provide any relevant links, such as screenshots.] - @Issues: (Issue Link) + @Issues: [Link to the issue]
## Pull Request -Once you submitted a pull request(PR), please make it sure below check list. -- Reviewers: Check Reviewers List -- Assignees: You -- Labels: Patch Purpose -- CODING STYLE CHECK: Must be perfect +Once you've submitted a pull request (PR), please ensure the following checklist is completed: +- Reviewers: Check the Reviewers List. +- Assignees: You should be assigned. +- Labels: Mark the appropriate Patch Purpose. +- Automated Integration Test: All must pass.