[My response below is quite long. I hope you will read it, but if you
want the tldr version it is this: I mostly agree with Eric, I think
the core maintainers need to communicate more, that's what I've been
saying all along.]
On Tue, 8 Feb 2011, Eric Shulman wrote:
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.
It's interesting: I think we mostly agree but because of some of my
pointed language I may be triggering a reaction in you that is
obscuring some of that agreement.
Let me review what I'm trying to accomplish through this conversation
and the other ones related to the wiki, ticket and code migration:
* "Core maintainers should be responsible for announcing
changes in good time and providing suitable beta periods (in the order
of weeks not months)." [1]
* "[these changes] 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" [1]
* "A driving force behind moving to github is to remove both the
perception and reality of any Osmosoft priority over priorities." [2]
* "There are 350 tickets in trac.tiddlywiki.org described by one of the
reports as 'active'...What does that say about the development
process and about the ticket handling process? Nothing good." [2]
* "The point is that ticket handling and management, the
social process surrounding tickets, is _broken_." [2]
[1] http://groups.google.com/group/tiddlywikidev/msg/7a4831c2c4f8eef6
[2] http://groups.google.com/group/tiddlywikidev/msg/178d3a3873135fa7
That last could s/tickets/development/ and still be a quote of me as
I've said that before.
The most important of the above list is the first. Your response reads
as if I either didn't say that or you didn't acknowledge it. This
current thread started because FND said, to paraphrase, the current
core maintainers (meaning Martin, as he is the only active core
committer) are not doing a good enough job, we need to fix it,
what shall we do?
I followed up by saying, to paraphrase, "yes, the current core committers
are not doing a good enough job, let's make things better". I then
went on to provide an opinion that one of the problems is that the cod
ebase does not change quickly enough (repeating Fred's assertion in
another way) and suggesting that we can make it more more quickly by
ensuring that core maintainers be attentive, accessible and responsive
AND announce their intentions and changes before making new releases.
This seems to be strongly in agreement with you. You want the core
maintainers to be far more verbose about both plans and accomplished
changes. I'm glad we agree about that.
I suspect some of the confusion here is that you are lumping the
various people who have some association with Osmosoft with the core
maintainers of TiddlyWiki. FND is "no longer with the company". I'm a
contractor. FND has been an adjunct core guy, trying hard to help
insure the quality of the release process for a few years now and
struggling mightily against the status quo. I'm a contractor with
Osmosoft and my involvement with Tiddly* has been entirely with
TiddlyWeb and TiddlySpace, until recently. TiddlySpace has helped
to reveal weaknesses in TiddlyWiki that I would like to help resolve,
but the existing development process is not working to get that
resolution happening in good time.
So, effectively, if I may interpret FND, we're railing against the
status quo as you, and attempting to stimulate ideas to change it.
We've both been arguing with Jeremy and Martin about how the TiddlyWiki
project is not operating on sound open source principles nor treating
its community well for more than two years. I can tell you, frankly,
that it has been incredibly frustrating and to find myself now lumped
in with the problem rather than solution, doubly so.
My feeling is that we are mostly likely to come to a robust solution if
we are forthright about the issues we have encountered.
For me, personally, one of the issues is this thing I'm calling the
tryanny of the legacy. As Tobias puts it:
"There should not be prolonged inaction for fear of breaking
existing (legacy) implementations ...blocking TW core progress."[3]
[3] http://groups.google.com/group/tiddlywikidev/msg/c0b60b4029b42a72
True, there should not be inaction, but there has been, so we need to
fix it.
One way to fix is to sit "in an ivory tower" and "toss [code] over the
wall", willy nilly.
But no one is suggesting that. Because that won't work.
There seem to be several different strategies floating around and
presumably we can cherrypick the best parts.
To be more explicit about the strategy I'm espousing, it is not at all
about making the community "cope with whatever we decide to do". It is
instead about as much as possible destroying any semblance of a tower,
making core development completely transparent and completely
accessible to any participants by using tools that a) have no
organizational barriers b) use easily shareable artifacts (code,
tickets, plans) and c) encourage and allow anyone to make contributions.
Critical to this is communication; dynamic and full-throated dialog
that does not languish. Tickets are a good example where this falls
down for TiddlyWiki, but so is this group: There's _very_ little talk
about the state of the core on this group. It's generally about
plugins.
I think we can agree that increased communication is a good thing. It
is a main portion of your message, Eric: Activity needs to be
telegraphed more effectively. Couldn't agree more. You are 100%
correct.
It is in the details of how an open source project is to be managed
where there is likey to be disagreement and those are areas in which I
think _all_ the people on this group can provide excellent input.
Tobias (in [3]) provided some very good input from an existing plugin
developer.
I hope this thread will continue to provide such insights as it
carries on.
I'll provide a brief picture of what I think an ideal is, and then
respond to some of the details of Eric's original message below.
In a modern healthy open source project, activity is focused around
source code. It's right there in the name. I want to see a future
where there is some person or persons "X" who maintain a git repo from
which the official TiddlyWiki core is built. Surrounding this are a
community of people who use it with some segment also providing help
with documentation and bug reports. Meanwhile there are several active
forks of the core. One belonging to me, one to FND, one to Jeremy, one
to Martin, one to Eric, some belonging to people I've never heard of.
Changes to the core are primarily driven by pull requests (patches in
old sk00l) coming from these forks. That is _code_ is the engine of
change. Person or people X are committed to responding quickly to bug
reports helping to clarify and reduce those that are actionable,
disposing those that are junk. They are also committed to announcing
plans for the next release cycle, managing a beta release process, and
doing regular releases (about every month or so depending on the bug
bandwidth).
There are a few problems with this plan, the biggest is who is going to
do it. While it may appear like Osmosoft is in the business of
"maintaining TiddlyWiki" this is not true. Osmosoft, at the moment, does
web development for BT, with TiddlyWiki as one of the primary tools.
I personally would like to see more core commits/patches from Eric.
I think this would a) help move things along, b) increase the
diversity in the code base, and c) be a good example for other people
who want to get their changes in the core.
Now into the depths of the message:
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.
We've both had a lot of experience in the software world, Eric, and
I'll simply respectfully disagree with you on this one and leave it
for another thread if we want to give the wide-adoption topic the
attention it may deserve.
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.
Yes.
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.
Yes. This would be especially true if there were a "core team" instead
of "just Martin".
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.
This distills to communication. As state above, there needs to be more
of it.
[snip] 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.
Agreed, and when I said this:
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.
it assumed the statement made elsewhere in the message: "Core maintainers
should be responsible for announcing changes in good time and providing
suitable beta periods (in the order of weeks not months)." [1]
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.
We agree on this up to the point of "provide *whatever assistance is
needed*". It's a bit much to expect more than effective communication
of changes and strategies for coping with them. The core developers
are not a support team. The communit at large is a support team:
that's part of the open source promise. It's unfortunate that the
existence of Osmosoft has sometimes made it seem (to some people, some
times) like that organization ought to take care of everything.
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,
My point was that itunes will upgrade itself (with a confirmation
dialog). A TiddlyWiki user has to choose to upgrade.
... 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?!?)
This is where I think you are starting to willfully misinterpret my
goals. If there exists an effective range of communication by those
people maintaining the core, then they will do what you suggest:
Provide enough information so people can make informed choices about
upgrading.
What I _did_ suggest was that we can't let backwards compatibility
prevent us from making changes that are important. Yes, when that
happens, we must make sure to communicate how it will impact existing
situations.
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"...
Let me unpack this in as explicit way as possible, at the risk of
being risky:
The move to github, etc will will not make enough of a difference
unless people other than Jeremy and Martin--who have been
insufficiently attentive, accessible and responsive--are enabled to
have some responsibility for the core.
Does that make it clear enough? What I mean is that they haven't done
a very good job for the two years I've been observing and we need to
change things so that other people can have more direct impact: You.
Me. FND. Person X.
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'.
Yes, my statement does reflect that, and my statement also reflects
that I think that situation is _completely_ broken and constitutionally
_wrong_. If I felt like you knew me better, I'd even go so far as to
describe it as sinful, but the nuances of that statement are probably
lost in translation.
Too many people, inside and out of Osmosoft, think that Osmosoft is
or should be controlling the code.
That's not open source.
And I only work on open source, so another way to interpret my part in
this whole conversation is: I'd like to work on TidldyWiki, but until some
things change, it doesn't meet with my standards.
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.
Yes, very good information. I too hope that it will show up in a tech
note associated with any release.
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.
Yes, on this we are 100% in agreement.
--
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.
