On Mar 17, 9:22 pm, Måns <[email protected]> wrote: > @Chris, @Jon, @Paul, @Jeremy, @Colm or @Martin!!!
Since I'm called out by name here in this message I'll respond here, but I'm mostly responding to the thread as a whole. I think there are competing forces and concerns at work in this thread, so the picture is simultaneously quite simple and not that big of a deal while also an important part of the evolution and discovery of new processes. Some thoughts, including a bit of a review of some things that I think we already decided about process: * code should be the engine of change in an open source project This means that making commits is the most forthright and inclusive way of bringing about change and discussion in the "product". Rather than waiting until there is consensus before experimenting it is more productive to experiment to generate discussion and build consensus on the back of real code rather than speculation. This means that for alpha level changes (which this is) it is the responsibility of interested parties to stay abreast of changes via commit messages and tracking tickets. It is hoped that the migration to github (starting today of all goes well) will help make those changes more accessible. * this particular change is only in an alpha, thus far This means that it can still change. Note that a large reason people are even aware of it is because alpha capabilities have been exposed on TiddlySpace. Understand how powerful this is: You can try your existing Tiddly-content against an alpha core at no cost just by changing the URI. This means we can theoretically get up to 1000 people testing an alpha before it even becomes a beta. That means the number of eyes on the functionality is high and we have greater change of getting it right before it becomes released. * there was consensus that development was stalled/moribund and insufficiently reactive to modern times To combat that one of the things to do is to react to contemporary requirements. To complain that one change is happening before another, or one change is cascading other changes in the system seems a bit specious. We should be celebrating that there is change at all. An alive open source project is about change and about reacting to needs across the full diversity of the community. * commits and tools matter This particular change made it in quickly because somebody made a commit. There are quite a few tickets out there that have suggested changes on them, but it is the nature of the beast that committed code is far more likely to be released than code that somebody needs to integrate. Eric has many worthwhile changes that are pending, but if my information is correct (and I confess it may not be, as there's lots of hearsay, so please correct me if I'm wrong), Eric has not been willing to use subversion, despite being invited to do so. When we move to github the primary way to drive the code will be via forks and pull requests. That is: If you want something in the core, and you know how to do it, then write it up in a fork and submit a pull request. If you don't know how to do these things then learn, the web is full of instruction. Related to this, I suspect, are some of the concerns about NIH. It probably does seem like some of the work done to improve the core or to create plugins duplicate effort already done somewhere in TiddlyTools. This is unfortunate and we should work to remedy it. However, while tiddlytools is an incredible resource for gaining useful plugins to do cool stuff, as a developer's resource it is not great: As far as I know, the plugins are not in version control not accessible individually over http from svn or git and don't use cook recipe files to build standalones. For developers who do use those (fairly standard on the web) tools, that's a hinderance. (It should be noted somewhere in this that I do not develop TiddlyWiki plugins myself and only very recently got involved in helping to coordinate TiddlyWiki core development. My interest is on the serverside. This means that much of my information is biased by hearsay and superficial observations. My apologies for errors, please correct me.) * going where the action is It is true that TiddlySpace is going to drive a lot of the changes that happen in TiddlyWiki over the next few months. This is simply a matter of numbers. There are lots of people using TiddlySpace and they are stretching TiddlyWiki in weird and wonderful ways. This will make TiddlyWiki better for all users, not just TiddlySpace users. * changing attitudes towards releases One of the goals with making alphas and betas more visible is to drastically accelerate the release cycle of TiddlyWiki, to get rid of the sense of morbidity and staleness. That this discussion has come up at all is a good sign. It means that a) people have noticed some changes, b) feel empowered to comment on them. Making alphas available more often will help this happen more often. [eric] > > From my point-of-view, there appears to be a double standard at work > > here. Proposed core changes developed *outside* Osmosoft get a lot of > > resistance, languish for months (or *years*), or are repeatedly re- > > scheduled for a later release, effectively forcing them to be > > implemented as plugins, even if the proposed core change is minimal, > > isolated, and well-tested. When we get on github, get an account, join the game. > > In contrast, it seems that changes developed *inside* Osmosoft often > > get "fast-tracked" straight into the next release of the core, > > resulting in follow-up tickets to fix problems (or add even more > > functionality) that could have been identified and addressed > > beforehand. There's nothing wrong with follow-up tickets. It's continuity. Add a feature, see that it is not quite right, tweak it, release again. Release early and often is the mantra of the open source world. It is a mantra that TiddlyWiki has forgotten and needs to get back. If we release alpha's early and often and make them visible, then people who need stability can avoid them, while people who are doing development, like being on the bleeding edge or need new features _now_ have an option. In the past they did not have that option. Elsewhere in the thread Jeremy says: "Eric is entirely correct that these new changes popping up in the alpha without discussion is not exactly best practice. It's a work in progress as we try to improve how we work together, devising better processes that are more transparent, and everyone's feedback is very valuable as we figure things out." I disagree. New changes popping up in alphas is a great way in which to bring about discussion. Ideally interested parties will read tickets and commit messages, but barring that available code is the best way for people to really evaluate a feature. When we get onto github people will be able to point the mailing list to their forks and says things like "try this empty.html I built with support for backbone.js", but right now one of the easiest ways to get feedback is to get the alpha out there. Feedback is what makes things happen, and feedback which is based on real code and real product rather than speculative discussion is far more useful. So to sum: * Nothing too bad going on here, it is the process working. Join in the conversation if you have concerns. * Participating in the generation of code means using and attending to the tools associated with the code. Starting very soon that will mean github, git, and the github issues system. -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" 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/tiddlywiki?hl=en.
