Feedback changes

I probably should not write this first paragraph publicly. The beta list has been awash lately with phrases like, "I really like this new spirit of openness," "thanks for keeping us informed" and even "thanks for listening, the changes are much better than your original proposal."

And then comes the announcement that the current feedback system is being replaced and will no longer be searchable. We can no longer see other people's reports.

Within seconds, I hit the bookmark to my watchlist, so I could pdf my outstanding reports.
But they had already gone.

That's what really irritates me. The sudden withdrawal of the data I keep around to remind me of workarounds to bugs I or others have already found.

If RS need a better project management system, it hardly comes as a surprise.

If they want to use its built-in bug-tracking, I hope and expect it will work better for them.

If they have decided to use a hosted system rather than host their own copy, who am I to argue.

And if they don't want to waste resources creating non-standard versions of FogBugz, nobody will suggest they look like a company with engineers to spare.

Other people complain that thousands of customers are being asked to waste their time to save a bit of centralized time at RS. This may be true but it may well be worthwhile.

It's the lack of notice that leads to the conspiracy theories.

What could be a possible motive for withdrawing the old data?

• RS don't want the world at large to be able to see how many bugs they have?

What could be a possible motive for giving no notice?

• To make it more difficult for some third-party to compile a website (wiki?) listing outstanding bugs?

It may well be that neither of these is the case.

It may well be that RS's normal policy of secrecy has engendered an attitude where, when considering a change, nobody even thinks to ask until the last minute, "How should we communicate with our customers to cause least upset?"

Personally, I really hope FogBugz works well for RS and I'll live with whatever decisions they make about customer access.

If I find a bug that doesn't affect me personally, it's quite likely I will assume somebody else has reported it.

If somebody else posts a bug to a mailing list or forum that does affect me, it's quite likely I will assume they may not have reported it and will paste a copy of it (altered as required to fit my personal prejudices) straight into the feedback system.

I'm sure somebody else will provide hosting for a public bug-list out of RS's control.
If so, I will do my best to contribute.

And just for the record, my business doesn't rely on RB at all.

So if I see RS getting heavy-handed with anyone that tries to maintain a public bug-list, I will just decide that RS is not a company with whom I need a business relationship any more.

It's a real shame I am even beginning to feel that way. My goodwill towards RS has been sky-high lately because stuff seemed to be moving in the right direction.

If I had had a few days notice that my watchlist was going to disappear, I would be slightly irritated but would now be posting "give it a while to see how it works" messages in reply to the current storm of complaints.

Yuma

I've been playing with Yuma and it's great fun.

I've got a lot of learning to do but I thought I'd mention one or two bits I've found useful.

I have an include file called myGlobals.yuma which includes methods

Sub MsgBox(s As String)
Function MsgBox(s As String, buttons as Integer) As Integer
Function MsgBox(s As String, buttons as Integer, Title As String) As Integer
Sub printLine(s As String)
Sub printParagraph(s As String)
Function lineBreak() As String
Const TargetYuma = True

The msgBoxes are just to stop test code falling over when I compile for RB and Yuma.

The other methods are for simpler formatting within Yuma and try to make the source a bit more readable when adding breaks or paragraphs to the output.

TargetYuma helps with conditional compilation.

In my RB code, I use a similar module which stops the RB code from falling over by having methods

Sub print
Sub PrintLine(s As String)
Sub printParagraph(s As String)
Function lineBreak() As String
Const TargetYuma = False

I save the project in VCF format, so picking classes and modules and converting them to Yuma then becomes a breeze.

Some of the very simple stuff I've tried so far is available for download from my website but please be aware that site is not running Yuma. The .yuma files need to be downloaded and tested on your own yuma development server.