feat: add human.json

content/ai.md

@@ -0,0 +1,9 @@
+---
+title: "AI Usage"
+date: 2025-03-18T12:51:08+02:00
+draft: False
+---
+
+No content on this website is the product of genAI, unless it is specifically mareked as such (e.g. to showcase bad code).
+
+Some people might vouche that this site is written by a human, you can check the status with [human.json](https://codeberg.org/robida/human.json).

content/notes/commitments.md

@@ -0,0 +1,94 @@
+---
+title: "Commitments"
+date: 2025-12-18T20:30:00+02:00
+draft: false
+subtitle: "It's frustrating to work for organizations that don't manage to get something online. How to fix that?"
+---
+
+In the past I have worked with various non-profit association, helping them with their IT. I have amd mixed experiences
+how productive and rewarding that was. After two particularly bad experiences I have decided I need a change,
+specifically I need more **commitment**.
+
+# The problem
+
+The main problem boils down to indecision and missing capacity/priority. As an example: A group wrote an extensive
+google doc, detailing about 15 pages on a website that is to be created. After implementing this in a few weeks (mainly
+due to necessary changes of already outdated information) a section of the website was ready for final approval, another
+one was in a Proof-of-Concept phase. This was finished in September. Since then, I repeatedly asked for review so the
+site could go live.
+One person reviewed parts, but wanted another person to give feedback as well.
+Now, end of December, the finished section is still not live. I refuse to put more work in until the existing work is
+reviewed.
+
+# The solution
+
+Tackle such projects, like I'd tackle a project in my day-job: Define stakeholders, a timeline and force decisions when
+necessary. Demand commitments. 
+
+## Scenario 1: Basic Website
+
+I believe the most common first step for organizations is to set up a website and be reachable via e-mail. For a first
+website there need to be the following things:
+
+* Homepage with short description and one Call-to-Action
+* Imprint
+* Data privacy statement
+
+A typical process to set up such a website should be
+
+* **Kick-Off call**: Discuss basic content and style elements, clarify technology, cost and timeline
+* **Basic implementation**: The developer will set up a website with the basic style elements and sections for the
+  content (not filled with real text yet)
+* **Content generation** The organization provides text for the website
+* **Implementation**: Content is added to the website by the developer
+* **Testing**: The organization checks the result, the dev will make minor adjustments
+* **Go-Live**: After confirming a successful test, the website will go-live
+
+In order to keep risk low, the time between Kick-Off and Go-Live should be planned to last not longer than 6 weeks.
+Otherwise, there is a risk that one side puts in a lot of work that is then not rewarded with a Go-Live.
+
+Here are some other commitments, one could think of:
+
+| Organization                                              | Developer                                      |
+|-----------------------------------------------------------|------------------------------------------------|
+| Provide text within two weeks after basic implementation  | Provide basic implementation within two weeks  |
+| Take not more than one week for testing                   | Make minor tweaks within a week                |
+| Provide actionable items when test result hinders Go-Live | Document infrastructure                        |
+| Define central person for functional questions            | Only implement what others could also maintain |
+
+## Scenario 2: Joining an existing IT team
+
+Another common scenario is joining an existing IT team. I've been on both sides of that process and here is how I think
+it should work
+
+* **Welcome call:** Who is everyone, who is responsible for what, how is the team organized? Define a first task that
+  the
+  new person can reasonably do. The smaller, the better.
+* **Technical onboarding:** Create admin users, invite to password manager, put SSH keys on server
+* **Getting started:** Newbie starts the task, knows who to ask when they need help - someone needs to be available to
+  answer questions, otherwise frustration and mental overload will settle in soon
+* **Integration in regular work** Newbie is assigned responsibilities and part of the group
+
+Ideally documentation already exists for the new person to learn. If not, this is a great opportunity to add it! If the
+Newbie has a question: Answer the question in detail and past the answer in your documentation. It will benefit you in
+the future, I promise!
+
+So this seems reasonable right? But there are many ways to fuck it up.
+
+### Reasons for failure
+
+* **Missing access:** This is something I have experienced time and time again. From data protection concerns to trust
+  issues, the problem was always power: Existing admins did trust the newbies with the power they have. And that is the
+  core problem: if someone has access, they can mess up things. Even the most experienced admins. That's why you should
+  have backups and written agreements on data protection. If you don't then your existing admin is more of a threat than
+  the newbie.
+* **Unclear processes:** So often it's unclear how decisions are made, whome to communicate a downtime, and so on.
+  Newbies are overwhelmed because they don't know what to do, existing teams are annoyed by newbies because they "don't
+  fit in"
+* **Missing capacity:** When you onboard people, this will take extra effort. There must be time made for that, you need
+  new people to succeed. If you don't do onboarding right, the new person will never become part of the team, will
+  eventually leave and your team will shrink more and more until it fails.
+
+# Conclusion
+
+New contributors are valuable. Don't waste their time, don't let them feel helpless. Then you will succeed.

content/post/trying-twenty/index.md

@@ -141,7 +141,6 @@ def sync_rescue_org_to_twenty(rescue_org: RescueOrganization, base_url, token: s
 
 ```
 
-#        
 
 # The Company, Business Model and Paid Features
 
@@ -184,7 +183,5 @@ Here is a short list of features I missed and their place on the roadmap if they
 
 * **Compose & Send E-Mails**
   Planned [Q4 2025](https://github.com/orgs/twentyhq/projects/1?pane=issue&itemId=106097937&issue=twentyhq%7Ccore-team-issues%7C811)
-* **Foreach loops in Workflows
-  ** [Q3 2025](https://github.com/orgs/twentyhq/projects/1/views/33?pane=issue&itemId=93150024&issue=twentyhq%7Ccore-team-issues%7C21)
-* **Conditions in Flows
-  ** [Q4 2025](https://github.com/orgs/twentyhq/projects/1/views/33?pane=issue&itemId=121287765&issue=twentyhq%7Ccore-team-issues%7C1265)
+* **Foreach loops in Workflows** [Q3 2025](https://github.com/orgs/twentyhq/projects/1/views/33?pane=issue&itemId=93150024&issue=twentyhq%7Ccore-team-issues%7C21)
+* **Conditions in Flows** [Q4 2025](https://github.com/orgs/twentyhq/projects/1/views/33?pane=issue&itemId=121287765&issue=twentyhq%7Ccore-team-issues%7C1265)

layouts/notes/list.html

@@ -6,12 +6,12 @@
 </div>
 
 
-<ul style="list-style-type:none">
+<ul class="notes-list" style="list-style-type:none">
     {{ if (.Pages.ByDate.Reverse) }}
     {{ range .Pages.ByDate.Reverse }}
     <li class="block">
         <h2>
-            <a href="{{ .Permalink }} " style="color: whitesmoke;"> {{ .Title }} </a>
+            <a href="{{ .Permalink }} " style="color: whitesmoke;"> {{ .Title }} <i class="fas fa-link"></i></a>
         </h2>
         <small style="color: whitesmoke;">{{ .Date.Format "2006-01-02" }}</small>
         {{ if .Params.subtitle }}

static/human.json

@@ -0,0 +1,10 @@
+{
+  "version": "1.0.0",
+  "url": "https://hyteck.de",
+  "vouches": [
+    {
+      "url": "https://notfellchen.org",
+      "vouched_at": "2026-03-18"
+    }
+  ]
+}