Rejuvenate Community

For the past few years, TWiki has been evolving steadily keeping its stability. But to secure long-term health of TWiki, we should have more contributors. Let's brainstorm how we can achieve that.

-- Contributors: Hideyo Imazu - 2014-02-07

Discussion

Needless to say, here are some ideas, not proposals.

Raise the bar

To attract new developers, at least we should not repel them.

twiki.org - our showcase

• Making http://twiki.org/Web/Topic canonical URLs keeping http://twiki.org/cgi-bin/view/Web/Topic available. It's only a matter of Apache mod_rewrite configuration and not a big deal but http://twiki.org/Web/Topic URLs look better and poses better impression than http://twiki.org/cgi-bin/view/Web/Topic
• Getting rid of ~twiki4 from http://develop.twiki.org URLs

Following the current norm

• Using Git as source repository. Young developers may think it odd that TWiki is not using Git
• Using a real issue tracker such as Bugzilla (written in Perl and free) and JIRA (free community license for open source projects, TWiki has JiraPlugin)
• Adopting a continuous integration mechanism such as Jenkins
• Requiring Perl 5.8 (preferably 5.10) and stop supporting 5.6

Strategic enhancements

• Supporting other markup than TML - POD and Markdown seem to be low-hanging fruits. By POD support, TWiki can help Perl community a lot.
• Better support for raw text editing - there are users who prefer raw text editing but don't remember TML well because they need to deal with other markups such as Markdown, MediaWiki markup. Raw text edit page having buttons to enter TML pieces will help

-- Hideyo Imazu - 2014-02-07

Good points here, Hideyo-san. I would put Git at higher priority.

In addition:

• Look at places to recruit Perl developers, such as Sourceforge.net
• Brush up the GettingInvolved topic
• Finish the TWikiAppInstaller and app repository so that ISVs and consultants can create TWiki apps (free & for sale)

-- Peter Thoeny - 2014-02-07

All these are valid points. But though I surely am a bit out of sync with TWiki, I have some doubts about whom you're going to address.

• Git is fine with me, though I would not qualify as a young developer.
• Perl 5.10 is also fine with me. My oldest NTAR-system has 5.10, and recent ones go up to 5.16.
• I can't see any urgency in using another issue tracker. In various projects I have been working with Bugzilla, RT (also in Perl!), Sharepoint and Jira, and none of them have any compelling advantages over what TWiki can do. For me, TWiki's bug tracker has always been a good real-life example for a TWiki application.
• Other markup is targeted at people who are creating content, and I agree that the various markup methods can be annoying for someone who is working with different applications. But both POD and Markdown lack a lot of TWiki features, and there already are ways to display these markups as HTML. By the way: I'm frequently using Org mode for stuff I am unlikely to share. I guess there are gazillions of alternative markups one could consider.
• Though Jenkins is fine software, I'd consider it to be more an extra hurdle than an enabler to attract developers. It isn't Perl, so I would need to care for yet another runtime ecosystem.

From the opposite point of view: Here are some things which have kept me from upgrading TWiki for years, but I have no idea whether I'm an outlier or nor:

• As an user: The TWiki 6 welcome page looks awesome after installation. However, it doesn't serve as an example of how easy it can be to create content in TWiki. Everyone seems to make his first attempt to hit the edit button on the welcome page - and then doesn't understand what's going on when looking at its source. I would be happier with a less fancy page with an easy-to-understand source.
• As a site admin: I want TWiki to fit into my corporate intranet ecosystem (e.g. have the same navigation in places where users expect them to be). The TWiki skin and template mechanism is awesome, but so far I failed to find easy-to-use guidance how to leverage its possibilities. I admit that this was also true in TWiki 4: I finally decided to write all the template pages from scratch, which enabled me to re-use HTML blocks, banners and CSS files from the corporate intranet. I might decide to do that again for TWiki 6.
• As a developer: I agree that GettingInvolved could use an overhaul. I found KampalaRelease even more disturbing and fail to see which topics are actually worked on, and which are sound asleep. May I suggest that the whole list is moved to a parking yard and the pages shows only those issues where the active developers can demonstrate an impact on the user community?

Cheers,

-- Harald Jörg - 2014-02-14

Peter, regarding TWikiAppInstaller, I sometimes feel TWiki is too flexible for many users. TWiki can do many things but it takes TWiki knowledge and decent amount of time investment in many cases. It would be great if various use cases/features are packaged as "Apps" or "libraries" and made available for non-TWiki experts.

-- Hideyo Imazu - 2014-02-17

That is the whole point of the app installer and app packaging standard: Developers/technical folks create apps, and end users browse the app store and choose apps to install. Apps should be created with easy point and click operation in mind. That way we can substantially lower the complexity of TWiki.

-- Peter Thoeny - 2014-02-17

Hi, has there been any consideration to allowing markdown to be used in some areas of TWIKI, Markdown is becoming a pretty much defacto standard for developer markup and it would be great if Twiki supported this

-- Fred Bowker - 2020-10-01

Not at this time. I think it is feasible to create a plugin that intercepts the edit and save to translate TML => Markdown => TML. However, the TML has a much larger feature set, so the question is what to do with that. Once a topic is edited in Markdown, is it locked to Markdown? Best to discuss in new topic TWikiWithMarkdown.

-- Peter Thoeny - 2020-10-03