Hello, the most important task of today is the coming release. We are interested in getting it stable work ASAP. That's why I am starting with the discussion about how to let the community participate on the testing.
(NB: Certainly there are two sides: the FreeMind team and the others called community. Because the discussed topics concerns the both of them, I write into the closed freemind-developer list for the internal team discussion and to the open discussion forum to let the community to participate in the discussion too.) I start with analysis of the current project practices. Currently the Beta versions are released rather seldom: the Beta 9 is released on the 2007-02-21, the Beta 12 is released exactly 5 months later on the 2007-07-21. (The Beta 10 and Beta 11 are also released in Juli, but they have been hidden because of some bugs). Each new Beta version encourage the beta users to submit the bug reports so that the remaining bugs can be removed. In about two weeks after the beta release all most important bugs are found, and the users want to get them away. But after fixing of the annoying submitted bugs (which takes in the most cases about a week) the freemind team does not immediately produce the next bug fix release. Instead it works on further testing and improvements not requested by the users. The users get disappointed and send mails like > I am also wondering when beta 13 will be published. I still see beta > 12 in the download list, and the images are still broken, and editing > a node(not long), still always has the text and cursor as black, even > if I set my selected node colors otherwise. Such mails are not always answered but often just ignored. It probably reduce both the will to submit bug reports and the consequently the chances that the bugs are found and reported by the users. As a consequence the team has to perform more tests by itself which course an additional delay of the next beta release. Another point: developers are generally less effective in performing the tests than the users, because the most bugs require some special conditions to become visible. Different users handling the program in different ways are more likely to find a bug than a single developer always trying more ore less the same things. The bugs happen mostly because of some wrong dependencies between different program parts. The program seems to work fine, and one need a coincidence to see the bug. That's why many beta tester are more likely to find the bug than one developer. Now I would like to describe what could be done another way. Instead of full concentration on the testing the team (or at least one developer) could concentrate on producing new beta releases and on the dialog with the community giving them response and paying the tribute to the people submitting the bug reports. The more people get involved in the testing and above all in submitting the bug reports, the more bugs can be recognized and fixed. It requires that both the team and the community accept that the bugs are still not unlikely to be present. And I have never had an impression that the community is not satisfied with the quality of the current beta versions. Because the newer versions fixing the old bugs are better than the older once, we produce a positive feedback loop: if the bugs get fixed, submitting of the new bug reports seems to make more sense. Further I think that releasing of the next beta does not require all of the known bugs to be fixed. The remaining bugs could be just listed in the version description, because it is better to work with a version where 70% of the reported bugs have been fixed than to wait for a version without bugs for many months. Let me conclude. I think that more frequently producing of the beta versions and staying in the dialog with the community is a better way for achieving both higher user satisfaction and less error rate in the release. The Beta versions could be produced every month. I would like to do the job, but first of all the proposed ideas should be discussed within the team and within the community. I am looking forward to your responses. Best regards, Dimitry ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ Freemind-developer mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/freemind-developer
