Skip to content

Instantly share code, notes, and snippets.

@yelizariev

yelizariev/1-Constitution.md

Last active February 20, 2021 00:05
Show Gist options
  • Star 7 You must be signed in to star a gist
  • Fork 3 You must be signed in to fork a gist
  • Save yelizariev/4f4fadf628f076d875b9 to your computer and use it in GitHub Desktop.
Save yelizariev/4f4fadf628f076d875b9 to your computer and use it in GitHub Desktop.
Download ZIP
IT-Projects LLC rules. The document is moved to https://gitlab.com/itpp/handbook/
Raw
1-Constitution.md

Constitution explains how and in what direction is the company growing

I. Just work well

  • The only way to compensate poorly made work is to improve yourself and do it well

I.1. No penalties

  • There are no any financial, moral, administrative penalties

I.2. No excuses

  • Inside the company, excuses have no sense

I.3. Only analysis

  • In case of any failure we analyse why it happened and what we can do. At the end we either

    • try to eliminate the cause
    • register that person doesn't follow the rules
    • update the rules

II. Just enhance Odoo

II.1. Develop

Open Source is a power

  • Idea that people who download your code will buy it when you close is wrong

    • Only small part of them will do it
    • Someone could make alternative (opensource or not) solution, that can destroy popularity of your code

  • In most cases it's good for IT ecosystem

    • People contribute to your code, rather than making the code you already done
    • People make other cool stuff, rather than making the code you already done

  • There are quite a few ways to earn with open source

    • Make a service for your software
    • Earn more after getting the reputation

  • Exceptions:

    • Customer is asking for proprietary software. If we accept it, we charge twice more, because we lost all other benefits
    • Publishing the source makes IT ecosystem or your service unhealthy. Example: Proxy part of IAP modules

II.2. Integrate

We use global IT ecosystem whenever it makes sense

  • Integration is better than no integration
  • All-in-one software shall not mean using other software is prohibited

II.3. Keep going

We make only odoo and related stuff

It's better to make odoo only, but do it the best. It's better than do everything but in a middle quality

Raw
corporate-culture.md

No micromanagement

Avoid micromanagement

  • Practice of autonomous work with probably a little bit far from ideal result is better than ideal but with micromanagement

No rushing

Super urgent tasks is a sign of bad planning

  • After each case rethink what was the reason and how to avoid it

Respectful communication

  • Don't use rhetorical questions. They don't help to analyze a problem and move forward.
  • Don't use pronouns (he, she). At least when the person can hear what you said or read what you wrote

Be open for community

  • twitter

    • you can use your account to tweet about development, work, traveling, vacation, fun
    • twitter profile's website URL has to be your page at team section, e.g. it-projects.info/team/yelizariev
    • no requirements for profile description, header photo
    • profile photo should be a real face photo
    • location has to be specifed YouCity, Country

  • github

  • https://gravatar.com

    • Be sure that your company email has avatar
Raw
development.md

Rules for developers only

Fix tiny issues

  • Fix tiny issues right after you find it, e.g.
    • wrong developer name or any other detail in __openerp__.py
    • variable that has to be renamed for any reason
    • etc.
  • If you don't fix in time, you could forget to do it at all. It means that your supervisor has to spend his time to find your tiny issues and wait for updates. If your supervisor doesn't notice such issue, you will release non-perfect product.

Make specification first

  • Make specification before you start actual development
    • It helps you to review requirements again before you start.
    • It helps your supervisor to check, that you understand requirements correctly

Always use specification templates

This rule helps keep module specification correct and complete

  • Don't use specification from old modules, use templates instead
    • Templates may be changed, while files in old modules may keep old variant
    • Templates have placeholders with instruction (like {put description here}) which you have to read before writing specification
      • Non updated (forgotten) placeholders are catched by travis

No code duplicates

Consider to make a method if you have similar code at least in two places

  • Such code is easy to fix / update (you do in a one place instead of 2+)

Use right names

Method, variables names:

  • shall not confuse. I must do / contain exactly what how it's named
Raw
git.md

Rules for developers only

Keep commit history clean

  • Clean history helps in understanding code via Blame tool
  • Clean history helps in reviewing pull request

Don't change git blame if possible

  • Avoid to make unneccessary changes in code lines if possible
    • it saves from a situation when you need to find significant commit for specific line in codes, but Blame tool shows a commit that either updates indent or adds a space, semicolon, comma, etc.
    • it saves reviewer's time

Review diff before making a commit

  • Clean code up, fix typos, undo unnecessary history changes, check formatting etc.
    • Respect time of your pull request reviewer

Use informative commit messages

Tag commits

  • Use tags to specify commit type

Use reference to an issue

  • Use reference to corresponding issue if any, e.g. work on issue #123
  • If commit fixes/closes issue at github, use special format to close that issue after merging, e.g. close #123

Commit message has to give an idea of the update

  • Don't use too short messages like "fix", "oops", "updates" etc
  • Commit message must be about updates commit makes, i.e. about diff
    • Don't reference to something outside the code, e.g. following messages are incorrect:
      • I'm going to switch from work computer to home computer, so I upload everything I have for now -- use instead [ADD] module for ...
    • If you made git reset, review your diff again and describe updates of new commits only
    • In the main, you cannot use the same commit message twice
  • It must be clear from the commit message why do you make such changes, e.g. following messages are not enough:
  • If commit fixes an error, don't just give a name to that error. Describe what error is. Examples of bad commit messages:
    • [FIX] fix longpolling error -- there could be a lot of different errors related to longpolling, you need to specify which one was in a code and fixed now

Be careful about git merge

Avoid to change strategy in git merge

  • Don't use -s option in git merge

Don't rename merge commits

  • use default merge message. You can add something there if needed, but don't delete default message
    • reviewer has to now which commits are merge commits
    • default merge message is used in multi pull requests

Make PR clean

Send only new commits only

  • it helps for reviewer to see what is changed after last review

Squash commits after work on reviews and CI checks

In order keep commit history clean, consider to squash some of your commits into one, especially when you

  • do lint fixes
  • fix CI tests
  • fix spelling
  • add code comments
  • etc,

Avoid of using git --amend to don't lose original commit history (see below)

Provide a link to original commit history after rewriting commits in PR

  • Before doing git rebase -i make a remote backup branch
  • After pushing updated commit history, add a link to original commit history (commits in backup branch, see example)

 * It helps to reviewers check that fixes were made correctly -- reviewers can see unsquashed changes

Avoid using of --force

  • Use --force-with-lease instead of --force

    • It prevents from losing updates made by reviewers directly in PR

  • make backup before using --force-with-lease

Raw
hours.md

Developer

  • Work week -- 5 days
  • Weekly workload (minimum hours) is 5 hours per work day, i.e. 25 hours in a normal week without holidays and vacations. Any type of projects are counted
  • Each hour after 20 hours has extra 50% compensation, but not more than for 10 hours. Only non hourly-rated projects are counted.
  • Work on hourly-rated projects has extra 50% compensation.

Take care of your time

Stop and ask

  • if you faced a problem and cannot find a solution more than 2 hours, then stop and wait for consultation with more experienced developers
  • after reporting on not working advice, it's probably better to wait while your advicer check that it really doesn't work, because oftenly advice was just wrongly applied
Raw
messaging.md

React on messages

  • On any question\remark\comment ether:
    • answer has to be given
    • or action has to be done
    • or message has to be starred for later reaction

Check Inbox

  • Go through all message at least at mornings.
    • It allows you be touch of all matters.
    • You can organaze work more efficiently and with right priorities if you have an idea about all updates in your inbox.
  • How to handle inbox:
    • Mark as read messages where you don't need to do anything
    • Messages with small action like quick response, small fix, etc, you may react immediatly
    • Everything else has to be marked as TODO (Star icon)
    • Odoo warning. Whenever you open any Record (Task, Lead etc.), all records are marked as read. Be sure, that you proceeded them. Don't lose them. Be carefull about opening any Record if your odoo inbox is not empty!

Write everything down

Write todos down

  • ToDos (messages) outside of task's form (oral, paper, IM, github, task's description field etc.) can be forgotten. Forgotten todo leads to mistakenly closed task. Mistakenly closed task can lead to unpredictable results.

Write questions to your supervisor down

  • If your supervisor is Cesar, he could easily do multiple tasks simultaneously. But if your supervisor is a simple human being, constant switching and returning to tasks easily makes him\her nervous and ineffective.

    • there is no exception for "small", "quick" question
    • there is no exception for "urgent" question. You must organise you work in way, when there are no urgent issues.

  • It helps you\your supervisor to write answer down. It's difficult to write answer down if there is no question

  • If you need direct discussion, it's a good idea to write the question in a chat, so supervisor can start discuss after finishing current tasks

Write answers down

  • While we write answers and questions down, it doesn't mean that we cannot have oral discussion. We can and it's even better, but every oral discussion must be summarised and written down.
  • It will help you and your colleagues to understand in the future what was going on, what and why decisions were made.
  • You remember advice better, if you write it down yourself.

Write down yourself

It's better to write down yourself, but if don't do it for some reason, then

  • you can expect that someone else do it only if you ask it explicitly: "Please write down ...."

  • check written text yourself

    • Expect that you can miss some points. To avoid this consider to write down yourself or at least send a chat message / audio message with full details

Report on results

Report when task is done

  • Before saying DONE, be sure that you have sent commit to your PR if it should be there

Report on not working advice

  • If advice doesn't work, your adviser has to know it.
  • If advice actually works, you have to just apply it correctly, instead of trying other (difficult) paths

Save time on unnecessary messaging

  • If you got a message and don't understand it (or have questions) -- consider to discuss it directly (live, chat, call)

    • if you need several iteration to get the resolution, you may lost a lot of time: (<average time of response> + <average time of noticing the response>) * <iteraions number>
    • after direct discussion write resolution down
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment