<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Projects on Jim's Notes</title><link>https://shizhi3620.github.io/en/tags/projects/</link><description>Recent content in Projects on Jim's Notes</description><generator>Hugo</generator><language>en-US</language><lastBuildDate>Mon, 07 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://shizhi3620.github.io/en/tags/projects/index.xml" rel="self" type="application/rss+xml"/><item><title>A Public Project Retrospective Starts with Verifiable Records</title><link>https://shizhi3620.github.io/en/posts/notes-from-a-public-project-retrospective/</link><pubDate>Mon, 07 Sep 2026 00:00:00 +0000</pubDate><guid>https://shizhi3620.github.io/en/posts/notes-from-a-public-project-retrospective/</guid><description>&lt;p&gt;A retrospective for a public project can easily collapse into outcomes: what shipped, what feedback arrived, and what might come next. The more useful part is whether people can understand and revisit the trade-offs made along the way.&lt;/p&gt;&#10;&lt;p&gt;I separate a retrospective into three layers. The first is verifiable fact, such as public commits, documentation, issue records, and release notes. The second is the judgment at the time: why one problem came first and another option was postponed. Only the third is personal feeling. It can clarify context, but it cannot stand in for evidence.&lt;/p&gt;&#10;&lt;p&gt;This approach helps in two ways. Collaborators get a project history rather than a collection of disconnected links. I get a record of the conditions behind a choice when facing similar constraints again, instead of relying on a vague memory of success or failure.&lt;/p&gt;</description></item></channel></rss>