Hi all, Over the past month or so development has been proceeding apace on the unit refactor in Matt's fork of yt. We did this because Matt initially opened the unitrefactor PR and at that time it was not ready for merging. However, thanks to everyone's hard work, unitrefactor is getting more and more stable and I think it's time to think about merging it into the main repo, even if there are open issues or some remaining bits of functionality that haven't been updated yet. With tons of development going on in Matt's fork, I think we're possibly leaving out people who aren't watching his repo. Additionally, since Matt is the only one who can merge pull requests into his repo, we need to use a lot more of his attention to keep work moving forward. It's true that there is some functionality that still needs to be ported and bugs that need to be fixed. Matt's trello board summarizes most of the issues (BTW, I see a couple missing issues, would you be open to adding more users to it?): https://trello.com/b/yv7o0dTp/unit-refactor One option would be to open a new named branch in the main repo, while still keeping the current 3.0 tip in a 'stable' state. I'm less inclined to go this route because I think unitrefactor is such a big improvement over the current codebase, since many new features have snuck in besides just adding units. Another concern is that there aren't any docs yet. That's definitely true, but there aren't any docs for the current 3.0 tip either. In fact, now that there are a set of docs bundled in the repo in the unitrefactor bookmark, merging should improve the documentation effort for 3.0 going forward by making it more straightforward to enforce a rule that things need to be documented before they get merged. What do you all think? -Nathan