Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RTL fixes #595

Merged
merged 18 commits into from
May 6, 2024
Merged

RTL fixes #595

merged 18 commits into from
May 6, 2024

Conversation

Arseny271
Copy link
Contributor

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.

Good luck and thanks for the contribution!

@TGX-Android TGX-Android deleted a comment from Krsitho Apr 28, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants