I see: Is anyone else from the CFWheels project here? If Tom's not here any more, I question the merits of the channel existing..? https://groups.google.com/g/cfwheels is probably a better way to go..?

Hi @Adam Cameron, as you have noticed I've stepped up to take over the reins of the project. Unfortunately the timing wasn't ideal as I was heading into a three week vacation, 4 days in Santa Barbara for my son’s wedding, 12 days in Israel for pilgrimage, and 4 days in London on our way back. We arrived in Israel yesterday so I have a couple of weeks ahead of me yet. So I have a bunch of thinks I'm thinking of for the project but they have to wait till I get back to start to implement them. Things I'm considering are moving the guides to a platform backed by git repository to make it easier for the community to contribute. I like GitBooks for this and was able to do some testing before I left to see how large of a lift that would be. I'm also exploring different funding strategies for the project similar to BountySource or IssueHunt to widen the pool of contributors. Another area that I've thought of is what you are mentioning about where to post messages. I like the community idea that Ortus is starting to implement so the messages and responses live on and don't fall of the scale since most people are using a free Slack account. I haven't really decided whether we should go the community route and standing up a server for that or go back to strictly using the google groups. But I agree with you that things are a little spread out right now between the different communication platforms. I also wanted to address some of your questions about the “CFWheels Way” of doing things. I really don't know how to answer questions like that right now cause cause I'm trying to read and internalize what the CFWheels Way really is. I can tell you that CFWheels began life as an attempt to port over Rials to CFML back in 2005. Some of the original people involved with that effort eventually moved over to become full time Rails developers. I was a member of the core team very early on and eventually stepped away from the project as my career basically took me away from development for a very long time. I know from a theoretical perspective why Rails was the rage in the early 2000’s and what the goal of the project was in its early days. I think that boils down to creating an opinionated MVC framework that relies on convention over configuration that makes the developers life easier. Some of this was by hiding the complexities of the underlying platform. There have been a lot of developments in the CF world since 2005 as well. The ones that are most profound I think are maturation of the open source CFML engine in Lucee, the creation of Commandbox with its CLI capabilities and local server launching and its package management that goes hand in hand with Forgebox which makes it easier to distribute modules and shared apps. The entire CFML ecosystem has benefited from these enhancements and CFWheels is no exception. For instance adopting Forgebox as the means to distribute plugins and moving away from the self hosted directory is a perfect example. So moving forward I would love to have discussions about the CFWheels Way, but I want to have them respectfully. I stand in a unique position where I am now the maintainer of an open source project with a 17 year track record and need to weigh things in light of the core principles of the project but at the same time I can be removed from the code since others committed it. What I won't be doing however is to demean the efforts of the volunteers that have come before me. I'm grateful for every single line of code that every volunteer has committed to the project over the last 17 years. I want to help foster a community where we can discuss the merits of something without offending anyone in the process. Having said that, I haven't yet had an opportunity to really take stock of the open issues in the repository. Need to figure out what is still an active open issue and what is stale and should be closed out. Of the stuff that is left figuring out what are bugs, nice to haves, and breaking changes. If we need to make breaking changes to modernize the framework how can we make them in a way to bring our existing community and deployed code along with us. This means not only having discussions about the merits of a change but planning those changes and mapping them out in a way that brings our existing deployments along with us. Anyway, I've rambled on for too long, I guess that's what you get when you're jet lagged and up at 4am with nothing else to do, I'm looking forward to implement some of these changes mentioned above and look forward to and welcome everyone's contributions to the project going forward.