TWiki Ideas

Not yet sorted - just things that I find interesting...

and probably mostly obsolete for the rest of the community. So let me just hide it. more... close

• Recent experience has added one issue which needs my attention more than everything else on this list: Make TWiki easier to use, in particular close the gap between "power users" and first-time contributors.
  • No more autolinking. CamelCase is so bloody fashionable these days that too often there are links where there shouldn't be. Needs work in templates, forms, many other details. People quickly get used to [[use some text]] for linking. They hate it when they have to write [[Otherweb.UseSomeText][use some text]] if linking to other webs, though. Doesn't happen too often? Just think of Main.TheAuthor....
  • Get rid of the dot - as already discussed. People want topics named TWiki4.2 - period. Telling them they should write TWiki4dot2 doesn't really work.
  • Get rid of Pseudo HTML. Yet another major incompatibility (though perhaps doable as a plugin). People with a background in HTML, or Docbook, or even LaTeX frown at the inconsistent behaviour of HTML tags (like <blockquote>) and pseudo-HTML (like <verbatim>). There are some interesting concepts to exploit behind that. Covers <nop> (a particular nuisance because there is no </nop>), <verbatim> and <literal>, <noautolink>, and even plugin stuff like <render>.
  • Better readability for multiline TWiki variables (like Formatted Search monsters). Sort of like the /x modifier in Perl's regular expressions. So that the power users can document their voodoo for others who want to create their very first TWiki application.
  • A TWiki variable for comments. Not comments in the sense of CommentPlugin, but comments which allow power users to document what they're doing. HTML comments are just a unsatisfactory workaround: TWiki variables within HTML comments will get processed, so you need to escape them, obfuscating the examples in the comments.
    • Paraphrasing Damian Conway: Always write a formatted search if the guy who ends up maintaining your topic will be a violent psychopathic who knows where you live (Perl Best Practices). It might be yourself.
• TWiki performance improvement: Work on BenchmarkFramework
  • TWiki is said to be "slow" - but where does it spend its time?
• TWiki to go - run TWiki on top of CPAN's HTTP::Daemon: Why bother with Apache?
  • Would allow a pre-configured demo without any additional (and sometimes difficult) settings
  • A PIM TWiki could be completely stored on a memory stick and run on every computer wherever Perl is installed
  • GilmarSantosJr has done great work in this area - congratulations!
• Work on RegistrationBeyondDakar. Many topics in Codev and support seem to indicate public interest in the area. The divergence between setups is increasing:
  • Intranet: LDAP server available in the network, domain controller login, etc. There should be corporate interest for either funding or collaboration on intranet integration, so I'm hesitating to invest too much of my spare time.
  • Internet: no central servers for the community, fighting SPAM is the most important issue. Hasn't been my top priority until I got a internet TWiki to maintain
• MiniAhah - a sidestep into the AJAX direction. More just for fun than driven by a requirement.

</>

The reason is that it is very unlikely that I'll contribute any features to TWiki in any reasonable timescale. The odds against it are beginning to be overwhelming. This is not an ordered list, on purpose.

• I've done almost all things TWiki in my spare time, i.e. on late evenings and weekends. There are other competitors for these hours, so unless doing TWiki is as much fun, it loses.
• My corporate TWiki is running 4.0, and again I consider whether upgrading to 4.2 is worth the effort, and again the answer is probably "no".
  • There's no demand for the PatternSkin improvements which came in 4.0.2 because I hacked my own "skin" to make my TWiki compliant with our corporate styleguide. Pattern has no chance to get this right, not even the most recent version.
  • There is no demand for YUI and other AJAX monsters since MiniAhah can do all we need, at a much less steep learning curve.
  • There is no big demand for WYSIWYG since most contributors just fill out forms. There's no WYSIWYG for textareas in forms, but TML works just fine.
  • There is no demand for refactoring of user code, since we have automatic registration of users who are automatically authenticated against a Microsoft AD. It was close to get integrated in TWiki 4.0, but was too late then (feature freeze), and since then TWiki's user management is rewritten for every release, faster than I have a chance to catch up.
  • The SQL search would be interesting for advanced users, but the very same advanced users would have all the work when upgrading, and they are pretty good with hacking complex searches right now.
• Whenever I start to develop something in TWiki, I start with running the unit test suite. If it breaks, I try to find out why, and occasionally submit a patch. Since 4.0, the unit test suite practically never ran without errors, and the developers which introduced the errors ignored them for weeks. It is much more time consuming for me to find out what they did than it would have been for them to not commit before the tests ran ok. Often the evening was over when I understood why the tests failed.
• Running the tests is getting more and more difficult. For every release, there are some more additional steps.
  • Interpreting the results, however, has improved vastly in 4.2.
• The overall code quality has decreased. Yes, I know, Cairo was pretty weird, and had weird coding conventions, too. But it had conventions. Now we have no conventions at all, and untidy sources all over the place:
  • Still too many SMELLs and TODOs in the release, and too little activity to resolve them.
  • Cinemascope lines (>150 columns), hard tabs (at 4 spaces), write-only variables, undocumented designs make it too tedious for me to understand new code.
  • Everyone seems to be developing his own debug trace. Monitor, ASSERT, print STDERR (commented out in the release). Every developer seems to think that it is fun to find out how to activate his tracing provisions.
  • Lots of TWiki-isms "for performance reasons" made any deep-inspection comparison between 4.1 and 4.2 useless, so all my old data are void.
• The debate about which logo comes first in which size on the press release and t.o topics was more than annoying - it was demotivating. Should I name my family as sponsors, since they donated family evenings?
• Quite a few functions have been developed not because it has been discussed in the community, but "because my customer wants it so". I do not like some of the recent changes but can not (nor do I want to) compete against developers who get their work paid.

It looks as if the number of active contributors is diminuishing over time, but that may be just a subjective impression. Anyway, I am not going to be swimming against that trend.

-- Contributors: HaraldJoerg

Discussion

Thank you Harald for your candid feedback. The community is learning from mistakes; it is impossible to fulfill the needs of all stakeholders. It is my personal goal to broaden the community, e.g. recruit more developers and make it easier to get started. That is one topic I'd like to cover in the TWikiCommunitySummit2008Q1 in mid February. It would be ueber-cool if you could participate. Can you convince your family to have a nice vacation in sunny California?

-- PeterThoeny - 22 Jan 2008