The guide below provides the flow for creating a perfect pull request to the Telegram X Repository. Before submitting your PR, ensure that it complies with the following principles.
Perfect PRs must be:
[ ] Rational. Explain the changes you've made. Be explicit and describe the changes in a few short, concise sentences.
[ ] Completed. All changes are properly tested and ready to be merged.
[ ] Up-To-Date. Your PR is based on the latest commit of the 'main' branch.
When fixing issues, make sure that your PR is:
[ ] Sufficient. Changes must fix the cause of an issue, not its effects.
[ ] Separated. Different bug fixes are divided into independent PRs.
[ ] Linked. If you fix a specific issue, add it to the title and its description to the body.
[ ] Creating. The fix does not break anything in other interfaces or on specific devices.
[ ] Consistent. Use the proper design relevant to the issue. If the design is missing, the PR must include at least two screenshots (before and after the changes).
When adding features, expect:
[ ] Discussion. If you implement a feature that requires a new design for the app, be ready to receive and follow comments or edit suggestions.
[ ] Dismissal. If the feature design you submitted is below our expectations, if it cripples the UX, or the feature-to-user impact is minor, your PR will be declined. All the features must strictly follow the Telegram X flow – matching the overall quality, stability, and the general style of the app.
Other contributions:
PR types not mentioned above can be considered as well, provided they are rational. For example, optimizations of existing features or the app build time (for this, before/after timing is mandatory). For code refactoring, the code should be clearly improved/simplified/more convenient and is expected to be free of any edge-case bugs.
The guide below provides the flow for creating a perfect pull request to the Telegram X Repository. Before submitting your PR, ensure that it complies with the following principles.
Perfect PRs must be:
'main'branch.When fixing issues, make sure that your PR is:
When adding features, expect:
Other contributions:
PR types not mentioned above can be considered as well, provided they are rational. For example, optimizations of existing features or the app build time (for this, before/after timing is mandatory). For code refactoring, the code should be clearly improved/simplified/more convenient and is expected to be free of any edge-case bugs.
Good luck and thanks for the contribution!