docs: add a decision regarding usage of 0pdd

Part of #1595

[skip ci]

Author: php-coder

Diff for: docs/decisions-log.md

@@ -2,6 +2,7 @@
 
 | Date/Type | Description |
 | --------- | ----------- |
+| 30.05.2023 Decision | [php-coder/mystamps#1595](https://github.com/php-coder/mystamps/issues/1595): The rate of issues that I faced with pdd/**0pdd** is too high. Time to time, it tries to create the duplicated issues or close issues while the comments are still in place. Also the issues that have been reported to upstream didn't have reaction from the maintainers for a long time. I decided that its cons overweight the pros and I dicontinued a usage of 0pdd. At the same time, the approach is still seems useful so I'm going to create my own solution that will be based on pdd and Github Actions (see [php-coder/mystamps#1610](https://github.com/php-coder/mystamps/issues/1610)). While pdd also has bugs and it isn't actively maintained, neverthereless I can fix the code by myself or I will be able to add workarounds if needed. |
 | 04.12.2022 Decision | [php-coder/mystamps#1600](https://github.com/php-coder/mystamps/issues/1600): during migration from Travis CI to GitHub Action ([php-coder/mystamps#1154](https://github.com/php-coder/mystamps/issues/1154)) I had to make a decision whether to port Danger or not. While I like the idea, I came to conclusion that I shouldn't port it and hence we will discontinue its usage. The main reason is that the project has no contributors other than myself, so I don't see a reason to invest my time to its migration. Even apart of migration, it still took time for maintenance, for instance, when a new tool is added. Also we used a version written on Ruby and I had a plan about rewriting it to JavaScript |
 | ~~09.07.2022 Workaround~~ | ~~[php-coder/mystamps#1533](https://github.com/php-coder/mystamps/issues/1533): After update of **html5validator** to 0.4.2, it has turned out that, starting from 0.4.0, it requires **Python** 3.6 that we don't have on Travis CI as we still on the old Ubuntu 16.04. Until we migrate to 20.04. (see [php-coder/mystamps#1467](https://github.com/php-coder/mystamps/issues/1467)), I decided to install Python 3.6 manually. Commits: [0e09fac8](https://github.com/php-coder/mystamps/commit/0e09fac8663d6642e13c7c413d550da163d4fa95)~~<br />UPDATE(03.12.2022): in [d2110ff6](https://github.com/php-coder/mystamps/commit/d2110ff651e84a32e25cc83cd4208d357f59791c) commit I reverted this workaround because it's no longer required: as part of migration to GitHub Actions ([php-coder/mystamps#1154](https://github.com/php-coder/mystamps/issues/1154)), since commit [661444c6](https://github.com/php-coder/mystamps/commit/661444c62d91694b628351b34724fdc6d999f5a4) we use a container with Ubuntu 20.04 and Python 3.8.10 |
 | 22.01.2022 Workaround | [php-coder/mystamps#1549](https://github.com/php-coder/mystamps/issues/1549): During update of **Liquibase** from 4.5.0 to 4.7.1 a new issue has been popped up: starting from 4.7.1 it logs all applied migrations to the console. And it seems like it logs directly and it doesn't respect logger configuration. It has a low impact to production but in test environment it spams a lot as we always apply all existing migrations. Moreover, it also affects unit tests where we use in-memory database. I raised this question in upstream (see my comments in [liquibase/liquibase#2200](https://github.com/liquibase/liquibase/pull/1932#discussion_r790117453)) but it might be an issue on our side as we use the latest Liquibase and (very old) Spring Boot 2.1.18 Commits: [f3c2e20d](https://github.com/php-coder/mystamps/commit/f3c2e20d1ba78703f53b6b090bfe7f7257e34a04)<br />UPDATE(24.01.2022): Bug: [liquibase/liquibase#2396](https://github.com/liquibase/liquibase/issues/2396) |