Chris's vision of an open source project: "In a modern healthy open source project, activity is focused around source code. It's right there in the name. I want to see a future where there is some person or persons "X" who maintain a git repo from which the official TiddlyWiki core is built. Surrounding this are a community of people who use it with some segment also providing help with documentation and bug reports. Meanwhile there are several active forks of the core. One belonging to me, one to FND, one to Jeremy, one to Martin, one to Eric, some belonging to people I've never heard of. Changes to the core are primarily driven by pull requests (patches in old sk00l) coming from these forks. That is _code_ is the engine of change. Person or people X are committed to responding quickly to bug reports helping to clarify and reduce those that are actionable, disposing those that are junk. They are also committed to announcing plans for the next release cycle, managing a beta release process, and doing regular releases (about every month or so depending on the bug bandwidth)."
I would also like to see this happen. Indeed it is one of the things I tried to get going (but based on developer branches in subversion rather than code forks (in, say, git)). When I started working on TiddlyWiki I made a lot of effort to try and get people to use subversion so that it would be easier for them to be involved in the development process. Unfortunately there was little take-up. I did have some minor success in that I managed to get all of Osmosoft using subversion (and this was no mean feat - software configuration management was not in the bones of any of the original Osmosoft team, apart from Paul and myself). One of my regrets is that despite my best efforts I never managed to persuade Eric to use subversion. "In my opinion, this "toss it over the wall" approach is at the heart of the real problem with the TW core development process, and the failure to reliably and consistently communicate a *detailed* upgrade 'story'... ... the core team should do everything possible to facilitate the efforts of plugin authors to keep their code viable and up-to-date with the latest core code rather than putting the onus onto the plugin developer to scramble and catch up." I think this is unfair. Any TiddlyWiki changes that break compatibility, or even might break compatibility are made into tickets and put on the release roadmap. Typically each point release has 15-20 tickets and there is plenty of time between a ticket being put on the roadmap and the release including that ticket - indeed the main complaint is that the release process is too slow. I don't understand the accusation that plugin developers need to "scramble and catch up". Eric said: "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." Although it may not have been visible, I was a considerable advocate for Eric in incorporating his changes into the core, often against the judgement of others at Osmosoft. Chris said the things he's trying to accomplish are: 1 "Core maintainers should be responsible for announcing changes in good time and providing suitable beta periods (in the order of weeks not months)." [1] * "[these changes] will not make enough of a difference if there is not a fundamental change in the attentiveness, accessibility and responsiveness of the people responsible for the core" [1] 2 "A driving force behind moving to github is to remove both the perception and reality of any Osmosoft priority over priorities." [2] 3 "There are 350 tickets in trac.tiddlywiki.org described by one of the reports as 'active'...What does that say about the development process and about the ticket handling process? Nothing good." [2] 4 "The point is that ticket handling and management, the social process surrounding tickets, is _broken_." [2] Some comments on these: 1) Changes are announced in good time - tickets are placed on the roadmap well in advance of their implementation. Having said that I agree that an improvement in "attentiveness, accessibility and responsiveness" is required. 2) I think the move to github will make development easier, but in itself won't change the perception of Osmosoft's priorities. The old adage: "Don't expect a technological change to solve a social problem" applies. I welcome the move to github (it will make core maintenance easier), but I don't expect it, in itself, to change perception. Having said that, introducing new working practices along with the change to github, can change perception. 3) "There are about 350 tickets described by one report as active." The trac ticketing system is used by things other than TiddlyWiki. The "really" active tickets for TiddlyWiki are those on the roadmap: 3 for milestone 2.7, 81 for milestone 2.7.1 and 11 for milestone 3.0. Now I agree that that is too many (and an effort to prune them is underway) - input on which tickets to prune has been solicited. 4) "The point is that ticket handling and management, the social process surrounding tickets, is _broken_." Agreed. Any suggestions on how to revive this process would be welcome. "The tyranny of the legacy" I think this is a difficult area. One of the reason I take a fairly conservative approach is that there is no plugin upgrade mechanism for TiddlyWiki. Which means if a user upgrades their tiddlywiki and it stops working it is actually quite difficult for them to get it working again. Even if the plugin developer has upgraded their plugin, the plugin is not upgraded automatically when the user upgrades their tiddlywiki. Take ticket #472 - invalid tiddler IDs (due to spaces). Although this meant that some users TiddlyWikis were technically incorrect - they still worked and were completely usable. However fixing this bug could render some TiddlyWikis unusable on upgrade, even if the plugins that relied on this erroneous behaviour had been fixed by their authors. Perhaps I erred too much on the side of caution here - on the other hand there certainly wasn't a strong call from users or plugin developers that this issue needed fixing. Some of my comments above may sound like they are defending the status quo - they are not meant to be. Rather they are explaining some of the reasons around why things are as they are. Chris pointed out: "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." He's right - there is little discussion about the state of the core and where people would like to see it moving. Even when there were major changes to the core (the addition of jQuery, for example) there was not much discussion. Chris also said: "The move to github, etc will will not make enough of a difference unless people other than Jeremy and Martin--who have been insufficiently attentive, accessible and responsive--are enabled to have some responsibility for the core. Does that make it clear enough? What I mean is that they haven't done a very good job for the two years I've been observing and we need to change things so that other people can have more direct impact: You. Me. FND. Person X." Agreed - other people need to get involved. There may be some inertia, but there is nothing actively stopping people from getting involved. And this involvement doesn't have to be directly contributing code. Opinions of which direction they'd like to see core development taking are also welcome. Martin On 10 February 2011 12:21, rakugo <jdlrob...@gmail.com> wrote: >> >> Extra thought: THANK YOU! This is the discussion we've been needing >> for YEARS! >> >> -e > > I couldn't agree more. > > -- > You received this message because you are subscribed to the Google Groups > "TiddlyWikiDev" group. > To post to this group, send email to tiddlywikidev@googlegroups.com. > To unsubscribe from this group, send email to > tiddlywikidev+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/tiddlywikidev?hl=en. > > -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to tiddlywikidev@googlegroups.com. To unsubscribe from this group, send email to tiddlywikidev+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
