Builder Season Playbook

Hello World

2026-04-29T00:00:00Z

I registered for the hackathon today and created the repo and made an annoucement post on X

Cool day ... and I got my progress log working ... I think.

It works but I still need to clean up some stuff. Cheers!

todo:

make blog-menu work in the most simple way - change to npm
make npm scripts to acces the blog / logging

The Web is on

2026-05-01T00:00:00Z

So today I was able to get the website going with this rogress log and an activity dashboard that pulls things from Discord and you know creates an 11T site that's able to be published on Github pages Feel like it was pretty good for Friday afternoon Have a great weekend!

Some Todo: Add Twitter profile pics, cutoff long commit messages, save the data from the API locally to cutdown on hitting the API limits, something with collecting and verifying the Twitter update posts

X search semi automated

2026-05-05T00:00:00Z

Working on shifting to Python and to a simple data model Moving away from Python to node Codex says:

• The activity pipeline is now Node-based.

  I replaced web/scripts/generate-activity.sh:1 with web/scripts/generate-activity.mjs:1 and updated web/
  package.json:1 so npm run build:data now runs node ./scripts/generate-activity.mjs. The new script keeps the
  same output shape in web/src/_data/activity.json, but the date math, GitHub requests, pagination, and JSON
  shaping all live in one Node module now.

Questions

What is normalization? When to use Bash, Python, or Node? is there a way to have a "don't hit the API" flag? The problem of builders starting in different weeks. Could each builder have a "start week" attribute?

Reference

xSearch = { adminWeek1Start, adminDurationWeeks, builderUpdateDurationWeeks, defaultBuilderWeek1End, weeklyUpdateHashtags, weeklyUpdateMention, configError, currentAdminWeekIndex, weeks: [ { index, startDate, endDateExclusive, endDateInclusive, label, dateRangeLabel, searchUrl } ], builders: [ { id, name, xHandle, firstUpdateWeekStart, firstUpdateWeekEnd, firstAdminWeekIndex, finalPresentationWeekEnd, searchUrl, weeks: [ { index, startDate, endDateExclusive, builderWeekIndex, builderWeekLabel, label, dateRangeLabel, searchUrl } ] } ] }

activity = { generatedAt, weekStart, weekEnd, builders: [ { id, name, lastActivityAt, commitsThisWeek, recentCommits: [ { repo, message, url, committedAt } ], error } ] }

builders = [ { id, name, github, x, xRequiredHashtags, xRequiredMention, xIgnore, projectName, projectUrl, repoUrl, pies, notes } ]

Bash Bash? move from Bash to Python

2026-05-05T00:00:00Z

I wanted to make sure I was using the right tooling and I think Python fits here. I'm using a script to take yml data - that I manually input and that outputs JSON for the 11ty to build the frontend... but why? Why not just use the yaml? Im pretty sure 11ty can use yml as well as JSON.

I think it's part of the iterative process to go back and rebuild when I 'see' it better. And, it underlines the data model first building method that I've seen some folks use. ... and that's what I'll do tomorrow.

PS: I'm pleased with the current Piece of pie hackathon. we closed the registration and have over 20 builders - which meets our goal. And, I'm happy with creating this repo to 'productize' the hackathon and make it a replicable safe space for builders of tomorrow. (yeah, I really think like that)

Codex says:

Implemented the Python migration. The builder normalization logic now lives in web/scripts/builders_json.py:1, with comments at the
  same intent-level as the shell scripts, and the old builders-json.sh entrypoint has been removed. Callers now invoke python3
  directly from web/package.json:7, web/scripts/generate-activity.sh:25, and web/scripts/generate-x-posts.sh:13.

  I also added the minimal Python dependency file at web/requirements.txt:1, updated both GitHub Actions workflows to install Python
  and PyYAML before builds (.github/workflows/update-activity.yml:30, .github/workflows/deploy.yml:37), and refreshed the docs in
  README.md:90 and web/README.md:15 to reflect the new runtime and the fact that the X pipeline still uses Ruby for now.

  Verification: python3 web/scripts/builders_json.py passed, and npm run build:data:x passed end-to-end. I did not fully verify npm
  run build:data because that path calls the live GitHub API. One generated file changed in-repo: web/src/_data/builders.json:1. Its
  content is equivalent, but empty arrays are now rendered as [] instead of Ruby’s multiline empty-array formatting.

updating the repos.yml

2026-05-06T00:00:00Z

Just updating the repos.yml with the "source of truth" spreadsheet that Harsha and I work with as admin ... and yes, I did it by hand, check it line by line and then ask copilot to verify it.

I'm learning so many little things by working on this project. Like .yml files and 11ty global data. One technique is to search Github for how others are using it and asking the AI to explain stuff.

The tech stack for this project

2026-05-06T00:00:00Z

Here's the tech stack for this repo:

Core:

Eleventy (11ty) v3.1.2 — Static site generator
Nunjucks — Template engine (.njk files)
Node.js — Runtime (ES modules)

Data & Config:

YAML (js-yaml v4.1.1) — Configuration files (repos.yml, event.yml)
GitHub API — Source of commit activity data
JSON — Data interchange (activity.json, builders.json, xSearch results)

Plugins:

@11ty/eleventy-plugin-rss v2.0.4 — Atom feed generation

Build & Scripts:

npm scripts — Task runner
Node.js ES modules — Standalone scripts for data generation (.mjs files)

Architecture summary:

Config layer → repos.yml (manual registry) + event.yml (event timing)
Data generation → generate-activity.mjs fetches GitHub API, outputs activity.json
Data aggregation → _data files (builders.js, activity.json, xSearch.js) provide global template data
Templates → Nunjucks + custom Eleventy filters (defined in eleventy.config.js)
Output → Static HTML in _site

The workflow is: YAML config → GitHub API → JSON snapshot → Nunjucks templates → Static site.

No framework cruft (React, Vue, etc.) — pure static generation optimized for content and dashboards.

writing a newsletter and updating the weeks

2026-05-08T00:00:00Z

Hello Happy Hackers

I'm not sure why we ended the weeks on a Sunday. I suppose it was to highlight the 'deadline' or 'due date' aspect. It could just as easily been ending on Friday, due on Friday. In future hachathons, this will be configurable.

We addressed the Admin Week and Builder week. The Admin weeks start when registration begins and the buider weeks start when registration closes. ... hmmm, maybe next time we use the NASA model of Time Minus and Plus. Weeks before registration closes (LIFTOFF) are Minus weeks and after are plus weeks or just weeks.

Anyway - happy Friday

and here is what Codex says:

Implemented the week-model change across config, data generation, dashboard UI, and docs.

  The core change is in /home/nsl/ad-ipsum/builder-season-playbook/config/event.yml:18, scripts/event.mjs:18, and src/
  _data/xSearch.js:1. Admin week 1 is now anchored to 2026-04-13 through 2026-04-19, the admin calendar runs for 14 weeks,
  builder updates run for 12 consecutive weeks, and the default builder Week 1 is the week ending 2026-05-03. Builder
  timing is now computed separately from admin week numbering, so a builder’s Week 1 can correctly map to Admin Week 3 and
  their final presentation week can land on 2026-07-19.

  The dashboard and builder pages now explain that distinction instead of hiding it. src/dashboard/index.njk:16 keeps
  admin week labels as the canonical labels, adds builder Week 1 and final presentation columns, and clarifies that the
  GitHub activity section uses the current UTC week. src/builders/builder.njk:45 shows each builder’s Week 1 update
  timing, admin-week offset, and final presentation week. I also updated README.md:30, /home/nsl/ad-ipsum/builder-season-
  playbook/config/repos.yml:1, and the internal reference post at src/posts/2026-05-05-x-search-semi-automated.md:28.

  I used an event-level default for all current builders rather than writing the same first_update_week_end into every
  builder entry. Individual builders can now override that in config/repos.yml when needed.

  Verification: ./node_modules/.bin/eleventy completed successfully, and the generated data confirms Week 1 = Apr 13 to
  Apr 19, Week 2 ends 2026-04-26, default builder Week 1 ends 2026-05-03, and the computed final presentation week ends
  2026-07-19.

Builder facepile and post tools

2026-05-12T00:00:00Z

Today I made two related improvements to the Builder Season Playbook: a new builder facepile on the homepage and a smoother post-writing workflow for future updates.

Builder Facepile

The homepage now includes a GitHub-profile-image facepile built from the existing normalized builder registry. The data still flows from config/repos.yml, optional project.yml overlays, and then through the shared builders array that Eleventy already consumes.

I added a small normalization step so each builder exposes githubProfileUrl, githubAvatarUrl, displayName, and builderPageUrl. The avatar URLs use the stable GitHub pattern https://avatars.githubusercontent.com/{username}?s=80, and the landing page renders those images with accessible markup, explicit dimensions, and lazy loading.

The section fits the site’s current warm editorial look: overlapping circular avatars, subtle hover and focus states, and wrapping that still works on mobile.

Post Authoring

I also updated the posting workflow so new posts can include an explicit author line without rewriting the older archive by hand. The shell scaffolds now default to author: "Newman", while the post templates render Author: Newman when a post does not define an author.

For agent-authored posts, there is now a dedicated create-post routine and repo-local plugin bundle. The script can generate a markdown file, create the matching image directory, and prefill a short summary body. That gives us a cleaner path for turning work sessions into publishable updates without having to reconstruct the front matter every time.

Verification

I ran the local Eleventy build after these changes. The homepage facepile rendered, existing posts displayed the new author line correctly, and the post-creation dry run produced the expected file path, image directory, and front matter.

That should make the site feel a little more personal on the front page and a little easier to maintain behind the scenes.

Little fixes that build up over time

2026-05-20T00:00:00Z

Newman's thought this week

Builder Season Playbook Progress Log

Dashboard / Infrastructure Updates

Current improvements and cleanup tasks for the dashboard:

use active: true/false instead of ignore in the repos.yml and ingestion scripts
make the "Deploy to GitHub Pages" script run after the "Update GitHub Activity" script
- activity updates daily, but the site is still manually deployed, which means the dashboard can get out of date quickly
- goal: automatically deploy at least once per day after the activity script runs
the dashboard page is too long
- remove the "Builder X Searches" section
- move recent commits to the top
  - shorten commit messages to a reasonable length
- explore simple toggle headlines / collapsible sections using native HTML if possible
  - keep it as lightweight and simple as possible
make X handles clickable links in the Builders section

So, here are my updates while working on the Builder Season Playbook.

To be honest, I was having some trouble motivating myself to really dive in and do the work. The list above is a collection of issues and observations I’ve been keeping track of over the last week or so. I had intended to sit down and knock them all out in a focused work session, but it was tougher than expected to get started.

One thing that helped was a hackathon member pointing out problems with the X search functions — specifically that some posts are not showing up correctly in the standard URL searches. That motivated me to spend about an hour and a half working in Codex, developing a clearer plan for the dashboard and refining it into something I liked.

Building with Codex is fun. I’m very glad I have enough coding background to not be afraid to dig down into the code when needed. Honestly, some of these tasks would have taken me an entire afternoon or longer on my own, especially the kinds of annoying debugging sessions where you’re stuck asking “why is this even breaking?”

It really does feel like a gift. It’s not without drawbacks, but building with Codex is allowing me to build the kinds of things I actually want to build. A lot of these improvements are fairly simple, but they are very focused on making the dashboard genuinely usable.

At this point, I feel the dashboard is becoming usable enough that I want to start getting feedback on it.

My next steps are:

gather feedback from builders
plan a dedicated feedback session
continue attending the GameChanger live coding sessions on Tuesdays at 15:30 UTC
- it was nice hearing other builders actively working on their projects

After that, I really want to think more deeply about the final product I want this playbook to become.

I think there’s a considerable chance that Gimbalabs will run this hackathon format again in the future, and that realization is motivating me to turn this into a reusable product — something that could help others recreate and facilitate this style of builder season themselves.

OK — in the interest of brevity, I’ll stop here.

The Codex Plan aka "Mr. Codex sez"

Summary - Dashboard + Automation Cleanup

Implement four coordinated changes:

Replace ignore with active across builder registry parsing and docs.
Make the daily activity workflow also deploy GitHub Pages so the public site refreshes after snapshot updates.
Shorten the dashboard by prioritizing recent commits, removing the builder-by-builder X search table, and collapsing the remaining X search area with simple native HTML.
Make builder X handles clickable in the dashboard Builders table.

Key Changes

Registry semantics:
- Update config/repos.yml usage so active: false excludes a builder from site output and activity ingestion.
- Change the registry loader to treat missing active as active by default.
- Remove ignore from docs/examples and replace it with active.
- Update any ownership/source-of-truth docs that currently describe ignore.
GitHub Actions:
- Convert the scheduled update-activity workflow into the daily source of truth for both data refresh and Pages deployment.
- Keep the existing build steps, commit/push updated activity.json and project-metadata.json, then build the Pages artifact and deploy in the same workflow run.
- Retain the separate deploy.yml for normal human pushes to main, but daily freshness should no longer depend on that push triggering another workflow.
- Add whatever Pages permissions are needed to the scheduled workflow so it can upload and deploy directly.
Dashboard layout and behavior:
- Move Recent Commits above the Builders table, directly after the summary cards.
- Trim commit messages in the recent-commit feed to a fixed reasonable preview length, preserving the full commit via the existing link.
- Remove the entire Builder X Searches section from the dashboard.
- Keep Weekly Global Searches, but wrap it in a native
  disclosure so it is collapsed by default with no JS dependency.
- Keep the existing X summary cards unless they become redundant during implementation.
Builders table:
- In the dashboard Builders section, render the X handle as a clickable https://x.com/{handle} link when present.
- If the table does not currently have an X column, add one; if it already gains the link through a different layout tweak, keep the simplest readable version.

Public Interface / Content Changes

config/repos.yml contract changes from ignore: true to active: false.
Builders are considered included unless active is explicitly false.
Dashboard content changes:
- Builder X Searches removed.
- Weekly Global Searches becomes collapsible.
- Recent Commits appears earlier and shows shortened commit text.
- Builders table exposes linked X handles.

Test Plan

Registry:
- Confirm a builder with active: false is absent from the homepage facepile, dashboard builders list, builder detail pages, and activity snapshot generation.
- Confirm a builder without active still appears normally.
- Confirm no code path still depends on ignore.
Dashboard rendering:
- Build the site and verify section order: summary cards, recent commits, builders, X weekly searches.
- Verify the Builder X Searches section is gone.
- Verify the Weekly Global Searches block is collapsed by default and expands with native browser behavior.
- Verify long commit messages are truncated cleanly without breaking links or timestamps.
- Verify builder X handles open the correct X profile URLs.
Automation:
- Review both workflow files for valid trigger/permission structure.
- Ensure the scheduled workflow contains both data refresh and Pages deployment steps.
- Ensure the manual/push deployment workflow still remains valid for normal site changes.

Assumptions

active fully replaces ignore; backward compatibility for ignore is not required.
The simplest toggle requested is native
/
with no JavaScript.
The collapsed section should be the remaining X search area, not the core activity or builders sections.
“Reasonable” commit shortening means a fixed preview length implemented in template/filter logic rather than CSS-only clipping.

Project Management and Kanban going in again

2026-05-27T00:00:00Z

Today we created the Work Breakdown Structure document and imported it into a GitHub Project using Codex.

I've always wanted to use a Kanban board. The approach makes sense to me, but I've rarely been able to use one consistently across a project. Lately, though, I've been thinking more about how to manage time effectively while juggling multiple projects, and it feels like the right moment to give Kanban another serious try.

This also aligns with a broader goal at Gimbalabs. We used Notion for project management in the past and later moved toward GitHub, but we never fully committed to using GitHub Projects as our primary project management system. I've seen many open source projects use GitHub Projects effectively, and I'd like to better understand how it can support community-driven work.

One thing that feels different now is the arrival of AI assistants. Creating a project board is one thing, but maintaining it has always been the harder challenge. With tools like Codex and ChatGPT, I wonder if project boards will become easier to create, update, refactor, and keep aligned with reality. I'm curious to experiment and learn what works.

The Builder Season Playbook is giving me an opportunity to explore these ideas in a real project. My hope is that by the end of this season I'll have a more informed perspective on project management systems, and perhaps something useful that Gimbalabs can apply when the next season begins.

codex sez: • Saved the generator as scripts/update_work_breakdown.py.

Run it with:

./scripts/update_work_breakdown.py

It pulls Project Newman5/3 via gh project item-list and rewrites templates/admins/ work-breakdown.md from the Project items.

We set up GitHub project management for Builder Season Playbook.

Main outcomes:

Authenticated gh with repo and project scopes.
Created GitHub Project: https://github.com/users/Newman5/projects/3
Created 109 real GitHub Issues from the WBS, #2 through #110.
Added all issues to the Project.
Created labels for:
- priority
- effort
- artifact type
- epic
Created 8 milestones from W5 Foundation Package through W12 Release.
Added Project fields:
- Kanban Status
- Epic
- Priority Tier
- Effort
- Artifact Type
- Target Week
- Dependencies
Populated Project item fields from the WBS.
Updated templates/admins/work-breakdown.md so it is now a local snapshot of the GitHub Project, with the Project as source of truth.
Added scripts/update_work_breakdown.py to regenerate work-breakdown.md from the GitHub Project.

Current repo changes:

Modified: templates/admins/work-breakdown.md
Added: scripts/update_work_breakdown.py
Existing untracked file still present: web/src/posts/2026-05-27-project-management- and-kanban-going-in-again.md

Useful command:

./scripts/update_work_breakdown.py

That refreshes the local WBS from GitHub Project Newman5/3.