In order to have a common understanding of how we work and the associated terminology, this page exists. We explain the terms and conventions we use in our work, publications and offers.
Collaboration types
Depending on the scope of the desired cooperation, we distinguish between adivsory, blueprint and hands-on.
Advisory
Our understanding of advisory is, to discuss and brainstorm specific problems, challenges and strategy decisions. A possible outcome of those discussions may be a Blueprint with concrecte measures or a specific action for a hands-on phase. Requests are made by the client by e-mail and answered promptly, usually on the next next business day. Brainstormings and remote meetings take place on request. The keeping of interview notes is the responsibility of the client.
Blueprint
A blueprint is a document containing specific action recommendations and/or points to consider. The blueprint is used in the hands-on phase to implement required changes.
Hands-on
In a hands-on phase, we dive into the system or application and deal with the configuration and source code. Hands-on can be e.g. debugging of systems and applications, peer-programming, setting up a CI/CD environment or developing a patch.
Bug/Error/Defect and Bugfixing
A bug, error or defect is a result of an unexpected system behaviour triggered by a human. This can be something like an improper calculation of values due to logic errors, data losses due to functional errors or syntax errors. A bug can lead to a service interruption. That interruption is then called incident. Bugfixing means finding and fixing the corresponding code which led to the bug.
Debugging service interruptions
When dealing with service interruptions, we are using the terms incident and major incident from the ITIL terms and acronyms.
Incident
An Incident is defined as an unplanned interruption or reduction in quality of an IT service (a Service Interruption).
This can be e.g. a failing backup, slow response times, security issues, unplanned downtimes of non-critical systems.
Major incident
Major Incidents cause serious interruptions of business activities and must be solved with greater urgency.
An event where users can no longer work with a system or application in the usual way. Major incidents are business-critical. Such an incident can be e.g inaccessibility of an application because of timeouts or flashing error messages, certificate issues.
Conventions
Versions
If not defined otherwise, we use the Semantic Versioning 2.0.0 for versioning terms. It specifies a version number as MAJOR.MINOR.PATCH:
Major
MAJOR version when you make incompatible API changes
Minor
MINOR version when you add functionality in a backwards compatible manner, and
Patch
PATCH version when you make backwards compatible bug fixes.
Commits
Commits are referenced by a starting hash (#) and have at least 6 following alpha-numeric characters.
Issue references
- Issues in GitHub are referenced by their issue id with a prefixed hash (
#). It should be clear from the context that this is an issue and not a commit. - Issues in Jira are referenced by their Jira issue key, e.g.
MYPROJECT-555.
Date format
Generally we use the date format YYYY-mm-dd (year-month-day) or in abbreviated form, e.g. for file names YYYmmdd.
For German-speaking customers, we use the format dd.mm.YYYY.
If we want to describe a monthly period, we use the format YYYY-mm or YYYY-mm - YYYY-mm, regardless of the customer's country of origin.