Last night I visited a WiX night after a very long absence.
After watching the Sounders 2-1 US Open Cup victory via the internet, I was asked: here to fix a bug or ...? Initial answer: I don't know, I'm just trying to figure out what's going on.
I casually asked what I hoped would be some orienting questions. Turns out there were no answers and that it wasn't different than before. A subtle reminder of the difference between "traditional" and open software development models.
I switched to lurking and listened to the banter that went around the room. Someone was picking up a drop into their product thus needed to root cause integration breaks. Someone else was orienting to the extension architecture underlying the core tool set to figure out an architecturally consistent place for a bug to be fixed. Another thread correlated an observed class of Windows behaviors with the various locations in the Windows technology stack the behaviors originated. I started to remember how this worked.
After lurking a while, fixing a bug seemed to be the place to restart. It had been much longer since checked in WiX code (~7 years?) than my last WiX night visit (~5 years?). Time to knock off the rust.
On the way to submitting a fix SourceForge Bug 3297725, there was a lot of rust to knock-off. How does one enlist again? What developer tools do I need? How does build work again? How do those unit tests work? How does the SourceForge bug tracking work? How do code reviews work? Finally: oh yeah, that's right, this language (C#) is different than my day job language (PowerShell).
After my first fix was submitted, I started to look at a harder Source Forge bug (3304311) in dark. Test driven development would require much more effort here than the last bug. Doing the right fix wouldn't fit in this WiX night so I packed up and headed home.
WiX night dynamics remain fascinating. While a few parts were familiar, most parts were not. Familiar and humbling.