keeping up with jQuery
FND
jQuery (v1.4.3 vs. v1.5.0), with jQuery 1.5 being a major release.
Late last year, there seemed to be universal agreement that core
development should move more rapidly and be more responsive.
Unfortunately, I don't see any evidence of that taking shape.
How can we, as a community, fix this situation? While I'm happy to
contribute, Martin's leadership and his role as gatekeeper seem
particularly crucial here.
-- F.
Martin Budden
jQuery version later than 1.4.3 requires fixing ticket 472 - spaces in
tiddler ids (http://trac.tiddlywiki.org/ticket/472 ). Although the fix
is simple to implement, it breaks a number of Eric's plugins so we
didn't put the fix in release 2.6.2 so that he would have time to fix
those plugins.
The intent is to fix ticket 472 and upgrade to the latest version of
jQuery in the next TiddlyWiki release.
Martin
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
> To post to this group, send email to tiddly...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
>
>
Paul Downey
> jQuery version later than 1.4.3 requires fixing ticket 472 - spaces in
> tiddler ids (http://trac.tiddlywiki.org/ticket/472 ).
Oh, 472 has been one of my big bones of contention, and not just for
jQuery, but for CSS and XSLT -- spaces in ids are invalid XHTML and
even invalid loosey-goosey HTML.
Seems we might have to break somethings to fix 472, but without fixing
472 something larger is still broken.
--
Paul (psd)
http://blog.whatfettle.com
PMario
3 years ago I even didn't know that TW exist. IMO this issue should
have been fixed 3 years ago. Or may be 2 years ago, after a one year
beta. I started programming TW about one year ago. Not fixing this
issue, now causes trouble, for everyone, that have made the mistake to
use a function, that is known to be broken.
my 2€ents
On Feb 8, 10:30 am, Martin Budden <mjbud...@gmail.com> wrote:
> There is a specific reason we are lagging jQuery: upgrading to a
> jQuery version later than 1.4.3 requires fixing ticket 472 - spaces in
> didn't put the fix in release 2.6.2 so that he would have time to fix
> those plugins.
>
> The intent is to fix ticket 472 and upgrade to the latest version of
> jQuery in the next TiddlyWiki release.
>
> Martin
>
tiddlygrp
if spaces are a problem, what about escaping them? Something like url-
escape possible or a html code.
url escaping would be: space %20
and for html something like:
  en space
  em space
  thin space
If spaces in titles could be html escaped, I think not too much would
happen.
yours,
vlak
Eric Shulman
> didn't put the fix in release 2.6.2 so that he would have time to fix
> those plugins.
using:
story.idPrefix+tiddler.title
to construct a tiddler element ID, which was then being passed to
document.getElementById(...)
to retrieve the rendered tiddler element from the story.
Fortunately, as of 11/30/2010, *all* of these occurences were replaced
with
story.getTiddler(tiddler.title);
As a result, all TiddlyTools plugins now rely upon the core's
implementation of
story.getTiddlerID(tiddler.title);
and will automatically handle any changes in the generation of tiddler
element IDs (i.e., mapping spaces to "_" to ensure valid IDs). Thus,
as far as TiddlyTools plugins are concerned, there are no *known*
barriers to fixing ticket 472.
However, the same may not be true for other, non-TiddlyTools plugins
that are still constructing their own tiddler element IDs. I suggest
that, before releasing any fix for #472, we should perform a simple
text search through as many known, published plugins as possible, to
attempt to identify code that needs to be changed. For example,
searching for any of these literal strings:
idPrefix
"tiddler"+
"tiddler" +
'tiddler'+
'tiddler' +
should locate nearly all instances of code that manually constructs
tiddler element IDs.
Of course, once identified, the work of actually altering that code
would fall to the individual plugin authors... but at least we can
attempt to notify them in advance and provide them with some guidance,
so that they are aware of the impending change and will have time to
prepare and publish their own plugin updates.
enjoy,
-e
Martin Budden
escaping spaces with underscores (and underscores with double
underscores). The problem is that this or any fix will break plugins,
so time was allowed for the plugins to be fixed.
I've just heard from Eric to say that he has fixed his plugins, so the
fix can go ahead in the next release.
And of course people who use any of the now fixed plugins will have to
upgrade the plugins when they upgrade tiddlywiki.
Martin
Paul Downey
> escaping spaces with underscores (and underscores with double
> underscores).
I'm not mad about legitimate underscores becoming doubled, and it
seems a reasonable work-round for a HTML document:
http://www.w3.org/TR/html5/elements.html#the-id-attribute
however claiming to be XHTML does imply other characters are invalid:
http://www.w3.org/TR/REC-xml/#id
http://www.w3.org/TR/REC-xml/#AVNormalize
Jeremy Ruston
to pursue XHTML compatibility.
Cheers
Jeremy
> --
> You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
> To post to this group, send email to tiddly...@googlegroups.com.
> To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
>
>
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
chris...@gmail.com
> However, the same may not be true for other, non-TiddlyTools plugins
> that are still constructing their own tiddler element IDs. I suggest
> that, before releasing any fix for #472, we should perform a simple
> text search through as many known, published plugins as possible, to
I think this is a) unreasonable, b) maintains a damaging precedent
that has limited TiddlyWiki's growth and maturation.
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.
NO!
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. Core maintainers should be responsible for announcing
changes in good time and providing suitable beta periods (in the order
of weeks not months). Plugin maintainers who don't track those changes
aren't _maintainers_ they are absent[2].
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.
[1] This tyranny is made extra strong by many of the techniques used in
some plugins.
[2] To get back to what I took as FND's original point, the issue here
is not this one bug about jQuery, but rather how long it is taking it,
as an example of many bugs, to get resolved. 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?
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.
--
Chris Dent http://burningchrome.com/
[...]
FND
> not this one bug about jQuery, but rather how long it is taking it,
> as an example of many bugs, to get resolved. A healthy open source
> project "should move more rapidly and be more responsive".
That was indeed my main point - the jQuery lag is just a symptom.
> The intent is to fix ticket 472 and upgrade to the latest version of
> jQuery in the next TiddlyWiki release.
Further to the above, I currently have no idea when that release is
gonna be - I don't think anybody (including the core maintainer) does.
Extrapolating from past and current trends, I'm concerned that's gonna
be months rather than weeks.
> 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.
+1
(Note that my intention here is not to spread pessimism, but rather to
constructively highlight significant issues.)
-- F.
Eric Shulman
> 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.
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.
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.
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?
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.
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
RobertC
been developing software for over 25 years. I'm also a bit out-of-the-
loop on TW plugins released in the last year due being on some other
projects. However, this discussion raises the (perhaps naive)
question...
Since each TW file could be thought of as analogous to a book (perhaps
a very dynamic reference book?), why do we need to "upgrade" our old
TW files? With the addition of some cross-file search capabilities
(and maybe this already exists), couldn't we avoid much of the
backward capatibility problem by just starting a new file when a new
version comes out?
My hat's off to you all for creating such an innovative and useful
product!
-R
Tobias Beer
agile enough to move on, especially with fundamental, high priority
issues like that of tiddler IDs.
If there are plugins that were published for TW 2.1.x and are expected
to flawlessly cooperate with 2.6+, I think one should either expect
there to be a maintainer or wait for someone to walk in his or her
footsteps. There should not be prolonged inaction for fear of breaking
existing (legacy) implementations ...blocking TW core progress.
There are still two problems with my last version of tbGTD and the
current version of the TW core, but it's up to me to take the time
required to fix those. I simply can't and wont upgrade or blame the
core for breaking my implementation.
If there are barriers for an upgrade, then it is the responsibility of
the one upgrading an implementation to thoroughly check for any
problems. Backwards compatibility should in my opinion not be a given
or even have topmost priority. I don't think it's a healthy approach
to generally suggest to users that upgrading the core of any wiki is a
minor issue et voila, no matter how complex your implementation and
depending on (community) plugins, things should work. They just might
not and one should not expect that.
As Chris pointed out, it's more a matter of giving appropriate notice
and expecting maintainers to consider any changes to the core with
respect to their plugins ...well, before publishing updates.
I do agree with Eric to advocate investigation as to implications of
core changes, providing said "tech notes" or migration paths, etc.
However, in my opinion, it is not and should not be a given that a
plugin designed for core 2.5.x is working with a 2.6.x core or that a
plugin that does work with 2.6.x works also does so for a 2.5.x
versions of the core. Consider the Mozilla development process... with
a new Firefox release all Addons are marked as not working for that
release unless tested and confirmed by the addons maintainer, at least
so it seems.
As I have pointed out in another post [1], I really hope that one day
a MUCH more powerful plugin mgt. system will be available to the TW
community... one which, for example, allowed to filter (plugin)
versions with respect to a given version of TW, a status which must be
rechecked for every (major) plugin and core release.
At least I do find the TiddlyWiki landscape to be way too complex to
do without the support of at least one integrated repository for all
kinds of related material. And no, I don't just mean some place onto
which to dump some code or documents in an unstructured, all organic
fashion. Accessiblity and the ability to evaluate suitability,
efficiency and potential risks for adapting a solution (e.g. a plugin)
to a given implementation should be top priority.
Cheers, Tobias.
[1] http://groups.google.com/group/tiddlywikidev/browse_frm/thread/1ba8b3361612b527
chris...@gmail.com
[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.
Eric Shulman
> pointed language I may be triggering a reaction in you that is
> obscuring some of that agreement.
the long-term frustrations with the process. Regrettably, those
frustrations sometimes lead to a bit more 'heat' and less bit less
'light'. Thanks for looking past the words to get to the meaning.
> * "Core maintainers should be responsible for announcing
> changes in good time and providing suitable beta periods (in the order
> of weeks not months)." [1]
> as if I either didn't say that or you didn't acknowledge it.
point. Mea Culpa.
> 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.
about the general 'core team' role, whether within Osmosoft or
otherwise.
> So, effectively, if I may interpret FND, we're railing against the
> status quo as you, and attempting to stimulate ideas to change it.
it... I'm just adding my thoughts to the pile in hopes that some
pretty flowers will grow.
> incredibly frustrating ... to find myself now lumped
> in with the problem rather than solution...
Profuse apologies! Despite the somewhat accusatory tone of my
posting, I wasn't trying to 'point fingers' at *people*. I think it's
just a result of accumulated frustrations with the *process*.
> My feeling is that we are mostly likely to come to a robust solution if
> we are forthright about the issues we have encountered.
> presumably we can cherrypick the best parts.
possible about the issues, so that a variety of views can be
considered and the best combined solution arrived at.
> 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.
patches (which I couldn't actually submit), publish CoreTweaks (to get
a viable solution into the field quickly), and spend a lot of effort
advocating for putting fixes (*small ones*) into the core. At my
request, we periodically had lengthy (and somewhat contentious)
conference calls to discuss open tickets, and I'd regularly (daily)
review all code submissions to look for possible red-flags (in terms
of impact on the installed base).
Unfortunately, *most* of the time, it seemed there was a significant
amount of resistance to making core changes (except for changes
originating within Osmosoft), and the response was typically along the
lines of "well, if Eric has a plugin/CoreTweak for it, then it doesn't
belong in the core." Except... for many cases, the plugin/tweak that
I created was just a 'monkey patch' of the core code, and really was
intended to provide a more immediate solution (and some real-world
field testing) so that TiddlyWiki users can achieve their goals
without waiting for "the next release" to fix their problems.
The conference calls were the most frustrating experiences! I'd start
with a pre-selected list of "important" tickets that I'd culled from
the larger list of open tickets, and *hope* that I might get just a
tiny few of them accepted and fixed. Typically, out of 20-25 tickets
discussed, perhaps 3-5 would be accepted (i.e., planned to fix in the
next release). Sometimes, even *after* extensive discussion and
apparent agreement, some of the changes in the accepted tickets would
still not make it into the core code, or would be implemented
differently (resulting in subtle differences in usage or effect).
Basically, after a long time of feeling like I'm on the outside, cut
out of "the loop" and banging my head against a brick wall, I gave up
trying.
> 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.
to fight the uphill battle to get them into the TW core. Initially,
CoreTweaks' purpose was to get solutions into the field quickly and
field-test the results to demonstrate the value and viability of the
changed code.
The intent was that CoreTweaks would be *temporary* fixes, not
permanent core overlays, and that when a CoreTweak is added to the
core, it is retired from the plugin. Intially, this worked reasonably
well. Unfortunately, due to the resistance to change I described
above, most CoreTweaks for the past few *years* have remained as
tweaks and have not been added to the core.
> 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.
Business users require a stable, reliable platform for conducting
mission-critical activities. Software upgrades are generally highly-
planned, phased roll-outs. Most IT departments reject (or at least
resist) any upgrade process that has too many issues or requires
extensive hand-modification of individual installations... and, if
there are *any* failure points in the upgrade process, including (and
especially) lost/damaged data or broken functionality, most IT people
start looking for other software to use, rather than take the risk
with their business.
> 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.
in the best interests of core developers to actively support changes
in their code by assisting other developers (i.e., plugin authors) in
responding to those changes, even to the extent of taking a bit of
time to help investigate/debug 3rd-party plugin code.
Writing and releasing updates to core code is not the *end* of the
process. The goal here is to make *everyone* successful and, in
practical terms, the core developers are in a position to do that,
since knowledge of the core changes starts with the core developers
themselves.
> > ... 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.
process (or lack thereof) "gives the impression that the project is
neither healthy nor maintained, which we _know_ is not true". My
point was that, similarly, when existing content fails as a result of
a core upgrade, the *impression* is that TiddlyWiki is an "unstable
hobby project that cannot be relied upon... which we _know_ is not
true"... leading to the same question you asked:
we are on the same page. I have confidence that, after sufficient
discussion, the technical aspects of the new development process will
be robust and more effective than the current process.
Where we perhaps differ somewhat is in the manner and extent to which
'community-based' support issues should be incorporated into that
process. My focus is, and has always been, on the community.
In addition to my role as plugin developer/wizard, many people
regard me as an advocate/evangelist, operating as a liason between the
'outside' (users and document authors) and the 'inside' (plugin and
core code developers). It is mostly in this capacity that I am
contributing to the current discussion.
Summary: we agree, with some minor differences.
Extra thought: THANK YOU! This is the discussion we've been needing
for YEARS!
-e
rakugo
> Extra thought: THANK YOU! This is the discussion we've been needing
> for YEARS!
>
> -e
Martin Budden
"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)."
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.
"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'...
... 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."
I think this is unfair. Any TiddlyWiki changes that break
compatibility, or even might break compatibility are made into tickets
and put on the release roadmap. Typically each point release has 15-20
tickets and there is plenty of time between a ticket being put on the
roadmap and the release including that ticket - indeed the main
complaint is that the release process is too slow. I don't understand
the accusation that plugin developers need to "scramble and catch up".
Eric said:
"I used to push hard for core changes. I'd write tickets, create
patches (which I couldn't actually submit), publish CoreTweaks (to get
a viable solution into the field quickly), and spend a lot of effort
advocating for putting fixes (*small ones*) into the core. At my
request, we periodically had lengthy (and somewhat contentious)
conference calls to discuss open tickets, and I'd regularly (daily)
review all code submissions to look for possible red-flags (in terms
of impact on the installed base).
Unfortunately, *most* of the time, it seemed there was a significant
amount of resistance to making core changes (except for changes
originating within Osmosoft), and the response was typically along the
lines of "well, if Eric has a plugin/CoreTweak for it, then it doesn't
belong in the core." Except... for many cases, the plugin/tweak that
I created was just a 'monkey patch' of the core code, and really was
intended to provide a more immediate solution (and some real-world
field testing) so that TiddlyWiki users can achieve their goals
without waiting for "the next release" to fix their problems."
Although it may not have been visible, I was a considerable advocate
for Eric in incorporating his changes into the core, often against the
judgement of others at Osmosoft.
Chris said the things he's trying to accomplish are:
1 "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]
2 "A driving force behind moving to github is to remove both the
perception and reality of any Osmosoft priority over priorities." [2]
3 "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]
4 "The point is that ticket handling and management, the social
process surrounding tickets, is _broken_." [2]
Some comments on these:
1) Changes are announced in good time - tickets are placed on the
roadmap well in advance of their implementation. Having said that I
agree that an improvement in "attentiveness, accessibility and
responsiveness" is required.
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.
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.
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.
"The tyranny of the legacy"
I think this is a difficult area. One of the reason I take a fairly
conservative approach is that there is no plugin upgrade mechanism for
TiddlyWiki. Which means if a user upgrades their tiddlywiki and it
stops working it is actually quite difficult for them to get it
working again. Even if the plugin developer has upgraded their plugin,
the plugin is not upgraded automatically when the user upgrades their
tiddlywiki.
Take ticket #472 - invalid tiddler IDs (due to spaces). Although this
meant that some users TiddlyWikis were technically incorrect - they
still worked and were completely usable. However fixing this bug could
render some TiddlyWikis unusable on upgrade, even if the plugins that
relied on this erroneous behaviour had been fixed by their authors.
Perhaps I erred too much on the side of caution here - on the other
hand there certainly wasn't a strong call from users or plugin
developers that this issue needed fixing.
Some of my comments above may sound like they are defending the status
quo - they are not meant to be. Rather they are explaining some of the
reasons around why things are as they are. Chris pointed out:
"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."
He's right - there is little discussion about the state of the core
and where people would like to see it moving. Even when there were
major changes to the core (the addition of jQuery, for example) there
was not much discussion.
Chris also said:
"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."
Agreed - other people need to get involved. There may be some inertia,
but there is nothing actively stopping people from getting involved.
And this involvement doesn't have to be directly contributing code.
Opinions of which direction they'd like to see core development taking
are also welcome.
Martin
chris...@gmail.com
> I think that the 'pointed language' on *both* our parts is a result of
> the long-term frustrations with the process. Regrettably, those
> frustrations sometimes lead to a bit more 'heat' and less bit less
> 'light'. Thanks for looking past the words to get to the meaning.
My pleasure. I enjoy a good frank discussion. It seems we have reached
some agreement on abstractions of problems and solutions. The next
step, then, would be to make some of the vague solutions into
practical proposals.
We already have a few concrete things in progress:
* Move the code to github to "blow the dust out" and improve
accessibility
* Tidy and migrate the tickets
* Migrating tiddlywiki.org (I hoping this will have secondary effects
of encouraging engagement, but that may just be hope)
Some of the other things probably need to be narrowed down a bit.
1) We know that we want greater information sharing from the "core team"
(whoever that might be) about:
* changes planned for the next release
* changes and the impact thereof in the current release
but what form this should take is not yet clear. Some seem to argue
that the presence of a ticket or a reference to it is enough. Other
suggest that commit messages ought to be enough. Experience suggests
that neither of these are satisfactory for the full breadth of the
TiddlyWiki community. If there were endless resources a series of
translators would be nice, but resources are not endless so something
else needs to happen.
2) We also know that we want much more timely turnaround time on
evaluating and processing tickets. I suspect that setting strict
guidelines for this sort of thing will just lead to disappointment.
That is, it is better for us to record a spirit of intent rather
than a letter of the law. From our conversations it seems the most
relevant spirit to uphold is acknowledgement.
3) We want a greater diversity of people, thought and code in the core
development process.
4) And finally, we know that there is work to do here. Not only to
keep the "core" in proper shape, but to improve it and to improve the
ecosystem around it such that there are positive feedback loops.
(In my own mind, on this particular issue, I keep coming back to
restarting chef, in part as a way of allowing assemblages of only some
parts of the core.)
I would think that immediate next step is continue with the migration
of the core code to github and getting to work on pending stuff. If an
expanded group of us participates in that any issues will soon be
revealed.
Agreed? Any additional stuff?
More comments within:
> Basically, after a long time of feeling like I'm on the outside, cut
> out of "the loop" and banging my head against a brick wall, I gave up
> trying.
In the small world of tiddly stuff, this is tragic. Unfortunately
we've seen the pattern a fair few times: With you, the Bairds, Udo,
Saq, others.
That's not how it is supposed to work at all. In fact the usual
trajectory for a maturing open source project is that the original
maintainers fade into the background as figures of hazy legend while
new ones become the keepers of code, commits and tickets.
> Extra thought: THANK YOU! This is the discussion we've been needing
> for YEARS!
Thank _you_ for participating. Now I hope we can get additional people
in the mix. While the Chris and Eric show is fun and all, it isn't
going to get us too far.
PMario
I like the idea, having a repo, that doesn't change weekly.
I also like the idea, using the newest stuff.
I think, having the core moved to github, can provide both.
I feel comfortable if a stable core moves on every half a year of even
every year.
On the other hand, I think the core needs to react more quickly, if
there is a major jQuery release. I think the decision, to use it,
created this dependency. At least, there should be a beta, available
immidiately. Having a new (stable) core release IMO can wait until
there is the first bugfix version. (http://docs.jquery.com/Roadmap no
need to have 2 (stable) core releases within one month).
I have no problem, if there are 2 (beta) releases within one month.
Since github is a network of trust, every user can decide, which core
to use. If you like the conservative approach, go with the
conservative core. If you like the community approach, go with the
community core, if there is one.
I think this is very common, with open source projects. In the long
run both will win.
=====
I think backwards compatibility is important. And I think the TW core
does very well. But as a user, I don't expect, a 4-5 year old plugin
to work with the newest core. It is a nice to have. But if it means
the core development, needs to be inactive, no thanks. (long live IE6)
And I also think it isn't necessary. Think of TiddlySpace. Every
plugin, that programmatically saved a tiddler was broken due to
missing fields. At the very beginning there were some posts in the
group. But since several month. Nothing ... Either, the users don't
use these plugins anymore, or they got them fixed. There was no need
to stop the core.
-m
Paul Downey
> 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."
>
> I think this is unfair. Any TiddlyWiki changes that break
> compatibility, or even might break compatibility are made into tickets
> and put on the release roadmap. Typically each point release has 15-20
> tickets and there is plenty of time between a ticket being put on the
> roadmap and the release including that ticket - indeed the main
> complaint is that the release process is too slow. I don't understand
> the accusation that plugin developers need to "scramble and catch up".
Indeed. One of the advantages of the monolithic repository comes from
cooking plugins and verticals against the latest core version from
subversion. We've spotted quite a few issues before even a beta is
released.
> Although it may not have been visible, I was a considerable advocate
> for Eric in incorporating his changes into the core, often against the
> judgement of others at Osmosoft.
Quite. And to somewhat simplify my position, I've been a strong
advocate for removing features from the core, and devolving them into
plugins.
> 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.
Quite so.
> "The tyranny of the legacy"
> I think this is a difficult area. One of the reason I take a fairly
> conservative approach is that there is no plugin upgrade mechanism for
> TiddlyWiki. Which means if a user upgrades their tiddlywiki and it
> stops working it is actually quite difficult for them to get it
> working again. Even if the plugin developer has upgraded their plugin,
> the plugin is not upgraded automatically when the user upgrades their
> tiddlywiki.
I think this is the biggest issue for TiddlyWiki. Most people expect
minor releases to be backwards compatible, so maybe we should bunch up
a group of breaking changes and plan a 3.0 release. I'd suggest a
different default theme and colour scheme at the same time which could
be as simple as a different ColorPalette and a font-size: 1.0em;
> Some of my comments above may sound like they are defending the status
> quo - they are not meant to be. Rather they are explaining some of the
> reasons around why things are as they are.
I applaud Martin for a reasoned response. The move to git/github isn't
a silver bullet, but it's an exciting opportunity, let's not spoil it
by personal attacks, please.
Martin Budden
1) "Some seem to argue that the presence of a ticket or a reference to
it is enough. Other
suggest that commit messages ought to be enough."
I'm one of the ones that argues that a ticket should be enough. From
your comment I presume you don't. But to move on we need to understand
why a ticket is not sufficient. Rather than a rather vague comment
such as "exerience suggests this is not satisfactory", I'd rather have
some concrete reasons as to why this is not satisfactory so that they
can be addressed. For example, is the problem using trac milestones
and the ticketing system, or is it that the tickets themselves do not
contain enough information?
Bear in mind also that TiddlyWiki is a relatively small project, both
in the size of the codebase and in the number of people actively
invovled. Something like RFCs, python PEPs or Java JSRs would, in my
opinion, be overkill.
2) We also know that we want much more timely turnaround time on
evaluating and processing tickets.
Agreed.
3) We want a greater diversity of people, thought and code in the core
development process.
Most certainly agreed. This was one of the things I tried to encourage
when I first started working on TiddlyWiki, but unfortunately to
little success. Related to this I think we should remember the
non-English speaking community. For example there, as far as I can
tell, relatively large communities of Chinese and Japanese users of
TiddlyWiki.
4) And finally, we know that there is work to do here.
Also agreed.
Martin
chris...@gmail.com
[keeping people informed]
> I'm one of the ones that argues that a ticket should be enough. From
> your comment I presume you don't. But to move on we need to understand
> why a ticket is not sufficient. Rather than a rather vague comment
> such as "exerience suggests this is not satisfactory", I'd rather have
> some concrete reasons as to why this is not satisfactory so that they
> can be addressed. For example, is the problem using trac milestones
> and the ticketing system, or is it that the tickets themselves do not
> contain enough information?
I'm summarizing what I've read from other people participating in this
and other threads related to TiddlyWiki, as well as threads related to
informing users of TiddlySpace. In both cases neither tickets nor
commit messages were considered sufficient to do either of the following:
* Keep people who wish to participate in active development aware of
opportunities.
* Keep people who wish to use new releases or new features aware of
the changes and features.
I'm one of the people who has said, to the people who are supposed to
keep http://blog.tiddlyspace.com/ up to date, "Just read the commit
messages". I was told that wasn't good enough, that it was my
responsibility as one of the tiddlyspace core developers to provide
accessible summaries with at least a bit of narrative. Eric has
described a similar need in the TiddlyWiki context. FND as well.
The problem isn't that commit messages and tickets "do not contain
enough information" but rather that they contain the wrong
information, or rather, information in the wrong form for consumption
types in the list above.[1]
In my perfect universe that wouldn't be the case, but "experience
suggests this is not [the case]". We aren't in that world. Therefore
we need to adapt.
> Bear in mind also that TiddlyWiki is a relatively small project, both
> in the size of the codebase and in the number of people actively
> invovled. Something like RFCs, python PEPs or Java JSRs would, in my
> opinion, be overkill.
Goodness me, no.
What we're talking about here is as simple as two things:
* writing narrative user-oriented release notes
* being forthcoming in this group where forthcoming means
conversational about what people who are working on the core are up
to and thinking about. Constant, ongoing dialog about what's
happening.
[1] It's important for me to state that I stand by my assertion made
in a few different places that good, verbose commit messages are
important. Code shows the result of a thinking process, it does not
narrate the thinking process itself.
Måns
Since github is a network of trust, every user can decide, which core
to use. If you like the conservative approach, go with the
conservative core. If you like the community approach, go with the
community core, if there is one.
I think this is very common, with open source projects. In the long
run both will win.
=====
I think backwards compatibility is important. And I think the TW core
does very well. But as a user, I don't expect, a 4-5 year old plugin
to work with the newest core. It is a nice to have. But if it means
the core development, needs to be inactive, no thanks. (long live IE6)
And I also think it isn't necessary. Think of TiddlySpace. Every
plugin, that programmatically saved a tiddler was broken due to
missing fields. At the very beginning there were some posts in the
group. But since several month. Nothing ... Either, the users don't
use these plugins anymore, or they got them fixed. There was no need
to stop the core.
Eric Shulman
> Well, - I'm not a programmer and I recon there are many "different roads to
> take" - preferences of style, if you like... However I have come to the
> conclusion that Eric is not "just" a gifted programmer in the normal meaning
WOW! How can I possibly respond to such kind words, except:
*SMILE* *BLUSH* thank you!
-e
Måns
WOW! How can I possibly respond to such kind words, except:
*SMILE* *BLUSH* thank you!
Paul Downey
> (tiddlytools) great plugins (especially import/export UI's and features)
> would be acknowleged as a standard which users of TiddlyWiki have come to
> expect from TiddlyWiki, and therefore investigated and copied into
> TiddlySpace by TS core developers...
Anyone, including you can do this as of now. But it would be a fork,
require a lot of changes to work around the use of embedded and
evaluated JavaScript, which are inappropriate in a shared JavaScript
environment, and then have to track Eric's changes in TiddlyTools.
Måns
Anyone, including you can do this as of now. But it would be a fork,
require a lot of changes to work around the use of embedded and
evaluated JavaScript, which are inappropriate in a shared JavaScript
environment, and then have to track Eric's changes in TiddlyTools.
Paul Downey
> any of the "killerfeatures" (maybe just some of the css) it has, and
> combine them with options and plugins that I know from other
> circumstances...
TiddlySlidy, etc deliberately have the asthetic of being complete
products, but are made from a collection of TiddlyWiki plugins. I
haven't made a good fist of explaining that, but you can see this from
the source code recipes:
http://svn.tiddlywiki.org/Trunk/verticals/TiddlySlidy/plugins/split.recipe
You seem to be asking us all to standardise on using plugins from
other developers. Actually one developer. Which plugins a developer
uses is all a matter of taste and judgement and may involve a number
of factors, size, complexity, security, reliability, self-development,
testing, being in source code control, licensing, speed, etc, etc. Or
just a matter of style.
Programming isn't a zero sum game, and there is room for many
different overlapping plugins all coalescing on TiddlyWiki core.
> However as a user, who loves TW for it's tweakability, I'd expect some kind
> of a follow up after a finished project like TiddlySlidy or FamilyTree - sth
> like a "do it yourself from a normal TW" - recipe. That would be really,
> really nice :-)
Documentation, and publishing verticals is an area where enthusiasts
like yourself, who don't develop code can contribute.
> I hope that I'm not asking too much - please correct me if I am..
I guess some of your concerns stem from one of TiddlyWikis greatest
issues: lack of discoverability for plugins. A conventional repository
of individual plugins is what I hear most newcomers expecting, and
failing to find.
FWIW, I publish my plugins, along with tests, documentation and
examples, one-vertical per plugin, in anticipation of a repository,
here:
http://whatfettle.com/2008/07/
Måns
... but you can see this from
the source code recipes:
http://svn.tiddlywiki.org/Trunk/verticals/TiddlySlidy/plugins/split.recipe
You seem to be asking us all to standardise on using plugins from
other developers. Actually one developer.
Which plugins a developer
uses is all a matter of taste and judgement and may involve a number
of factors, size, complexity, security, reliability, self-development,
testing, being in source code control, licensing, speed, etc, etc. Or
just a matter of style.
Programming isn't a zero sum game, and there is room for many
different overlapping plugins all coalescing on TiddlyWiki core.
> However as a user, who loves TW for it's tweakability, I'd expect some kind
> of a follow up after a finished project like TiddlySlidy or FamilyTree - sth
> like a "do it yourself from a normal TW" - recipe. That would be really,
> really nice :-)Documentation, and publishing verticals is an area where enthusiasts
like yourself, who don't develop code can contribute.
> I hope that I'm not asking too much - please correct me if I am..
I guess some of your concerns stem from one of TiddlyWikis greatest
issues: lack of discoverability for plugins. A conventional repository
of individual plugins is what I hear most newcomers expecting, and
failing to find.
FWIW, I publish my plugins, along with tests, documentation and
examples, one-vertical per plugin, in anticipation of a repository,
here:
PMario
> .... At the very beginning there were some posts in the
> > use these plugins anymore, or they got them fixed. There was no need
> > to stop the core.
>
> I don't agree :-)
> IMHO:
>
> I was one of those users, who tried to make some of the most vital (to me at
> least...) plugins/transclusions work on TS.
> I managed to fix a few (two or three in all... "TiddlerNotesPlugin",
> "QuickNotes","CreateTiddlersFromCSV" and maybe one more - don't remember..)
> The reason why I haven't kept on reporting incompabilities on the TiddlyWeb
> group - is the fact that most of these discussions now take place on the
> TiddlyWiki usergroup instead.
problems.
> My hope or vision if you like - (initially) was that most of Eric's
> (tiddlytools) great plugins (especially import/export UI's and features)
> would be acknowleged as a standard which users of TiddlyWiki have come to
> expect from TiddlyWiki, and therefore investigated and copied into
> TiddlySpace by TS core developers...
Eric's site state:
"There are 447 tiddlers, including:115 plugins+76
transclusions(2038607 total bytes)"
And I haven't seen indications, that Eric want's to _move_ to TS.
There was a post from Eric, that most, or all transclusions (76) need
rewriting, because of the "evaluated parameter" security issue. That's
a hell lot of work.
And .. As I understand tiddlytools "Terms of use" first paragraph
[1], imo it clearly explains, not to do so.
> New social channels ...
> From my adventures in TS-land I've discovered that there's a genuine wish to
> create new "social channels" around the "TiddlyWikiProject" and I hope that
> Eric (or his Legacy) won't get lost in the process. I really wish that Eric
> would get into the TS-game.
snip
> I wish we had a ratingsystem where everybody could vote for plugins to be
> tested against a beta-release, - then core-developers and/or
> plugin-developers would know what to test and eventually fix anticipating a
> release meant for upgrade..
pessimistic about this. [2]. But I deffinitly think it's worth it :)
> I believe that Eric's standards for plugindocumentation and TiddlyTools
> itself could be simulated by TS in some form - I don't see why not...
-m
[1] http://www.tiddlytools.com/#LegalStatements
[2] http://groups.google.com/group/tiddlywiki/msg/569d7f8cd66b71f1?hl=en
Paul Downey
> documenting his plugins (how it's seen at TiddlyTools...) was a standard
> which was followed by all TWDevelopers.
> 1) Plugin,
> 2) PluginInfo,
> 3) Examples of usage - maybe even a
> 4) Usercase vertical, setup for immediate use: like Eric's
> Quickstartdocuments
Yes, I agree people should follow conventions, ("standards" isn't the
right word) and I do provide most of the above if it's a plugin I
anticpate others reusing. I personally don't much like the separate
"PluginInfo" tiddler, and always publish a plugin in a vertical, but
that's a matter of style.
I'd also off two important additions:
5) some tests
6) a link to the plugin source code control
e.g.:
http://whatfettle.com/2008/07/StaticMapPlugin/
http://whatfettle.com/2008/07/TiddlySpaceLinkPlugin/
Eric Shulman
the code in a single tiddler. While this provides a good *initial*
learning experience for the user, the documentation isn't actually
necessary in order to use the plugin. In some instances, the
documentation is nearly as large or even *larger* than the plugin code
itself. If several plugins are installed in a document, the resulting
wasted extra overhead for the documentation can really add up quickly!
To address this, some people would edit the plugins they installed,
and strip out all the documentation and keep just the functional code
section. However, this has a huge potential to introduce errors while
hand-editing the plugin content and also prevents easy upgrading of
plugins without hand-editing each time. In addition, it removes the
credits/backlinks that point to the official distribution of the
plugin and, if the document is shared with even one other person, it
then re-distributes the stripped-down, uncredited plugins to others.
In order to discourage these kinds of changes to plugin content as
well as address the practical concerns regarding the overhead used by
plugin documentation, I started to split the larger plugins into two
pieces: the primary SomeNamePlugin, and the associated
SomeNamePluginInfo. This allows people to import both a plugin
tiddler that still has a small amount of non-code information (i.e.,
the credits/backlinks, revision summary, etc.) as well as a
documentation tiddler with all the remaining non-code 'instructional'
content. Once they have read and understood the instructional
content, they can easily discard the Info tiddler(s) and avoids the
overhead from having the primary documentation stored in each and
every document.
-e
chris...@gmail.com
[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.