On Fri, 11 Feb 2011, Martin Budden wrote: [code as the engine of change]
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.
One option we might consider is that once the github move has happened gatekeeping a bit more strongly around pull requests _the_ way to submit a patch. In these modern times I don't think that's too much of a burden, especially given how much handholding github will do if you let it. Participating in version control is a broadly accepted best practice. It has worked _very_ well with TiddlySpace and TiddlyWeb.
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.
I see the move to github as a lubricant that will allow (has already allowed) an increase in dialog and it is that dialog that will both change perceptions and introduce improved practices. If we're lucky.
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.
I think this points out one of the problem with the trac and svn setup. The roadmap isn't really relevant or visible unless you are already in the game. When you look at it, a lot of milestones show up and their relative importance is not clear. It isn't obvious where effort is being applied or how best to apply effort if you want to join in. Instead, what is obvious is that there are a very large number of tickets, some of them very old, suggesting a lack of health.
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.
From the people I've spoken with, both in private and public, the main
theme I've heard is that the turnaround time from contributing a ticket to seeing results is far too long, and over repeated instances drives the person to lose any urge to ticket again. -- Chris Dent http://burningchrome.com/ [...] -- 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.
