> It's interesting: I think we mostly agree but because of some of my > pointed language I may be triggering a reaction in you that is > obscuring some of that agreement.
I think that the 'pointed language' on *both* our parts is a result of the long-term frustrations with the process. Regrettably, those frustrations sometimes lead to a bit more 'heat' and less bit less 'light'. Thanks for looking past the words to get to the meaning. > * "Core maintainers should be responsible for announcing > changes in good time and providing suitable beta periods (in the order > of weeks not months)." [1] > The most important of the above list is the first. Your response reads > as if I either didn't say that or you didn't acknowledge it. I did read that, but I suppose it didn't stick in my head as your main point. Mea Culpa. > I suspect some of the confusion here is that you are lumping the > various people who have some association with Osmosoft with the core > maintainers of TiddlyWiki. Actually, I wasn't thinking about individuals at all. I was thinking about the general 'core team' role, whether within Osmosoft or otherwise. > So, effectively, if I may interpret FND, we're railing against the > status quo as you, and attempting to stimulate ideas to change it. Yes. That's the *entire* purpose... to stimulate *ideas* to change it... I'm just adding my thoughts to the pile in hopes that some pretty flowers will grow. > incredibly frustrating ... to find myself now lumped > in with the problem rather than solution... Profuse apologies! Despite the somewhat accusatory tone of my posting, I wasn't trying to 'point fingers' at *people*. I think it's just a result of accumulated frustrations with the *process*. > My feeling is that we are mostly likely to come to a robust solution if > we are forthright about the issues we have encountered. > There seem to be several different strategies floating around and > presumably we can cherrypick the best parts. Again, YES! That was my entire intent.. to be as "forthright" as possible about the issues, so that a variety of views can be considered and the best combined solution arrived at. > Critical to this is communication; dynamic and full-throated dialog > that does not languish. Tickets are a good example where this falls > down for TiddlyWiki, but so is this group: There's _very_ little talk > about the state of the core on this group. It's generally about > plugins. I used to push hard for core changes. I'd write tickets, create patches (which I couldn't actually submit), publish CoreTweaks (to get a viable solution into the field quickly), and spend a lot of effort advocating for putting fixes (*small ones*) into the core. At my request, we periodically had lengthy (and somewhat contentious) conference calls to discuss open tickets, and I'd regularly (daily) review all code submissions to look for possible red-flags (in terms of impact on the installed base). Unfortunately, *most* of the time, it seemed there was a significant amount of resistance to making core changes (except for changes originating within Osmosoft), and the response was typically along the lines of "well, if Eric has a plugin/CoreTweak for it, then it doesn't belong in the core." Except... for many cases, the plugin/tweak that I created was just a 'monkey patch' of the core code, and really was intended to provide a more immediate solution (and some real-world field testing) so that TiddlyWiki users can achieve their goals without waiting for "the next release" to fix their problems. The conference calls were the most frustrating experiences! I'd start with a pre-selected list of "important" tickets that I'd culled from the larger list of open tickets, and *hope* that I might get just a tiny few of them accepted and fixed. Typically, out of 20-25 tickets discussed, perhaps 3-5 would be accepted (i.e., planned to fix in the next release). Sometimes, even *after* extensive discussion and apparent agreement, some of the changes in the accepted tickets would still not make it into the core code, or would be implemented differently (resulting in subtle differences in usage or effect). Basically, after a long time of feeling like I'm on the outside, cut out of "the loop" and banging my head against a brick wall, I gave up trying. > I personally would like to see more core commits/patches from Eric. > I think this would a) help move things along, b) increase the > diversity in the code base, and c) be a good example for other people > who want to get their changes in the core. TiddlyTools' CoreTweaks is my way of publishing patches without having to fight the uphill battle to get them into the TW core. Initially, CoreTweaks' purpose was to get solutions into the field quickly and field-test the results to demonstrate the value and viability of the changed code. The intent was that CoreTweaks would be *temporary* fixes, not permanent core overlays, and that when a CoreTweak is added to the core, it is retired from the plugin. Intially, this worked reasonably well. Unfortunately, due to the resistance to change I described above, most CoreTweaks for the past few *years* have remained as tweaks and have not been added to the core. > We've both had a lot of experience in the software world, Eric, and > I'll simply respectfully disagree with you on this one and leave it > for another thread if we want to give the wide-adoption topic the > attention it may deserve. Indeed. A topic for another thread. I'll just say this: Business users require a stable, reliable platform for conducting mission-critical activities. Software upgrades are generally highly- planned, phased roll-outs. Most IT departments reject (or at least resist) any upgrade process that has too many issues or requires extensive hand-modification of individual installations... and, if there are *any* failure points in the upgrade process, including (and especially) lost/damaged data or broken functionality, most IT people start looking for other software to use, rather than take the risk with their business. > We agree on this up to the point of "provide *whatever assistance is > needed*". It's a bit much to expect more than effective communication > of changes and strategies for coping with them. The core developers > are not a support team. In general, I agree with you on this... However, in my opinion it is in the best interests of core developers to actively support changes in their code by assisting other developers (i.e., plugin authors) in responding to those changes, even to the extent of taking a bit of time to help investigate/debug 3rd-party plugin code. Writing and releasing updates to core code is not the *end* of the process. The goal here is to make *everyone* successful and, in practical terms, the core developers are in a position to do that, since knowledge of the core changes starts with the core developers themselves. > > ... and, failing to ensure that the upgrade process is smooth and > > uneventful for the end-user gives the impression that TiddlyWiki is an > > unstable "hobby" project that *cannot be relied upon* as a safe place > > to keep your important information (which we *know* is not true?!?) > > This is where I think you are starting to willfully misinterpret my > goals. If there exists an effective range of communication by those > people maintaining the core, then they will do what you suggest: > Provide enough information so people can make informed choices about > upgrading. Actually, I was responding to your statement that the current core process (or lack thereof) "gives the impression that the project is neither healthy nor maintained, which we _know_ is not true". My point was that, similarly, when existing content fails as a result of a core upgrade, the *impression* is that TiddlyWiki is an "unstable hobby project that cannot be relied upon... which we _know_ is not true"... leading to the same question you asked: "how do we change things so that that impression is not given?" > Yes, on this we are 100% in agreement. Despite a bit of frustration in the tone of our conversation, I think we are on the same page. I have confidence that, after sufficient discussion, the technical aspects of the new development process will be robust and more effective than the current process. Where we perhaps differ somewhat is in the manner and extent to which 'community-based' support issues should be incorporated into that process. My focus is, and has always been, on the community. In addition to my role as plugin developer/wizard, many people regard me as an advocate/evangelist, operating as a liason between the 'outside' (users and document authors) and the 'inside' (plugin and core code developers). It is mostly in this capacity that I am contributing to the current discussion. Summary: we agree, with some minor differences. Extra thought: THANK YOU! This is the discussion we've been needing for YEARS! -e -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
