> TiddlyWiki suffers from something that might be called the tyranny of
> the legacy[1]. It's captured in the idea that it is up to the maintainers
> of the core to go out and search for plugins that might be harmed by
> changes to the core.
There is no "tyranny" of the legacy. But there *is* a world-wide
community of TiddlyWiki users that expects and depends upon a
*reliable* upgrade process... and disregarding the impact of core
changes on the community is extremely short-sighted. It is highly
irresponsible to make changes to *any* codebase and not consider the
potential harm those changes might cause to current users.
If you want to develop a piece of code in an ivory tower... then go
ahead. But I deal every day with the *practical* issues of keeping
the TiddlyWiki community healthy, growing and thriving. The attitude
you espouse, quite frankly, seems to be one of "the community will
just have to cope with whatever we decide to do, even if it means a
lot more work for them".
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' has been the single most influential reason that TiddlyWiki
hasn't been as widely adopted as it could have been by now, especially
for commercial, mission-critical business uses.
My previously posted suggestion, that the core team try to check 3rd-
party plugins for their potential failure during core upgrades, was
absolutely *not* advocating that the core team does the work of
*maintaining* those 3rd-party plugins. Clearly, that responsibility
falls squarely on the shoulders of the plugin authors.
Nonetheless, 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. It seems to me that the core team
is in an ideal position to perform at least a cursory *investigation*
of the potential impact of core changes on existing plugin code, and
then report their findings publicly, so that plugin developers can
more quickly and reliably revise their code.
Of course, this assumes that the plugin hasn't been orphaned and that
the developer is actually paying attention to core changes.
Unfortunately, even if the developer *is* actively involved in plugin
maintainence, it is still extremely easy for core changes to 'sneak
up' on him. The problem is that, without better communication from
the core team, the impact of impending core changes on existing
plugins is rarely apparent to the plugin developers unless they are
extremely diligent in tracking those changes *and* they have
sufficient understanding of the TW core architecture to recognize the
potentially very subtle effects those changes can produce.
> Plugin maintainers should be responsible for tracking the core and
> keeping up to date as needed, or stating that their plugins require an
> older version.
Yes. They *should*. But, failing to do that, it still falls on the
TW core developers to properly *communicate* the expected impact of TW
core changes, and provide *whatever assistance is needed* to ensure a
successful upgrade path for all TiddlyWiki users who want/need to
upgrade.
> The nature of TiddlyWiki makes it so that people who don't want to
> upgrade don't have to: Their stuff is all there and already working.
> If they want new stuff, it is _new_ stuff, which they have gotten for
> themselves. This isn't like upgrading iTunes and suddenly you can't
> play your oog files.
Oh.. but it is! Many people *attempt* to upgrade their documents,
only to find that the core changes break their existing installed
plugins... and, because they have no idea what has changed in the core
(and most users wouldn't understand the code anyway), they *cannot*
resolve the problems themselves.
As a result, they either:
A) abandon the attempt to upgrade their documents (which further
isolates them in a *legacy* document environment),
B) post a desperate message on the GoogleGroups (e.g. "Help...
everything broke!")
C) try to investigate the cause and find a work-around (assuming
they have both the time and the skills to do so).
D) and finally, if they do manage to isolate and identify which
plugin(s) are failing, they *might* actually try to contact the plugin
author to report the problem.
If they are *lucky*, the plugin developer is already aware of the core
changes, and has had the time to revise their code accordingly, so
that the end-user solution is simply to upgrade the affected plugins
and get back to work. This assumes, of course, that the plugin author
is able to determine why and how the core changes break their plugin
code, and that a fix or work-around can be readily implemented.
> A healthy open source
> project "should move more rapidly and be more responsive". The fact
> that this bug, and many other bugs, languish gives the impression
> that the project is neither healthy nor maintained, which we _know_ is
> not true, so how do we change things so that that impression is not
> given?
... and, failing to ensure that the upgrade process is smooth and
uneventful for the end-user gives the impression that TiddlyWiki is an
unstable "hobby" project that *cannot be relied upon* as a safe place
to keep your important information (which we *know* is not true?!?)
> The move to github is an effort to shake things up, blow out the dust
> a bit, but it 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.
"the people responsible for the core"...
Do you mean the *entire TiddlyWiki community* or just the folks at
Osmosoft that are actually permitted to submit changes to core
code??? Your statement seems to reflect the current view that
Osmosoft "owns" the core code and that other potential core
contributors are 'on the outside, looking in'. Regardless, my
suggestion that the core team try to identify and report on
potentially affected 3rd-party plugins goes directly to the issues of
'accessibility' and 'responsiveness' that you mention.
For example, in the recent discussion of ticket #472 ("tiddler ID's
with spaces"), I described some of the coding issues, and suggested
some specific search text that should locate *most* (if not all)
instances of plugin code affected by the proposed core change. I also
included a small example of the change in coding usage that the core
change would require.
It seems to me that providing this kind of detailed "tech note"
information to plugin developers should be an integral part of *every*
core upgrade notice (especially alpha/beta announcements), and would
go a long way towards improving the current negative feeling in the
community that there is a *lack* of accessibility and responsiveness
on the part of the core team.
-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.
