Wayne et al,
> 1, Run vs S&P mode
> It has been my opinion for a very long
> time that modes cause more problems than they solve?
I agree. The F-buttons are enough.
> 2. zooming of the bandmap. how useful is this to you?
Not at all.
> 3. The reviewer takes away points from WL because its windows
> can be docked
> instead of floating on the desktop. Surely I should not
> remove this feature from WL?
I find the current solution OK.
> 4. The review takes away points from WL because we don't
> update the software in real time during contest weekends and
> "updates come out infrequently".
I strongly disagee with the concept of live updates. I do SW testing and
acceptance for the living and I would not take the risk of taking a not
sufficiently tested SW into a live situation.
> Would users really prefer that the
> beta tests be publically available?
Yes. I would like to see public beta releases. The more testers you have,
the bigger test scope you get thus the probability of finding faults would
increase. You maybe should have test object owners or a beta test
coordinator who takes the load of the programmer to filter and organize
feedback.
> 5, the way we manage the country files and multiplier files
I agree with the current implementation and would like to thank to AD1C for
his work.
I agree with the differences with the UPGRADE vs. FULL versions distribution
policy. However, I would like to see the full package also available for
download to get an updated reference dump when need to do a full install.
With the current policy I have to look at the latest full version I have and
execute all the upgrades that came in between as I don't have full
visibility of the changed content and don't know what will miss if I skip
one. (In addition I don't think that the current policy of provinding full
installs with the codes and its avialbility only upon request would block
any serious piracy attempt)
> I invite email comments to any or all of the above, either
> direct or on the
> reflector. I personally value thoughtful answers the most
> (and prettymuch
> ignore flames and my-dog-is-better-than-your-dog comments)
> and I try to
> thoughtfully consider recommendations. However, I don't
> promise any action
> or even a response to any email (and I confess that I am
> guilty as charged
> in the review of not answered 100% of all email queries I
> get--I have no excuse.)
Yes, this is actually what I consider the a bit a problem with Writelog
management. Once you wrote that you can't act upon last minute fault
correction requests. I Agree. OTOH, you often do not react to fault
correction requests done months before the next appearence of the contest.
Sometimes you do, sometimes you don't and I haven't manage to find out what
the triggers are. :)
Maybe what you want is a web-based fault-reporting system, where the beta
testers or programmer could verify the faults reported and would insert the
verified and reproducable faults into the scheduling of the development
process allowing the programmer enough time to code and the users to get the
corrections in time. Seeing that a fault reported is taken care gives much
more confidence to the user (and spares his time, too).
I hope you will find this useful.
73,
Zoli HA1AG
_______________________________________________
WriteLog mailing list
WriteLog@contesting.com
http://lists.contesting.com/mailman/listinfo/writelog
WriteLog on the web: http://www.writelog.com/
|