This is similar to a discussion I had earlier this week about fixing the issues I found in DataGrid.
However, what do we do about OnRev, especially if we are going to work on it as a group of sorts? On Thu, May 15, 2014 at 4:29 PM, Richard Gaskin <ambassa...@fourthworld.com>wrote: > 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 > rich...@livecode.org > > > > _______________________________________________ > use-livecode mailing list > use-livecode@lists.runrev.com > Please visit this url to subscribe, unsubscribe and manage your > subscription preferences: > http://lists.runrev.com/mailman/listinfo/use-livecode > -- On the first day, God created the heavens and the Earth On the second day, God created the oceans. On the third day, God put the animals on hold for a few hours, and did a little diving. And God said, "This is good." _______________________________________________ use-livecode mailing list use-livecode@lists.runrev.com Please visit this url to subscribe, unsubscribe and manage your subscription preferences: http://lists.runrev.com/mailman/listinfo/use-livecode