IDE oddities (was Re: Error Messages Are Evil)

[Richard Gaskin]

Charles wrote:
 > OK, so what do we have to do, as a community of users, to get
 > RevOnline working again?

Fix it.  :)

My Community meeting this morning with Ben focused almost exclusively on 
RevOnline.

It's true that LiveCode is inherently problematic to attempt to 
integrate into tools like GitHub, not merely because it's a binary file 
format and GitHub is designed for plain text, but more because of the 
nature of the workflow in which UI and code are intermingled.  Monte's 
spent considerable time explaining the Why of that, and if needed I 
could try again, but for now the bottom line on GitHub integration is 
that it may require engine enhancements to support, and given current 
priorities not likely to happen for at least a few more months at best.

So in the absence of a GitHub workflow, clearly we need at least some 
alternative to move forward with community contributions on IDE components.

We explored a few options, but one stood out as a *possible* solution 
for modest fixes in the short term.  I'm stressing "possible" here 
because he needs to review the workflow with the team to make sure it's 
going to work, but here's the outline:


If a member of the community has time and interest to fix a bug in the 
IDE, the revised handler(s) can be added to the bug report, and the 
title of the report prepended with "FIX:" to flag it for the team as a 
report that also includes the fix.  And of course the post with the 
fixed handler(s) should note the object and line numbers where the 
original handler(s) can be found.

For any issue whose recipe requires more than running a single line of 
code in the Message Box, a unit test stack should be provided 
illustrating the issue so that it can be run before the fix is applied, 
then again after copying-and-pasting the fix to verify that it works.

Well-crafted unit tests may even be included in RunRev's internal 
collection for future regression tests, providing long-term benefit in 
addition to helping to ensure quick action on a bug.


As an example of this workflow in action, we have a simple fix here:
<http://quality.runrev.com/show_bug.cgi?id=11493>

Since the code change is comprised of adding only five characters to a 
comparison string and can be easily seen in the Message Box, no unit 
test is required for that one.

There may be reasons why they're not able to guarantee super-quick 
responses on reports using this protocol, but even before he runs it by 
the team I see no harm and potentially much good in encouraging 
interested folks to dive into fixing any issues you find particularly 
annoying, and including the fixed code in the report.


True, this protocol can only address issues of limited scope, and at the 
moment is still being reviewed for feasibility.

But the benefit of having fixed code posted to the report is undeniably 
valuable in guiding the team to the solution - all we need now is people 
in a position to supply the fixes.

That last step has been the hardest.

For example, after all the discussion of documentation issues over the 
years, once I got forum permissions to modify things there for community 
initiatives I took the time to set up a new forum section for that:
<http://forums.runrev.com/viewforum.php?f=83>

Thus far there's been some good ideas discussed, but no one in a 
position to actually act on any of them.

Many of us juggle multiple priorities, much like RunRev themselves, so I 
can understand that it's far easier to imagine fixed code than it is to 
write it. :)

It may be that we won't really see serious traction on community 
participation for quite some months yet, until the community grows large 
enough to include a greater number of people in a position to contribute.

We'll see.  But in the meantime the core dev team at RunRev is actively 
exploring many ways to incorporate community contributions for IDE 
components, and if we start seeing fixes submitted to the bug reports 
we'll be able to refine and enhance the workflow to make sure it's 
working well for all of us.

--
  Richard Gaskin
  LiveCode Community Manager
  richard at livecode.org