Before I respond below, I'd just like to repeat that what I suggested
is a proposal for the sake of discussion. Some of the more "radical"
parts designed to draw out some of the real issues. My response below
should be taken as presenting my position and feelings on the issues
in the discussion.

On Thu, 20 Jan 2011, Eric Shulman wrote:

History for those components will not be migrated.

Is there some reason why you would discard this information?  Is it
not correct?  Even if it's very old, the modification history can be
*vital* to determining what changed and why.. and, VERY old versions
of TiddlyWiki are still relevant.  (I just responded to a question
about someone using TW1.2.12, from 2006).  Please don't throw away the
past in an attempt to move towards a better future.

I didn't say "discard". The svn repo would remain in place, with full
history. Reviewing that history would require an extra step, but still
be possible.

In my experience deep knowledge of why certain structures are in place
is a good way of making sure they stay in place. I think it can be
argued that such thinking hampers TiddlyWiki across the board.

I *strongly* object to this.  There are HUNDREDS of open tickets that
have simply been deferred over and over and over again, due to "short
term priorities" at Osmosoft.  These tickets may be old, but they are
NOT irrelevant.  In many cases, there are extensive discussions and
detailed information in these tickets, not only about the outstanding
problems, but also, in many cases, solutions that can be readily
implemented *if* there is the will to do so!

A driving force behind moving to github is to remove both the
perception and reality of any Osmosoft priority over priorities. If
you keep your own fork of TiddlyWiki on github, and manage it in a
shareable way, then it becomes easy for your changes and fixes to be
merged into an official core, or even for your version to be become
preferred.

In any case, again, the tickets would not be destroyed, just left in
their current state. That is to say: idle.

Forcing the re-entry of all of this information is NOT the way to
review the issues.  Certainly, some of these open tickets are not
important any more, but that cannot be said for MOST of them.  Perhaps
there is a way to migrate the tickets but declare them as 'migrated'
and subject to review before being marked as 'active'.

Or they can just be left there and people who have the will to do them
will migrate _only_ the ones that are actually important.

I'm not saying this to be cantankerous nor contrary. I'm just as
annoyed as anyone else by the seeming policy of deferment in TiddlyWiki
development. I've agitated for this github stuff exactly to shake things
up enough so that the morbidity in the development of the TiddlyWiki
core can be blown out the doors, washed down the streets and become an
interesting memory.

If we get stuck deep in process discussion about how to save tickets,
how to migrate tickets, or how to pick and choose then things will
stay stuck. Stuff that matters will move to a new system because it
matters. Stuff that doesn't move either doesn't matter, or the
problems (and solutions) will rise up again because they do.

There are 350 tickets in trac.tiddlywiki.org described by one of the
reports as "active". The oldest is dated May of 2006. It can't be that
active if it is 5 years old and still exists. Amusingly this
particular bug (http://trac.tiddlywiki.org/ticket/17) is one that
keeps coming back up but somehow just keeps getting its milestone
changed, and that's it. What does that say about the development
process and about the ticket handling process? Nothing good. Further,
the bug in question is one of those bugs that's pretty obvious and
we'll get it again if for some reason all TiddlyWiki tickets are
destroyed. The gist is: Search in TiddlyWikis sucks, especially when
there are lots of results.

We'll continue to know that if ticket 17 dropped off the face of the
earth.

I'm sure there are plenty of counter examples of tickets with full and
luscious histories that include multiple proposed solutions so this
doesn't need to be an invitation to show that #17 is anomalous. That's
not the point. The point is that ticket handling and management, the
social process surrounding tickets, is _broken_.

I think it will be easier to fix that social process from something
closer to scratch.

Thanks for providing me the opportunity to rant. Sorry for being
strident.

--
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 [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.

Reply via email to