Peter Donker wrote
To Jan and Craig,
I understand that frankness in no way means you want to impede the project and I certainly don't take it this way. In fact, I'm happy some people are taking the module to its limits as I have limited resources (that some of you guessed rightly above). Every module that I make I am inextricably bound to however, and it is obviously not the greatest read just before going to sleep that something you made s*cks. But again: we need people to run the module and I need your feedback.
So let me elaborate on resourcing for a second. There has been a pinned post at the top of this forum by Phil advertising to apply to become part of the project. I left it there as it still stands. To this day the total nr of reactions: 0. Add to this that I don't want to drag just anyone into this project and you get the picture: I'm doing this by myself. Last year I met someone that wanted to participate on a trip in the US, but this person has since gone AWOL. It is very very hard to get good and dedicated people to do Open Source development. This goes for me as it does for the wider CT.
As team lead and developer I concentrate on a number of things: a solid base of core features but not getting dragged into fancy whistles and bells (let the commercial vendors do that) and manageability of the codebase (i.e. refactoring when you can).Testing is always something that is done in 'the time remaining'. There is also a catch here: if you're the developer you test all along while building and ideally you should not test as you'll just repeat what you've been doing. Instead it'd be a lot better if I had some resources that would help with this part. This is why I took the step of publishing the 04.00.01 beta through this channel even though this is 'bending the rules' (DNN prefers me not to make anything 'officially DNN' available anywhere else than on dotnetnuke.com and this was hosted at my own site).
So to recap: this is not a perfect world, but we do our best at DNN to make it so. The procedures Sebastian elaborated on are put in place to prevent the mishaps that occurred but as we saw we simply lack the resources to make this watertight. I look forward to working with both of you in the future as I prepare new versions. I have submitted 04.00.01 in the tracker as I did not read about any showstoppers in this thread (I believe Jan was not struggling with the module per se, but with the larger setup). I'd like to have it released asap as there are many people that have installed or are enticed to install 04.00.00. At the very least 04.00.01 is a much better module than 04.00.00. After this is pushed through we can think about addressing things like performance again.
Have a nice weekend,
Peter
Peter
Thank you for your comments, To be absolutely clear, I would in no way say that your module "S*cks", Im my opinion I would only say that as a replacement for the previous it was not ready. As I have mentioned previously, you module meets a design spec, you have designed it to be standards based, and this is where it first raised issues. Now tht 4.00.01 was made available as a "Hot Fix" we are seeing some performance issues. This in my opinion is part of the development evolution and in no way unique to you or your module, the real issue here IMHO is that we are discovering this in production release.
From a usability testing view, I dont think the people who are reporting issues here are seeking anything other than the expected behaviour of an RSS feed module?
Resourcing, I am sorry I missed the post that you mentioned and will go back and take a look, I respect you role to seek and select the right resources for your project and I understand the difficulty in doing so, however regardless of the "Who" I feel that at less some "real world" usability testing is required , I say that in a nice way , as we as authors do not always see the woods for the trees. Certanly in my offer to assist is to help maintain the quality of the release and to provide another set of opinions that help any project maximise the benefits.
[EDIT] "There has been a pinned post at the top of this forum by Phil advertising to apply to become part of the project. I left it there as it still stands. To this day the total nr of reactions: 0"
I just checked Phil's post that you mentioned, I notice that the post does not permit replies!
Having developed and trained in DNN module developmemt, I uderstand the effort required to create a "production" ready module, I undertsnad that considerable effort goes into the core design (import export search etc) even before you get into you modules functionality, this is a lot of effort, however equally important is Documentation (so that people understand the designed functionality, Expected results), (how to you build a test case if people don't know what the expected results are), and testing both unit and usability testing. This typically is a big job for a project manager\developer to do effectively. While it is not impossible it can result in some degradation of quality.
Early release of a fix (4.00.01), while I understand that any early release does not go through the release process, I do not support the DNN Corp view that you mention, even Microsoft provides "Hot Fixes" to assist consumers between offical releases. I extend credit to you for providing a fix for these issues. I am sure thn DNN Corp could provide a Hot Fix process with a disclaimer to advise that the hot fix has not gone through the normal release process and use is at the users risk.
I feel that we have two main user types (DNN Consumers), those who just grab the latest software and apply to production installations, then deal with any problems (with urgency) and those who test, approve and release into production. In my case nothing goes into production until it passes our internal testing, if it fails then it is common for us to repackage an update without the failed components. Hence we do not expose issues into production. In our case version 4.00.00 did not create ay "panic' because it never reached a production release, however others who may not go through our own release process would have experinced some grief because the module was "released"
I would formally offer any assistance that you may need to help, however as you point out it is not an easy road dedicate value to the open source community as well as making a living in the challenging world, In the short term I would be happy to provide a level of usability testing and to report any findings, who knows what may develop in the futiure.
Peter, a final word on "Breaking the rules", the world breaks the rules!, loom at the variations from the standards for RSS feeds, It is common for rules to be broken, the difference is the reason for breaking the rules - in your case it was for the good of the project and the reputation of DNN, your fix will elimiate a large number of issues that would have been experienced by end users. If you had broken the rules for say not implementing "Import\Export" or some other module requirement then this is probably "breaking the rules" for the wrong reason.
Peter, I agree with your comments, we are friends here and my frankness is designed to be constructive.
Have a great weekend!
Craig