The periodic roadmap update: I'm still plugging away on Yakread; the current overhaul should be released sometime next week, and then I'll spend the rest of the week knocking out as much of the remaining todo items as I can. (The unfinished, not-officially-released complete rewrite of the app is available at http://yakread.com/home, see also https://tfos.co/p/yakread-rss-recommendation/ about how the recommendation algorithm works). Starting on the 22nd I'm switching back into Biff mode, and will concurrently be marketing yakread/looking for consulting clients/possibly job hunting. So the longer that phase takes, the more Biff stuff I'll be able to get done 😉. I've been thinking that I should shift gears a bit with Biff and focus on facilitating community contribution, especially in the form of how-to docs. All the feature work I've had in mind would work perfectly well as how-to blog posts and the like. I'd like to make a roadmap document that lists the most important how-to docs I'd like to have, with links to github issues/discussions for each one, where I'll write up any additional notes I have. I'll add a "How to" page to the Biff website which will have links to any relevant posts, whether written by me or from the community. Posts don't need to be long; could even just be a quick github gist depending on the topic. Once all that stuff is in place, I'll start working through the documentation roadmap myself, and any contributions anyone makes will be most welcome. Besides that I'll also write a few more essays and make a few videos. I'd also like to set up a similar roadmap for platypub so it's easier to contribute to--I have the same feeling there that I should focus on facilitating contribution rather than trying to power through it myself. At least I did manage to re-architect the theme system, which was probably the most complicated thing that's been needed lately. As far as Biff's code--I don't really have anything on the todo list that feels urgent to be honest. Better to just focus on docs I think. I think the ideal process is that new Biff features start out as how-to docs, and if it feels like something would make sense to be in Biff core, then I'll move it in. So the goal is to have Biff core always be small and focused, but then also have a comprehensive content library for ~anything else you might need (the latter of which would ideally also have a lot of value even for people not using Biff!).