english русский
🌚🌚 First of all, thanks for your helping! 🌝🌝
This page briefly describes the process of developing both the specific MTProto package and all Xelaj projects. if you read all these rules, you will be the best helper in the wild west!
We all want to make other people happy! We believe that you are a good guy, but please, just in case, read our code of conduct. They will help you understand what ideals we adhere to, among other things, you will be even more cool!
By joining our community, you automatically agree to our rules (even if you have not read them!). and if you saw their violation somewhere, write to rcooper.xelaj@protnmail.com, we will help!
Just remind: you just don’t need to ask anything right to the issues, okay? just not necessary. you will quickly solve your problem if you find the answer below
We have the official Xelaj chat in Telegram: @xelaj_developers. In this chat you can promptly clarify the information of interest to you.
Also, github create discussions page! Ask in discussions, that's why this feature released. It's like stack overflow for any repo like this one!
And we also actually want to do FAQ, but we don’t know what questions to write there, so, if you are reading this, probably write while in the Telegram, we'll figure it out :)
Please, sign ALL of your commits. It's really really really important! Guide, how to sign your commits is here. Unsigned commits will not be merged
- Look for issues with a bug / bug label, it is likely that it has already been reported.
- even if you found issue: describe your situation in the comments of issue, attach logs, backup database, just do not duplicate issues.
We love to add new features! Use the New Feature issues template and fill in all the fields. Attaching labels is also very important!
Here it is up to you, the only thing is: we are more willing to take pull requests based on a specific issue (i.e., created pull request based on issue #100500 or something like this) This will help us understand what problem your request solves.
We love localizations! If you fluently know some more languages than us — feel free to create pull request with localization suggestion!
Note
The localization for application text is only worth to contribute right now. Documentation localization currently is not accepting, however, we want to continue this practice. See explaination in the spoiler.
Why we did that:
We are working hard on adding localization features to applications and services, however, the process of translating documentation is stopped for now. The reason for the delete previous translations is very simple: we do not have a suitable system to keep translations up to date for markdown files.
The reason lies in the fact that markdown is very difficult to structure, and the documentation is updated very often. The previous pipeline was like this:
- the document is updated in English
- the required block is manually found, using diff to send for translation
- a separate (!!) pull request is created to update the translations
- PR with translation is merged into PR with comments
- and only after that everything is merged into the master.
We are pleased with the idea that documentation can be manually translated and be more useful than auto-translation, but we do not yet have a suitable tool that would allow 1) structuring markdown files to clearly understand the differences between versions of translations, 2) working with git 3) work with github 4) don't be a pain in the ass.
If you know the tool which will help us — please, let us know. 🙏
We love Conventional Commits, so, please, use recommendations from that page.
One important change of conventional commits in our projects: use emojis,
please! They looks awesome, especially in git logs, in github ui, everywhere!
So, unlike feat: yakedey-yakedey, please name commits like
✨ yakedey-yakedey. Want prefix? ✨ (abcd): ooga booga is right for you.
Please add one space after emoji! Some terminals renders emojis by 2 columns
Note also, that prefix MUST only code of any project in github
(In description, you can see Code: ABCD, so use it. it's case insensitive).
This is real important to automatically add tasks to boards. But it's not
important! If you just want add scope — you're welcome, but please, don't add
unknown before scope
Don't add semicolon after emoji without scope: ✏️ fixed typo looks better than
✏️ : fixed typo.
Commit messages like 👷 fixed #1337 issue are NOT allowed. Git repository must
not be dependent by github.
There is a list of features and emojis right for you:
| Feature | Emoji | Desc |
|---|---|---|
feat |
✨ | Added some new feature, which wasn't before |
fix |
🐛 | Bug fixes |
deprecate |
🗑 | API Deprecation (but with saving backwards compatibility). Deprecation changes MUST be splitted to separate pull request. See? Emojis are shorter! |
docs |
📖 | Documentation improvements |
typo |
✏️ | Fixed typos, everywhere. In docs, in tests, in file names, in variables. Breaking changes allowed, but note this change in commit body, please |
style |
💎 | Style improvements of code, without change of logic e.g. formatting of code. If you changed code logic (even internal logic with backward compatibility), please, use 📦 feature |
refactor |
📦 | Code Refactoring. |
perf |
🚀 | Performance improvements (new benchmarks counts too) |
test |
✅ | New tests, test fixes, etc. Benchmarks are not included |
ci |
👷 | Building scripts, CI/CD stuff, etc. Any config changes for build systems, use also this prefix |
merge |
🔀 | Merge commits. Do not use it manually. |
chore |
🎫 | Chore stuff (add new dependencies, update links in docs, change year of license header). Adding contributors is also chore. |
egg |
🥚 | Some tweaks for easter eggs in code. These changes won't be showed in any changelogs |
revert |
🔙 | Revert any stuff, MUST NOT BE USED except in too bad cases! When you use this feature, you MUST add Reverts: <commit hash> commit tag (any pull requests which contains commits with this feature will be automatically closed) |
| ❌ Don't | ✅ Do | |
|---|---|---|
| do not write what commit does | commit adds ... |
added support ... |
| do not write who made a commit | I changed ... our team worked for a long time and created ... |
Added support of ... |
| write briefly (no more than 60 characters), everything else - in the description after two (2) new lines | fool, i forgot to delete ... |
removed ... |
Unlike official golang convention
Please, use format ErrXxx even for structs. It's important, cause in godoc all
errors are tighten to single place. Also, it's better to see unified view of
comparison for error types and error constants, e.g.
if errors.Is(err, ErrSomething) {
...
}
if e := ErrStructed; errors.As(err, &e) {
...
}So, please, use this naming. I know, you can hate us, and hate for obvious reasons, but even in go different teams can have different styleguides.
Most perfect way for structs is to use generic function like this:
func as118[T error](err error) (T, bool) {
var converted T
return converted, errors.As(err, &converted)
}
...
if err, ok := as118[ErrStructed](err); ok {
...
}And it's working!