Hey @alexmiller, I'm curious about your approach (and the clojure core team in general) to deciding which bugs to fix or even what counts as a bug. For example, I ran into the issue detailed in https://clojure.atlassian.net/browse/CLJ-2640 - "ex-info should be tolerant of nil data param" where an argument with map destructuring is nil and is passed to ex-info . I handled it as described in the ticket (`(ex-info "message" (or m {}))`) but it felt like a place where ex-info could just "do the right thing". What led you to the decision to not merge the patch? Or request an alternative version of the patch that makes the change in a new way.

just hasn't gone through the process yet

My apologies, I don't mean to ask directly about that one necessarily, I'm purely curious about your process. Hoping to better understand it as I recently added a patch for clojure.test and don't have a good frame of reference for how things work

If it's helpful, I'll pop this in the chat in case it's helpful: https://clojure.org/dev/workflow

that's the overall process but of course there are vastly more things to look at than we will actually have time to look at, so I assume your question is how do we pick

Fogus and I build target lists to go through with Rich - those are a combination of things highly voted on ask clojure, things of high priority (based on other time swept sweeping through big issue lists and prioritizing), and generally things people regularly ask about

we've built some lists for 1.12, Rich hasn't looked at any of it yet

On the subject of 1.12, I still have regular reminders popping up about that stability issue I reported with the alpha but haven't yet had the space to put a version of the problematic app in production with the alpha in order to get thread and heap dumps. I will get to it. Maybe next week.

I didn't realize every single patch still had to get explicit approval from Rich, that's interesting. Cool, thanks for the explanation