I would also like to have a "class" on hacking the IDE, so when we are breaking things to look cool, we aren't doing something that will make our work harder to accept.
On Sun, Jun 8, 2014 at 7:31 PM, Richard Gaskin <ambassa...@fourthworld.com> wrote: > In another thread the topic came up about moving our open source process > forward with the IDE. Let me describe some of the current options already > on the table, and invite your suggestions for others: > > > There are challenges with any open source project, and with LiveCode > they're made even more complex by not being able to easily use > off-the-shelf systems for our unique stack file structure. > > So in the interest of helping to find ways to move things forward with > what we have now, members of the community and the core team at RunRev have > been taking on some initiatives toward that end. > > As with just about any component in any software project, we can expect > that the IDE we currently use will eventually be replaced with something > better suited for the engine as it evolves. > > Ideally that process will include a lot of community contribution, and > indeed Ben and others at RunRev have noted that much of the long-term > planning revolves around community-driven components. However, dependent > as it is on specific engine features that don't yet exist, I wouldn't > expect it soon. > > In the meantime, there are bugs in the IDE and opportunities for > refinement, and these can be done with the assistance of the community if > anyone here is up for it. > > In broad terms: > > - Forums as a central working group resource we can use to explore ideas, > assemble teams, and manage projects > > - Experimental "FIX:" protocol in the bug database > > - Forking to explore radical design initiatives > > > In more detail: > > > Forums as Working Groups > ------------------------ > To help move things along, Heather elevated my privileges in the forums so > we can create new sections as needed to form working groups for IDE > projects: > <http://forums.livecode.com/viewforum.php?f=67> > > The protocol used there is an attempt to bring some of the things I've > seen work with other projects into this community: > > Topics are initially flagged as "Brainstorm", encouraging folks to discuss > ideas and explore the range of things they'd like to work on. > > Once a given scope has become sufficiently well defined to be actionable, > and with a team and a team leader to make it happen, we can make a separate > thread for that with the heading of "Project:". > > A few projects are underway there, mostly on the documentation side but > we've seen interest from some members of the community in helping with a > triage on RevOnline, which seems a good focus while we're all still > exploring the process because it's very valuable to the community and when > it breaks people are vocal about it. :) > > > > EXPERIMENTAL "FIX:" protocol > ----------------------------- > I really do need to stress that this is EXPERIMENTAL, so please do not > participate in this EXPERIMENTAL protocol if you require that your fixes be > acted on immediately. Have I stressed that it's EXPERIMENTAL enough? > Okay, here's the deal: > > If you have the time to fix a bug that's bugging you in the IDE, that's > the best first step because at that point we have at least one copy of the > IDE where that bug no longer exists. > > To share the fix with the core team, paste the code in your original bug > report for the item, along with the object reference and line numbers of > the script it belongs in. Once you've done that, change the Summary field > to be prefixed with "FIX:", so the team can see it's flagged as a report > that also includes a fix. > > Of course any FIX item, like any bug report, must have a recipe. If the > recipe takes more than a single line in the Message Box to execute, please > also include a sample test so the team can not only readily identify the > problem, but also so that they can add it into their testing system to > minimize possible regressions in the future. > > Did I note that this protocol is EXPERIMENTAL? On the RunRev side, things > are hectic and complex. They're willing to experiment with this protocol to > see if it's helpful, but if we see submissions lacking in quality or absent > of sample stacks, it won't help at all. So right now this is EXPERIMENTAL, > and it's up to us to make sure it's actually helpful. > > > Forking the IDE > --------------- > The IDE is licensed under the permissive MIT license, just as the MetaCard > IDE was in 2003, so anyone can modify it however they like. > > While forking can risk audience fragmentation, it can be a good choice for > impatient people or radical visionaries. :) And it can be a good choice > for making specialized IDEs for specific niches, like education. > > With a fork you're completely unencumbered by whatever long-term > considerations the core dev team has to accommodate, or any backward > compatibility any community members may expect. You can do whatever you > like, and sometimes this can be a good way to explore ideas. > > In my own view, the risk to audience fragmentation is really only a > learnability issue, since things like the User Guide by necessity will only > document the IDE that ships with the main distribution from LiveCode.com. > > But if you want to make sweeping changes beyond what RunRev can > accommodate, or just want to explore radical new designs without worrying > about compatibility, fork away. That's what the GPL is all about, learning > and proliferation. > > Another option along these lines worth mentioning is building an entirely > new IDE, either forking MetaCard or building it from scratch as Mats > Wilstrand did with rIDE: > <http://forums.livecode.com/viewforum.php?f=79> > > rIDE is an ambitious project, and rather exemplary in the the way Mats has > embraced open source process and actively invites contributions. > > > Other Options > ------------- > What would you like to contribute, and what obstacles have you found that > have prevented you from doing so? > > Let's figure it out together, and make the best LiveCode ever. > > -- > 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
