Project: GraphScope (App Definition and Development / Database)
File: how_to_contribute.md

Thanks for your interest in the GraphScope project. GraphScope is an open-source project focused on large-scale graph computation with a friendly community of developers eager to help new contributors. We welcome contributions of all types, from code improvements to documentation. Before contributing to or engaging with our community, please read our . A good first step to getting involved in the GraphScope project is to participate in our discussions and join us in our different communication channels. Here are several ways to connect with us: We use to ask and answer questions. Feel free to ask any questions you may have about GraphScope or issues you've encountered with your own code. Join in the for discussion. If you find a bug in GraphScope, first test against the to ensure your issue hasn't already been fixed. If not, search our on GitHub to see if a similar issue has already been opened. If you confirm that the bug hasn't already been reported before writing any code. When submitting an issue, please include a clear and concise description of the problem, relevant code or error messages, and steps to reproduce the issue. If you find yourself wishing for a feature that doesn't exist in GraphScope, please open on GitHub to describe the feature, why it's needed, and how it should work. Other users may share similar needs, and many of GraphScope's features were added because users saw a need. A great way to contribute to the project is by improving documentation. If you find any incomplete or inaccurate documentation, please share your knowledge with the community. Documentation improvements are also a great way to gain some experience with our submission and review process, discussed below, without requiring a lot of local development environment setup. In fact, many documentation-only changes can be made directly in the by clicking the Edit On GitHub button. This will handle making a fork and a pull request for you. TBF: add a link to how to helping with documentation TBF: add a link to how to build the documentation If you would like to contribute a new feature or a bug fix to GraphScope, please first discuss your idea on a GitHub issue. If there isn't an issue for it, create one. There may be someone already working on it, or it may have particular complexities that you should be aware of before starting to

There are often several ways to fix a problem, so it's important to find the right approach before spending time on a PR that can't be merged. GraphScope use `pre-commit`_ to ensure no secrets are accidentally committed into the Git repository. Before contributing, install `pre-commit` by typing: ```bash $ pip3 install pre-commit ``` Configure the necessary pre-commit hooks with: ```bash $ pre-commit install --install-hooks ``` For minor changes that affect documentation, you don't need to open a GitHub issue. Instead, add the prefix "[MINOR]" to the title of your PR if it meets the following guidelines: Grammar, usage and spelling fixes that affect no more than 2 files Documentation updates affecting no more than 2 files and not more than 500 words. Fork the main GraphScope code and clone it to your local machine. See for help. Create a branch with a descriptive name. A good branch name would be (where issue #42 is the ticket you're working on): ```bash $ git checkout -b 42-add-chinese-translations ``` See for help. At this point, you're ready to make the changes. Feel free to ask for help because everyone is a beginner at first! Your patch should follow the same conventions and pass the same code quality checks as the rest of the project. Follow to attain the proper code format and style. To submit your changes, you will need to open a pull request (PR) against the main repository. If you're new to GitHub, you can find instructions on how to do that in . GraphScope requires PR titles to follow a specific format (a.k.a., ), depending on the type of change you're making. The format is as follows: type(scope): brief description about the pr Below are some examples of the valid PR titles: fix: Correct typo feat(interactive): Add support for g.V().outE().inV() refactor!: Drop support for Python 3.8 feat(analytical): Add delta-version for PageRank ````{note} Note that since pull request titles only have a single line, you have to use ! to indicate breaking changes. ```` The 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 docs: Documentation only changes feat: A new feature fix: A bug fix perf: A code change that improves performance refactor: A code change that neither fixes a bug nor adds a feature test: Adding missing tests or correcting existing tests chore: A routine task of development The scope is

However, if it assigned, it must be one of the following: core python k8s coordinator one interactive insight analytical learning In addition to the conventional commit specification, we also require the PRs with feature update, (i.e., titled with feat:) should update the corresponding documentations. The repo deployed a CI check to ensure this. You will probably receive feedback or requests for changes to your pull request. This is big part of the submission process and is necessary to evaluate your changes correctly, so don't be discouraged! If a maintainer asks you to "rebase" your pull request, it means that a lot of code has changed and you need to update your branch so it's easier to merge. To learn more about rebasing in Git, refer to the recommended workflow: ```bash $ git checkout 42-add-chinese-translations $ git pull --rebase upstream main $ git push --force-with-lease 42-add-chinese-translations ``` Feel free to comment in the pull request to ping reviewers if you're awaiting a response. If you encounter unfamiliar words or acronyms, refer to this . A pull request can only be merged into main by a maintainer if: It is passing CI. At least two maintainers have approved it. If a maintainer opened the PR, only one extra approval is needed. There are no requested changes. It is up to date with current main. TODO(dongze): TBF We welcome contributions from the community and encourage everyone to review pull requests. When reviewing a pull request, please consider the following: Does the code follow our ? Does the code solve the problem described in the issue or feature request? Are there any potential side effects or edge cases that need to be considered? Are there any tests included to ensure the code works as expected? If you have any questions or concerns about a pull request, please comment on the pull request or reach out to the contributor directly. All pull requests that contain changes to code must be run through continuous integration (CI) testing at The pull request change will trigger a CI testing run. Ideally, the code change will pass ("be green") on all platform configurations supported by GraphScope. This means that all tests pass and there are no linting errors. In reality, however, it is not uncommon for the CI infrastructure itself to fail on specific platforms ("be red"). It is vital to visually inspect the results of all failed ("red") tests to determine whether the failure was caused by the changes in the pull request.