Hi Alexander,
Regarding bugs, I fix them as soon as they are validated. There have been some where you post the needed change and some where you say the spot in the code where you "think" there is a problem and others where you described a symptom. In all cases when the bug was validated with steps to produce it and the solution proved the bug was fixed very quickly.
You cannot expect me to have the same policy for new features or feature enhancements, while you may need some new feature or enhancement right away, that does not mean I drop what I'm doing and agree to integrate whatever changes you want. You may think coordinating your desired improvements is a simple matter that only takes 15 minutes but it is not so. Any change to the database schema in any feature must be made for all supported data layers before it can go into svn which means I have to implement the changes in the other data layers that you are not using. Furthermore I have to own and support the change for it's life time, so I have to agree with the implementation.
Regarding the blog, I am warming up to the ideas for adding an option for not using friendly urls and an option for and end date and an a change so that different users with edit permissions on the blog can only edit their own posts (unless admin). As I chew on these ideas I realize that others have asked for some of this before. In the past many times people ask about a News Module, but when I ask them what they mean by a news module it sounds just like a blog and I would ask the user what is different about a news module than a blog and they would have no answer. But now I begin to think the differences are precisely, end dates, no friendly urls, and articles owned by the editing user. In the past many people have implemented a news module by using the feed manager to consume the feed from 1 or more blogs, but I think if we do make it possible to use the blog directly for this it will scratch a common itch. So I will agree to add these things to my Road Map and I will get to them sometime in the coming months.
Regarding this idea of content notes feature, I think the idea is good but I do not want to implement it as you suggest by adding fields to mp_Blogs and mp_Html. It should have a new table mp_ContentNotes so that the same notes system can be re-used in the blog and in Html feature and in the store for notes about products and anywhere else it is needed, much like content ratings or content history, it should be a core sub system that can be re-used in features so we don't have to implement it over and over in each feature. Each feature will pass in its own content guid to retrieve and update notes for the content.
About testing, I do the best I can, I eat my own cooking by deploying new builds on mojoportal.com and on demo.mojoportal.com before making releases. I am one person managing development, support, marketing, strategy, I have no team of QA testers other than the community. I assume that anyone running a big operation using mojoportal also has their own staging/testing environment and can do some testing of their own before upgrading their production environments. If someone does encounter a bug and reports it I fix it quickly, if the user has a site that is impacted in a bad way and they cannot produce a new build from svn then I offer to make a build for them or if the bug is very bad and impacting lots of people I put out a new release quickly. You have identified some significant bugs and I am planning to get a new release out soon with the fixes, but some of these bugs have been there a long time and yet do not seem to be impacting a lot of people or they would have been reported sooner. You are doing it the right way by producing your own builds since you have a big operation running on mojoportal.
About development deadlock, I disagree. Good developers can build custom features to supplement or replace existing ones or they can clone an existing one as a starting point for a custom one. If you are impatient for bog enhancements or html enhancements you could clone those features and do whatever you like so I'm not really preventing anyone from doing anything. In the core and included features it needs to be much more controlled and it has to fit in with my vision and my time table of priorities. My time is my most precious resource and I must remain in control of how I use my time and energy. Furthermore, my own development effort is advancing the project very quickly therefore it cannot truly be said that there is some development deadlock as development is progressing very well. Development is not always faster by adding more developers, it requires more formal processes and it slows down the pace of development unless you have developers who know each other well and think in the same direction.
Best Regards,
Joe