It's really embarrassing to post here.. Eric's problem is the community's problem, but there's no reason to discuss all the community's problems here.. Eric, I'll try to fight all the banking issues and establish constant donation asap.
But as this thread is that involved, it seems to be the best to go on here. This is rather strange to hear that TW is dieing (sorry, idk how this spells correctly). Eric's situation is a problem to solve, but not a reason to panic. However, this showed that the lack of documentation (here I mean "text that new user or a user which has a common question should read") is of great importance for community and the lack of it depresses many people. I understood this hindrance right when I found TW (I needed a way to write hypertext terribly and was seeking for mechanisms of interaction of web techs with file system, but found an established solution which had.. scattered documentation), so I decided that the only way to mantain hypertext properly was to write my own "documentation" within a TW instance. Now I really can't understand how other people fight the complexity of TW without such notes/"documentation", but it seems that -- quite problematically. Here, we've heard two main ideas about the documentation in the first sense -- or I'd call that "knowledge inheritance": * mantain consistent documentation * create a forum and some other infrastructure which would allow to contribute easily As for the second one, I can't say much as I've never seen a well- organized forum about such a complex thing like TW. But I would be careful and rather sceptical about the word "automatically" in the worfgang's post, as TW is about hypertext which is quite complex by its own, and TW is even more complex. I mean old-fashioned tree-like forums don't seem to be the way to go (in my "documentation" of TW transclusion is used here and there and convergion of different tree branches would likely make mess). But let it be, I'm not that confident in this matter. As for documentation in usual sense.. > A really centralized, comprehensive and easy to navigate 'How to manual' for > TiddlyWiki will very unlikely ever materialize I'd say yes and no. Yes -- meaning there's no way to create a comprehensive 'How to manual' -- because TW itself has it's own markup, styling system, data structures and macros, navigation, workflow issues and more and with such a massive of technologues "How to" is not a way to go. In my opinion, basic documentation can be only sort of reference book -- more strict, with high density of information. And not addresed to new users. Then, some howtos, can be "attached" (some already exist, like [1] or others) after that -- they should be small, simple, creative and probably rewritten from time to time. Because these are the most difficult and perhaps intimate questions -- what is TW and why one would benefit of it. In my feeling, TiddlyWiki is a framework for mind which endures with web and evolves with the community. However, this wouldn't be sufficient for a person which is not familiar with TW. Now my "no" to the citation is because I see the possibility that I turn my "documentation" written in russian for myself into a public documentation, but here are some serious issues: 1. I can't start publishing before I establish a "CMS" within a tw- document which would allow to write different "versions" of tiddler (short and with comments for personal use, public content in English and perhaps public content in Russian). This is essential because if I start to write a separate TiddlyWiki for documentation, it will sooner or later will slide apart from my main document in the logic of narration and after that texts will inevitably turn into a mess. This is what I faced many times with other texts; I call this a "split". I'm working on this system (basically it should do quite the same thing as multilanguage support), but do this quite slowly and in current circumstances it seems to be unacceptable. 2. I have no idea of how to turn such a thing into a contributable one besides making a blog where I can post announcements of updates and make preview of new chapters for preliminary discussion and clarifying some questions. 3. Such a documentation will reflect subjective intersts anyway and may make conflicts with developers' philosophy. On the other hand, if someone establishes an "infrastructure" for contributable documentation, I can provide material for each chapter and suggest the structure of the text. Although not everything is written in my document (for instance, descriptions of many macros are just sketches). As for now, I can show a "table of contents" of my current "documentation" (note, though, that the text is not fully linear): * [what is tiddlywiki, what are the unique features etc -- now skipped] * application notes (what for I use TW or think of using or am going to use) * working withing TW: ** syntax/markup and user-defined DOM ** styling ** user data structures (meaning tiddlers, tags, fields etc) and macros ** TW interface and pre-defined stuff (not very well written, but themes are discussed here and default interface like PageTemplate should be) ** navigation, editing and managing links ** workflow ** TW limitations and desirable extenstion (the latter should be ideally aggregated from the previous chapters) * TW extensions: ** extension types and their installation/usage ** extension repositories and navigation through them ** interesting extensions (ok, this is subjective, but should influence some previous chapters also -- like PasteUpPlugin which is mentioned in the "workflow" chapter) ** TiddlyWiki-based tools * TW in the context of file system, OS, browser, other TWs and systems of writing and/or the web (perhaps this one should be splitted): ** operability of TW in the context of FS environment and OS ** operability and interaction with browsers (sort of known issues, support details) ** local interaction of TW with non-TW files ** local interaction between TW documents ** TW for aggregation from the web (RSS aggregation, XMPPWiki) ** TW in the web ** [perhaps here will be the collaboration chapter, but I still have no experience in this] * Dev: writing extensions (this is not well-established part, so here only subsections I already have): ** notes ** writing plugins ** dev of macros ** desired plugins to develope, their states (subjective, but can be present in community documentation) * core code and architecture (even less established) ** exploring core code ** core models and algorithms (only notes) ** elements of API * personal section regarding ToDos, proposals, desires (community can have similar thing) * TiddlyWiki appearence; community and contribution (not very well established) A step back, though: I'd like to point that as tiddlywiki.org has migrated (and unfortunately not fully migrated) to [2], one thing got worse for sure: when one meets a MediaWiki page, he or she knows at once that he *can* contribute. The TiddlySpace version needs big link "how to contribute" to make this clear. But anyway, this rapid migration haven't solved the main problem: the need of fundamental text, not a pile of notes on different common things about TW. [1] http://www.giffmex.org/twfortherestofus.html [2] http://tiddlywiki.tiddlyspace.com/ -- You received this message because you are subscribed to the Google Groups "TiddlyWiki" 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/tiddlywiki?hl=en.
