This looks interesting (https://eventmodeling.org/posts/what-is-event-modeling/)

If you want to report a bug to a (typically an open source) project. Follow these steps:

Check if the bug is already in the tracker. If so see if you could add a new test case to demonstrste the issue.

If it is not in the tracker create a simple test case that demonstrates the problem. Being able to recreate the issue makes it far easier to work on, making it far more likely to be picked to work on.

If you know how to fix the problem check that they accept Pull Requests and supply one. Allow the maintainer to edit it. Its likely that you are going to have missed some internal rules of the project.

Contributions to documentation are really appreciated by maintainers.

I have been following Codurance Fireside Chats (This is Episode 38).

Public Interest Note: I currently work for Codurance.

In this episode Sandro mentions that there is very little impact that you can have in 20% of the time.
I disagree, you can achieve a big impact with small changes over an extended period.

A good example came when I was supporting a production client system (in addition to other new development work). At the start of each day I would check the most frequent error listed in the logs for the past 24 hours. I would either try and resolve that error or improve the logging so that it can be resolved in the future. This would take less than 15 minutes per day.

There is an interesting statistical effect that happens in any distribution of events. It is extremely unlikely that everything happens at the same frequency. Certain items will dominate the sample.. Items that have identical frequencies are likely to be coupled (such as a system reporting the same error in two places). This is known as the Power Law

By using the Power Law I was able to significantly reduce the volume of error messages. The top 5 formed 50% of the overall messages so in a week the error volume had halved. This made the error logs easier to read. This process repeated for a few months and eventually there were only a handful of errors left that were so infrequent as to not be worth fixing. The next target was the warnings.

This makes a great principle: try and fix or improve one small thing each day. Even if the rest of the day is fairly monotonous at least you have that one small win. By the end of a year you will have hundreds of small wins which should be significant (even if some of them had to be rolled back).

Today I have found my diary has 10 meetings.

This is a reminder never to let this happen again.

This looks to be very interesting: https://github.com/burrito-elixir/burrito

I am going to see if I can make this work with home_server