Quantifiable Metrics for PhysLean

Stream: PhysLean

[Shlok Vaibhav]

I found these two articles that explain the philosophy behind need (or futility) of metrics:

1. https://www.linuxfoundation.org/resources/open-source-guides/measuring-your-open-source-program-success
   (Written for managers of projects with more emphasis on tracking performance)

2. https://opensource.guide/metrics/ (Basic guide from GitHub)
   I think I guess metrics best emerge in top-down fashion in an open-source environment, the manager has the highest amount of information and agency about the goals, stakes and resources at hand so as to decide what insights needs to be gained for decision making and how to monitor health of the project. Once this is decided, everyone can debate what exact metric or formula furnishes the required information most faithfully.

[Notification Bot]

A message was moved here from #PhysLean > PhysLean in 2026 by Joseph Tooby-Smith.

[Joseph Tooby-Smith]

From my point of view, I think the most important metric to track (in terms of goals rather than e.g. usage) is the building of APIs. I made this a while ago:

https://physlean.com/APIs

But I don't think this is nearly as much detail as what would be necessary. Another metric to use would be the formalization of e.g. a book - as has been discussed with e.g. Landau and Lifshitz.

One slight annoyance is that even building such metrics would require a lot of work (e.g. working out exactly what APIs we want, with what requirements etc, or theorems from books), that those processes in themselves likely benefit from their own metrics to measure progress and incentives.

The other thing I was thinking in this direction is to set ourselves a goal for 2026 e.g. "The addition of five informal results per week" to the project, and to make a weekly announcement of what informal lemmas have been added and by who.

[Joseph Tooby-Smith]

@Shlok Vaibhav (Also just pining you here as I moved this chat to a new thread, and not sure how e.g. notifications work when this is done)

[Joseph Tooby-Smith]

Maybe this is somewhere we could generally utilize GitHub issues more effectively.