Describing problems and feature requests

Description, including impact and motivation, is very useful when prioritizing tasks, resolving problems and implementing features so make sure you do your best when creating tickets in Gitlab.

When describing a problem in Gitlab it is important to give a description of how the system should be set up and what steps should be followed to reproduce it. Current result and expected result should follow after that. Remember that it is always useful to have pictures and screen recordings in order to make tickets clear for our developers.

Go through these questions when creating a ticket for devellopers.

    Who is experiencing the problem? 
    : Company’s name, user’s name and role

    Where does the problem occur?
    : Page, button, tab or another part of the system

    What is happening? 
    : Error messages, behavior of the system

    What is the user trying to achieve?
    : Expected result

    At which point/step in the process does the problem occur?
    : Step-by-step description

    At what time did the problem happen?
    : Date and time

    Is the person using the web application or the mobile application? 
    : How the user is using the system

    Which browser is the person using?
    : Google Chrome, Microsoft Edge, Internet Explorer, Mozilla Firefox, Safari

    What version of the web application/mobile application is the person using?
    : Complete version information

    How critical is the situation? 
    : Describe the severity

    Critical - problem affects more than one client and prevents them from scheduling, time reporting, approving time reports, generating payroll and invoice basis.
    Major - problem affects one customer and prevents them from scheduling, time reporting, approving time reports, generating payroll and invoice basis.
    Normal - problem is irritating but we can go around it with a temporary solution.

When describing a feature request in Gitlab use the following guidelines:

    AS A (type of user)  
    I WANT (functionality/action)  
    SO THAT (benefit/outcome)  

Title of any ticket should be as specific as possible.

    Example of a title that could be improved: The system is slow 
    Example of a good title: It takes 1 minute to load monthly schedule containing X shifts