Because I might want to go back to this current messy state but I don't want to commit it like this (hardcoded test strings, debug logs, cutted corners to see if something works, you name it).
I simply commit something like "WIP: testing xy" and if its working and properly implemented i can squash/rebase/edit the commit message and force push it to my feature branch.
Using a Git client like Gitkraken makes this incredibly easy, takes seconds.
This way I can leverage version control without committing bogus states to the final PR.
It depends on the theme. If we're picking something in a space the group already knows well, like databases, I'll look at "Best Papers" from recent VLDB/ICDE/SIGMOD conferences. If we're exploring a topic most people are unfamiliar with, we'll go with something more foundational instead. For example, we're starting an arc on datacenters (servers, racks, networking, load balancing, power, cooling, failures, etc.), and most attendees don't have deep background there, so I found a book on the topic that we're going to read through[1].
Not author, but in the past I was just going through papers on biggest conferences for the last year and checked what sounded interesting for my own education. But it was a bit of a chore. What I tried now is use gemini thinking research and asked it to do just that, go through main software/hardware conferences for last 3 years, find me papers on the topics of interest and give summary and links. The result is pretty good!
reply