"I also get a sense that there is a desire by some people to simply ignore and *discard* old tickets and move on without actually resolving the issues addressed by those tickets, unless they are *personally* interesting. It's simply too easy for someone to leave out the references to old Trac tickets and pretend that those problems never existed."
As one of the primary users of the ticket system, I'll address this comment. There are certainly tickets that I am reluctant to address, but this reluctance has nothing to do with whether I find the tickets "interesting". My reluctance is normally caused by one of four factors: i) The view that fixing the problem may break backwards compatibility and stop existing plugins and macros from working. This is especially true if the problem is relatively minor and there are established work-arounds. A good example is Ticket #472, "Invalid tiddler IDs (due to spaces)" - I've avoided fixing this ticket because I know it will break quite a few of Eric's plugins. (In the case of this Ticket the issue is being forced by jQuery - TiddlyWiki will not work with the next version of jQuery unless this is fixed.) I take a fairly conservative view here, and I know that there are those who feel that we should be less concerned about backwards compatibility. ii) The view that the feature is does not really belong in the core. Part of this is influenced by my view that "users who don't use a feature, shouldn't pay for that feature". Every feature added to the core increases its size and so its load time. Although the effect for a single feature is small, unless a conservative approach is taken the core, over time, will become bloated. A good example of this is the famous Ticket 17, "Improve searching user interface". The current search is adequate for many users, and users who want better search can use one of the many plugins. iii) The view that the problem is a theoretical one, rather than a practical one. There are a class of bugs that are what might be called "theoretical" - that is in principle they might cause problems, but in practice they do not, because the circumstances in which the bugs manifest themselves are extremely rare or even non-existant. iv) The view that the problem is difficult to fix and that the benefits are small or even unnoticeable. A good example is Ticket 34, "TiddlyWiki should generate proper <P> paragraph tags". This is a difficult (and interesting) problem, but one I just don't feel is worth fixing. I imagine that the vast majority of TW users don't care about the underlying HTML format of their tiddlers, they just care if they look OK. Actually Ticket 34 falls into several categories ( i: fixing it may break backwards compatibility, in that people's TiddlyWikis may display differently, ii: it's mainly a theoretical problem (there is the occasional HTML-purist who complains, but the average user doesn't notice), and the problem is difficult to fix). (And for the record I am one of those HTML-purists: it pains me that TW does not do proper paragraph formatting). One of the problems is my own reluctance to close down tickets completely. The migration to a new ticketing system is perhaps an opportunity to do this - if people believe a closed down ticket is important, then they can re-open it. Martin On 1 February 2011 00:06, Eric Shulman <elsdes...@gmail.com> wrote: >> > "Tickets". I agree that this is a difficult issue, and I don't think >> > there is an entirely satisfactory solution. >> >> Personally again, I would prefer that any important issues are >> manually moved over... even if that is just referencing a ticket on >> trac. I think this would be valuable to the TiddlyWiki project as a >> way of determining which issues are really really important and >> actionable. > > There are tickets in the Trac system that have been repeatedly re- > scheduled to "sometime in a future release", usually as a result of > some short-term priorities at Osmosoft. This doesn't mean they aren't > important or 'actionable', just that there were other items that were > deemed, at the time, to be more immediately in need of attention. > > I *do* agree that new tickets should be created for all actionable > issues. However, I am greatly concerned that creating a new ticket > that merely *references* a ticket on Trac doesn't ensure that people > actually examine the information in the old ticket and it also assumes > that *only* the referenced tickets are relevant to the current issue. > > My concern is that, given how poorly people *currently* use the > information in Trac, I think they are unlikely to suddenly become more > rigorous in checking that information when it is not integrated into > the new ticket system. There is *always* an "out of sight, out of > mind" effect when information is split across systems, especially if > one of those systems is 'mothballed' for reference-use only and is not > integrated into a single search process that examines ALL ticket > information (both old and new) for related issues. > > I also get a sense that there is a desire by some people to simply > ignore and *discard* old tickets and move on without actually > resolving the issues addressed by those tickets, unless they are > *personally* interesting. It's simply too easy for someone to leave > out the references to old Trac tickets and pretend that those problems > never existed. > > As I previously posted, I feel *very* strongly that the existing > tickets should be migrated into the new system (as *read-only* > information) so that the old ticket information is easily searchable > without having to search on two separate systems. Please note, I am > *not* suggesting that these tickets be made *active* in the new > system. What I am advocating is that ALL ticket information be > retained and migrated, so that there is no chance that it is simply > "lost" or ignored as a result of the transition. > > -e > > -- > 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.
