آرمان عزیز سلام.
امیدوارم خوب و خوش باشی.

من اگه یک افتخار توی زندگیم داشته باشم، حتمن این لطف و نگاهی هست که تو به من و آروان داری.

توی این روزهای سخت که حقیقیت به راحتی قربانی جنگ‌های سیاسی میشه، خوشحالم که آدم‌هایی مثل تو هستند و این بیشتر از هر چیزی من رو به آینده امیدوار می‌کنه.

امیدوارم بالاخره یک روزی حقیقت روشن بشه.
و امیدوارم یک روزی بتونیم با هم همکار بشیم و از نزدیک همدیگه رو ببینیم.

به امید دیدار
در پناه خدا باشی

اماده شید که داداش اومد

این دو تا هم درمورد آداب کد ریویو و مرج رکوئست زدن بودند که بنظرم مفید هستند.

Do the pre-work
Help challenging code reviews go smoothly by reaching out to prospective reviewers before writing any code. Describing the problem and your approach ahead of time reduces surprise and provides an opportunity for early input. Ensure the decisions resulting from these exchanges, as well as the reasoning behind them, are accessible to others (e.g. via bug or design doc).

Mind your reviewer

Make choices that spare your reviewer time or cognitive load, such as preferring a series of short changes to a massive one, or uploading separate patches to isolate rebases during review.

https://chromium.googlesource.com/chromium/src/+/master/docs/cl_respect.md

Find an end
If you like things neat, it‘s tempting to go over a code review over and over until it’s perfect, dragging it out for longer than necessary. It‘s soul-deadening for the recipient, though. Keep in mind that “LGTM” does not mean “I vouch my immortal soul this will never fail”, but “looks good to me”. If it looks good, move on. (That doesn’t mean you shouldn‘t be thorough. It’s a judgment call.) And if there are bigger refactorings to be done, move them to a new CL.

Don't bikeshed
Always ask yourself if this decision really matters in the long run, or if you‘re enforcing a subjective preference. It feels good to be right, but only one of the two participants can win that game. If it’s not important, agree to disagree, and move on.
https://chromium.googlesource.com/chromium/src/+/master/docs/cr_respect.md