|
1 | | -Thank you for your interest in Picsart Creative APIs SDK project contribution! Please refer to the following sections on how to contribute code and bug reports. |
2 | | - |
3 | | -# Repository Structure |
4 | | - |
5 | | -| fold | description | |
6 | | -|---------------|------------------------------------------------------------------------------------------| |
7 | | -| `/src/` | folder containing the source files that implement API usage | |
8 | | -| `/tests/` | folder containing tests that ensure the high quality and stability of the implementation | |
9 | | -| `/scripts/` | folder containing scripts | |
10 | | -| `/examples/` | folder containing examples and samples of the SDK usage | |
11 | | - |
12 | | -## General Requirements |
13 | | - |
14 | | -When submitting changes and improvements to the codebase, it's important to provide all important pieces as described below |
15 | | - |
16 | | -- Source code: |
17 | | - - Contribute the main source code changes in `/src/`. |
18 | | - - Choose the right folder to publish the new implementation: `/src/image-api/` or `/src/genai-api`. |
19 | | - - Create a new folder for new endpoints, for example, `/src/image-api/new-service-name/`. |
20 | | - - Copy the style and create separate files for the request, result and the main implementation. |
21 | | - - Provide proper documentation for each added piece. |
22 | | - |
23 | | -- Tests: |
24 | | - - Create tests for all newly added functionality. |
25 | | - - Following the same pattern as with the source code, put tests under `/tests/image-api/` or `/tests/genai-api` folders. |
26 | | - - Run tests and make sure no test is failing because of the changes. Make sure to fix all tests before committing changes. |
27 | | - |
28 | | -- Third party libraries: |
29 | | - - In case new third party library dependencies are added, make sure to list those in the `/README.md` file, under the License section. |
30 | | - - Add the name of the library, version, the license, also a short description what that library is used for. |
31 | | - |
32 | | -- Copyright Notice and License Template: |
33 | | - - Run the `/scripts/license.sh` to add the boilerplate license notice to the new files. |
34 | | - |
35 | | -# Reporting bugs |
36 | | -Before submitting a question or reporting a bug, please take a moment of your time and ensure that your issue isn't already discussed in the project documentation or in the [Github issue tracker](../../issues) . |
37 | | -If you have identified a previously unknown problem, it's essential that you submit a self-contained and minimal piece of code that reproduces the problem. The bugs need to be reported in Gihub issue tracker, with “bug” label on them. In the Comment section, clearly explain what was your expectation, and what is the actual result of the execution. Try to isolate the function(s) that malfunction, attach the code snippets that can be easily compiled and run in isolation. |
38 | | -From the same issue tracker, You can also ask questions to CppBind code owners, by using “question” label while creating the Issue. |
39 | | - |
40 | | -# Pull requests |
41 | | -Contributions are submitted, reviewed, and accepted using GitHub pull requests. Please refer to [this article](https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests) for details and adhere to the following rules to make the process as smooth as possible: |
42 | | -- Make a new branch for every feature you're working on. |
43 | | -- Make small and clean pull requests that are easy to review but make sure they do add value by themselves. |
44 | | -- While contributing, please, follow the Style Guides |
45 | | - - for Python Coding defined as [Google Pythong Style Guide](https://google.github.io/styleguide/pyguide.html) |
46 | | - - for Java Coding defined as [Google Java Style Guide](https://google.github.io/styleguide/javaguide.html) |
47 | | - - for Typescript defined as [Google Typescript Style Guide](https://google.github.io/styleguide/tsguide.html) |
48 | | -- Add tests for any new functionality and run the test suite to ensure that no existing features break |
49 | | -- Every pull request needs to have at least 2 approvals before being merged. The mandatory approvers are code owners of the repository. |
50 | | -- Merging is getting done by Picsart, that is in charge of the tool stability and maintainability. |
51 | | - |
52 | | -# Release cycle |
53 | | -There is no fixed releases cadence, the new fixes/enhancements will be published on-demand. |
54 | | -The release train will take all the merges done after the last release, and generate a new release tag for them, with Semantic Versioning rules. |
55 | | -Release Notes will be located in the Github Releases file, with the latest first order, as well as at [Creative APIs Releases](https://docs.picsart.io/docs/creative-apis-releases) page. |
56 | | - |
57 | | -# Licensing of contributions |
58 | | -Picsart Creative APIs SDK is provided under a MIT license that can be found in the [LICENSE](./LICENSE) file. By using, distributing, or contributing to this project, you agree to the terms and conditions of this license. |
0 commit comments