How to write issues that help moving the project forward

Rule No. 1: One issue is one issue

Each issue should describe only one particular problem. Do not write test report into one single issue. It’s impossible to communicate on the details if the original issue if the report is referring to different actual issues that will typically require different people to work on them.

Rule No. 2: Always include un-cropped screenshot

Un-cropped screenshot contains a wealth of information. Including, but not limited to: browser version, URL, date, time, windows version, scroll position. Developers don’t care if you have Facebook open on another tab. But screenshot cropped to 100x100 doesn’t convey any information. Issues without screenshot should be rejected. In rare cases when it’s hard to attain the un-cropped screenshot, a team member can try to replicate the problem and add screenshot. But if that is unsuccessful, then the issue should be really bounced back to original reporter. That being said, if the screenshot doesn’t include the URL (as is the case on mobile devices), write the url in description.

Rule No. 3: Clearly and verbosely describe what the current and expected behavior 

clearly and verbosely describe what the current behavior is and how it should behave. If not obvious from screenshot (e.g. mobile device), the description should have environment details (e.g. which browser, which phone, in case of phone, which version of OS,..)

The person assigned is responsible for moving the issue to resolution

If the issue is assigned to you, then you are responsible for either fixing the issue, adding information to the issue, checking the issue or reassigning the issue to someone else who will work on it. If you go to a vacation, make a triage of issues, select the ones that you’ll keep for after vacation and reassign the ones that are left.

Issue tracker is the only source of truth about issues

All work starts only and only if a issue exists in issue tracker. If you think you’re helping by starting work based on slack/telegram/verbal request, think again. There will be no record of the original requirements (a least not easy to find), there will be no prioritization,… In other words:  All of communication related to a issue should be recorded in comments of issue tracker; if you must communicate using other channels, then a note of the communication must be made in issue tracker comments.

The person writing the issue should understand it well enough to validate the resolution

When a issue is written, that is not the end of the road. Someone(s) must fix it and the person who wrote the issue will need to check if the issue is actually fixed.

Side note for programmers

If you did not push your code, then it’s the same as if you were never working

Always commit. If by the end of the day you have nothing to commit, then you weren’t coding. Perhaps you were reading, educating of writing documentation, but sure as hell you weren’t coding.

Programmers version of on issue is one issue rule: on commit is one limited fix/resolution/work item.

Just don’t write a new operating system and then push it as one commit with 100.000 lines and no commit message.

Always use CI/CD

Could should be automatically deployed to production when pushed to master. No manual copying at all. Prorgrammers should not have any access to servers other than trough GIT.