If you have ideas of what plugins you'd like to have installed here at TWikiDotOrg please list them here. currently, the following plugins are installed:
TWiki06x01.SpreadSheetPlugin, AutoSectionsPlugin, BackupRestorePlugin, BlackListPlugin, CalendarPlugin, ChartPlugin, ColorPickerPlugin, CommentPlugin, DatePickerPlugin, EditTablePlugin, GaugePlugin, GeoLookupPlugin, HeadlinesPlugin, IfThenActionPlugin, InterwikiPlugin, JQueryPlugin, LocalCityTimePlugin, PercentCompletePlugin, PerlDocPlugin, PreferencesPlugin, QRCodePlugin, RecentVisitorPlugin, RenderListPlugin, SetGetPlugin, ShareMePlugin, SlideShowPlugin, SmiliesPlugin, SyntaxHighlightingPlugin, TWikiDrawPlugin, TWikiOrgPlugin, TWikiSheetPlugin, TablePlugin, TagMePlugin, TinyMCEPlugin, TwistyPlugin, VarCachePlugin, WatchlistPlugin, WysiwygPlugin

NB. A generic argument against plugins on TWiki.org is performance - every plugin has some performance impact. PluginsRegisteringTheirVariables and EnhancementsToThePluginAPI have some ideas around improving this.

SubscribePlugin

New and occasional users of TWiki.org would especially benefit from being able to subscribe by email to particular topics. They might write a support ticket and no one answers for 3 months. Many people will leave an enquiry and forget to come back.

Most other wikis have this feature built in. It's a standard feature. Many newbies might be forgiven for thinking TWiki doesn't offer this feature at all.

Installing Subscribe Plugin and a corresponding "Subscribe/Unsubscribe" button would attract more people, show answered questions more quickly and bring people back who only visit casually.

Even if subscription notifications are sent out by a different machine, this should be done

8

MartinSeibert

20 Oct 2008

6	MartinSeibert	31 Aug 2008		7	FranzJosefGigler	15 Oct 2007
9	MartinCleaver	12 Oct 2007

Share your opinion of this idea by selecting one of the radio buttons below and clicking the button. It would be nice ... 1 2 3 4 5 6 7 8 9 ... I want this so much it hurts

CompareRevisionsAddOn

Hasn't everyone wanted inline word diffs for a long time?

Please let's help test out this plugin and get it installed on twiki.org

• Proposed by: WillNorris - 20 Jan 2005

9	RafaelAlvarez	22 Jan 2005
9	TravisBarker	21 Jan 2005
9	ColasNahaboo	21 Jan 2005
6	PeterThoeny	21 Jan 2005
9	MattWilkie	20 Jan 2005
9	SvenDowideit	20 Jan 2005
9	BillGatliff	20 Jan 2005
7	MartinCleaver	20 Jan 2005
8	RobKirk	20 Jan 2005
11	WillNorris	20 Jan 2005

Share your opinion of this idea by selecting one of the radio buttons below and clicking the button. It would be nice ... 1 2 3 4 5 6 7 8 9 ... I want this so much it hurts

Nice add-on, very intuitive presentation.

Before we install the Add-on on TWiki.org, could someone review the code for security?

-- PeterThoeny - 21 Jan 2005

Will asked me why I downgraded my rating: this simply because although this compare revisions both pretty and useful, I'd rather get ActionTrackerPlugin installed. That would allow us to mark our dependencies on each other and track and progress for their completion.

-- MartinCleaver - 21 Jan 2005

ActionTrackerPlugin

I'd like this installed to make requesting things off other members of the community easier. It would also help me to track what I have made commitments on.

• Proposed by: MartinCleaver

7	MartinSeibert	31 Aug 2008		9	TravisBarker	31 Oct 2004
9	SvenDowideit	31 Oct 2004
8	RafaelAlvarez	27 Oct 2004
5	CrawfordCurrie	20 Oct 2004
8	LynnwoodBrown	20 Oct 2004
9	WillNorris	19 Oct 2004
7	MartinCleaver	19 Oct 2004

Share your opinion of this idea by selecting one of the radio buttons below and clicking the button. It would be nice ... 1 2 3 4 5 6 7 8 9 ... I want this so much it hurts

Comments / factors other than agreement

being able to manage (sub/mini) projects as CrawfordCurrie has described elsewhere seems to me to be an integral part of the PostCairoDevelopmentModel and the DakarRelease as it would facilitate collaboration

-- WillNorris - 19 Oct 2004

Dito to Will's comment. One reservation: without agreements regarding assignment of tasks (i.e. assignee must explicitly agree), this might turn into mechanism to badger already stretched core-team member (and other volunteers).

-- LynnwoodBrown - 20 Oct 2004

Can the ActionTracker be configured such that only the individual can assign to oneself? If not, we could always just agree that we don't assign to other people.

-- MartinCleaver - 21 Oct 2004

In a large web, such as Codev, it becomes important that one limit the search for actions to topics that are relevant. One might want to identify "groups of actions" that should be displayed together, but not all actions that are stated in a web. You can have this effect by naming all such topics following a regular expression and limit action search to those, but this convention will probably not scale. I suggest that action tracker might consider adding the option to search the tree of topics that form a parent/child hierarchy from a given topic.

-- ThomasWeigert - 01 Nov 2004

I see it premature to install this Plugin on TWiki.org at this point for two reasons:

• E-mail notification does not work due to SourceForge limitation
• No clear agreement on how to use it in the community

Once these two questions are solved we can use the Plugin. Any proposal on how to use it? Personally I love this Plugin to follow up on meetings, I am curious to know if/how it can fit for an opens source project.

-- PeterThoeny - 08 Nov 2004

If you love this plugin, Peter, then surely you too can imagine some ways we can use it. How about you install it and we do some experimentation?

As for email notification, if it is important we can just as easily build a replacement for TWiki::Net::sendEmail that queues outbound messages into a topic and then we build a remote sender on a different server that grabs them off the topic and emails them.

-- MartinCleaver - 21 Nov 2004

FormQueryPlugin

• Proposed by: MartinCleaver (MC)
• Seconded by:

#FQPTarget

9	SamHasler	04 Oct 2004
8	WillNorris	04 Oct 2004

Share your opinion of this idea by selecting one of the radio buttons below and clicking the button. It would be nice ... 1 2 3 4 5 6 7 8 9 ... I want this so much it hurts

Comments / factors other than agreement

on the fence

RandomTopicPlugin

• Proposed by: MattWilkie (MHW) - 29 Jul 2003

I propose the addition of a new gateway topic to Codev. It would have 3 columns each of which contain 1) this months Hot Topics and Contributors (a la WebHome) 2) the last 10 or 15 recently edited topics, 3) and 10 or 15 random topics

(not necessarily in that order; the Hot Topics could be dropped; WhatsNew might be a good name.)

Arguments For

There are now over 2000 topics in Codev which is more than enough for old discussions to remain undiscovered when the same old ideas arise anew with participants who weren't present for the last round. Theoretically over the course of time all topics would get exposure on the popular gateway page thus potentially rejuvenating TopicsThatDie, as well as adding entries to the loose associative in-your-head index we all carry. -MHW

Given there's no solution to TopicsThatDie at the moment - after all when did you last look at:

• EmbeddedTableBug - relates to including into a table fails abysmally. This has been declared to be a dead issue, but you could argue (quite easily) that the argument wrong is false - tables could be expanded before INCLUDES (which could be argued should have their contents expanded before inclusion), and in that case the intuitive example would work.
• EncouragingContributors - A discussion that lasted 2 days, and has died a death, but is actually quite an important issue.
• MakeTWikiCfgTWikiCfgDist - covers an issue/option relating to making upgrades less painful - and lasted a mighty single day discussion. The idea is useful though.
• Was Grant's question on LogDirectory ever answered?
• Did you ever get your request/requirement for your laptop that you mentioned in NoArchiveFileTillNeeded ?
• Did anyone ever consider the option of having parameters passed to the templating system so that OptionallyHideWebForm could be done in a more flexible manner?
• Did anyone ever take this simple but powerful idea forward? Or did it get forgotten ?
• Finally, has anyone taken the TWikiForge idea forward at all? (Strikes some chords with a number of recent threads...)

The majority of these I'd not looked at until just now. How did I find them? I took a snapshot of the Codev web (raw=debug), and flicked through at random the topped & tailled resulting .txt files. (Which due to not being really raw (specifically no tabs, etc) aren't suitable for use as a mirror of course, but are useful for browsing)

That said, an alternative method of bringing untouched pages down the ages to the fore again is to simply occasionally rename topics slightly that are referred to by 50-100 other topics and cause a small amout of churn on the web changes. (15 random topics at the top of webchanges however would also have the same effect of course. Over the course of a day if you have 42 views of WebChanges per day (1329/31 - current stats) that's around 450 topics that gets bounced past peoples eyes (best case, 15 worst case, in reality probably 100). Over the course of a week, virtually every topic would have an equal chance of appearing at the top of the web changes list.

Afterall, the output from the plugin can be made to look like this using it's format attribute:

• EncouragingContributors MakeTWikiCfgTWikiCfgDist LogDirectory NoArchiveFileTillNeeded OptionallyHideWebForm PoorManWorkFlow TWikiForge

Arguments Against

I'd rather see a more robust solution to TopicsThatDie, and a better way of navigating through gateway topics etc - see CodevFields etc.

[ RichardDonkin 29 Jul 2003 ]

• Since no-one is proposing anything better, it strikes me that this is a very poor argument. After all studies have been done that show that random selection comes close to being just as good as targeted selection on a sufficiently large user group. The most recent good example of this was the churn produced by the TWikiUnixInstaller rename - a flood of old "dead" topics resurfaced and moved on. Since those dropped off the WebChanges page TWiki's discussion mode has returned largely to being like an email system with a very poor (in comparison to email) interface. -- SomeoneElse
  • 'as good as' what? I really want to see better ConversationTracking, a subset of TopicsThatDie, which is best addressed through some sort of EmailNotificationEnhancements. More refactoring and consolidation into DocumentMode, as well as better navigation of Codev through logically structured gateway topics, would help people avoid creating new topics when there's already an existing topic on the same subject. BTW I think the refactoring of this topic into DocumentMode is premature IMO - it is easy to read this bulletted list and think initially that the same person made both comments, hence the nesting and SomeoneElse sig above. -- RichardDonkin

With all due respect, this is an argument for a better solution to TopicsThatDie, one which does not yet exist even as a proposal, not an argument against a partial solution, which already exists. [ MattWilkie - 17 Oct 2003 ]

---

RevisionLinkPlugin

• Proposed by: JonathanCline - 29 Aug 2003

Arguments For

• There's a convention here to refactor old topic text into topicname+"Old" or topicname+"Archives"; example: CoffeeBreak and CoffeeBreakArchives. This is rather odd, since all text is actually already archived in prior revisions. Instead, "old" topic text should be deleted with a heavy hand and a link appended to the topic, for instance, Older text can be read at %REV{"CoffeeBreak " rev="1.102"}% -- JonathanCline - 29 Aug 2003

Comments

1. These "hidden" texts are probably not searchable
2. Perhaps this is not an issue with long threaded texts - otherwise the valuable information would have been refactored and kept

-- ArthurClemens - 29 Aug 2003

I prefere the syntax of the RevRecoverPlugin. It's simpler and easier to remember.

-- SamHasler - 22 Mar 2004

---

PollPlugin

• Proposed by: MartinCleaver (MC)
• Seconded by: LynnwoodBrown (LB)

Arguments for

• There are many issues that we raise that would benefit from getting a collective sentiment for. PollPlugin appears to be a good solution, not least because many would agree or disagree but may not have enough to say to warrant going through the edit (and horrid preview) cycle. -- MartinCleaver - 16 Oct 2003
• I have long felt that the single biggest process shortcoming on TWiki.org is the lack of a quick-and-easy way to register support for some proposed action or preference among a range of options. Take this topic as an example, PollPlugin would allow users an easy way to show preference for which plugins they would like to see on TWiki.org. The current (rarely used) convention of manually editing a topic and upping a vote number is not sufficiently convienent to be effective, as evidenced by how few votes are registered when this has been used. For this reason, I think loading the PollPlugin is the simplest and most effective improvement that could be made to the decision making process within the TWiki community. -- LynnwoodBrown - 17 Oct 2003

BeautifierPlugin

• Proposed by: WillNorris (WN)
• Seconded by: MattWilkie (mhw)

Arguments for

• simple: we discuss code in this web. some samples: SaneAsylum:Sandbox.TestTopicBeautifierPluginBash, SaneAsylum:Sandbox.TestTopicBeautifierPluginPerl, SaneAsylum:Sandbox.TestTopicBeautifierPluginLua

I think this would be welcome. It would make it easier to share code snippets in the Plugins web (code which might be useful for something but isn't complete enough to be a plugin); supports SharedCodeProposal -- (mhw)

---

Contributors

-- MartinCleaver (MC)
-- MichaelSparks - 31 Jul 2003, 28 Aug 2003
-- PeterMasiar (PM)
-- RichardDonkin (RD) - 29 Jul 2003
-- MattWilkie (MHW) - 29 Jul 2003
-- AndreaSterbini (AS) - 28 Aug 2003

---

Related Comments

For the past few months (whenever SourceForge's load problem began to increase beyond all bounds), twiki.org response has been extremely slow. Again, this is a sourceforge issue, but adding more plugins to the site will exacerbate the problem. Usually it takes 5-7 seconds for pages to render during normal business hours. Yes, I've counted seconds.

-- JonathanCline - 28 Aug 2003

It's a general SourceForge issue. PeterThoeny has mentioned several times that the idea of a reliable hosting provider will be looked into. Nothing's come of it so far, but I'm sure he meant it. BTW, 5-7 seconds? You lucky person! Some of us consider ourselves lucky to actually get a web page back at all - let alone within a measly 5-7 seconds!

I hope that Peter has passed the issue onto someone else in the enlargened CoreTeam to resolve the issue if he hasn't had time to look into.

-- MS - 29 Aug 2003

(more comments interspersed in the text above)

---

TouchGraphPlugin

This new plugin cures most of the problems with the older TouchGraphAddOn, chief among the improvements is 1) the client doesn't have to install a JVM as now it is an applet instead and uses the native browser java plugin, and 2) the main browser window is used to view the follow up pages (the old java browser was functional but limited).

There are still some minor browser issues, but more widespread testing could shake these out. To begin with we could install TG in a low profile location, or at least make the touchgraph.txt downloadable for offline use of the die-hards.

-- MattWilkie - 01 Apr 2004

---

RedirectPlugin

• Proposed by: SamHasler (SH)

This would allow merging of duplicate topics with similar names and redirect one to the other so that CoolURIsDontChange. -- SH

I'm very fond of this plugin where I work. It's excellent for aliases or when two pages are merged. -VB

ExplicitNumberingPlugin

• Proposed by: VickiBrown (VB)

I would love this for the newsletters, among other things. It allows for headers (or paragraph-separated "bullets) to have proper numbering. I use it a lot where I work. VB

Installed Plugins

Comment Plugin

I would like to see the ability to quickly and easily add comments to certain pages on twiki.org. However I am against a free for all comments everywhere kind of setup. If there are no restrictions[*] Slashdot style ThreadMode discussions will proliferate everywhere and we will lose, in my opinion, an essential element of wikiness. TWiki.org already has a large problem with discussions not being refactored enough. - MHW

• Re: free for all comments everywhere : COMMENT could be only on pages where it has merit (added and removed as needed), allowing quick contribution, without preventing serious refactoring via standard EDIT. -- PM
• People will do what they want to do anyway. If this means to leave a comment on the end of the page then COMMENT might encourage them to say something where they might ordinarily say nothing. If they are intending to refactor then I am sure that COMMENT won't discourage them. -- MC
  • If we want people to refactor we have to give them an incentive to do so. Something like the Ratings plugin is likely to make a big difference in this respect. -- MC
• IMHO Twiki.org has 2 problems
  • page lock (sometimes) might prevent contribution - COMMENT will allow to post and unlock
  • not enough refactoring - due edit/preview/save is slow

[*] soft restrictions, social ones. Along the the lines of "Support questions go here, Bug Reports go there, and Usability Issues are thataway". - MHW

---

Just before releasing Cairo, I wanted to put the comment plugin in the template. Then I got the afterthought:

Now the CommentPlugin tag is used in topic text. If I include it in view.pattern.tmpl, people will get to see 2 comment boxes. If they then delete the version in the topic text, people using the default skin won't see the box.

Also for some pages it makes no sense to put it in by default (WebChanges for instance). So while I like the idea to have it on by default, not all cases are covered.

-- ArthurClemens - 07 Sep 2004

1. How about adding it to the Classic Skin too?
2. Can we make the comment box know that it has been already displayed on a given page and thus not display again? (bearing in mind we'd sometimes want it on twice)

-- MartinCleaver - 07 Sep 2004

After some consideration I agree with Arthur's view. A comment box should not be in the skin by default. Reasons: Too much UI clutter by default; two comment boxes will show up in topics that have already a comment box; on many topics it does not make sense to have a comment box; some topics have a certain place for a comment box.

-- PeterThoeny - 31 Oct 2004

A better place to put comment boxes would be in the new topic templates. I'll do it soon it soon if there are no objections.

It should be on:

• Codev.WebTopicEditTemplate
• Plugins.WebTopicEditTemplate
• Sandbox.WebTopicEditTemplate
• Support.WebTopicEditTemplate
• TWiki.WebTopicEditTemplate
• TWiki01.WebTopicEditTemplate
• TWiki02.WebTopicEditTemplate
• TWiki03.WebTopicEditTemplate
• TWiki04.WebTopicEditTemplate
• TWiki04x01.WebTopicEditTemplate
• TWiki04x02.WebTopicEditTemplate
• TWiki04x03.WebTopicEditTemplate
• TWiki05x00.WebTopicEditTemplate
• TWiki05x01.WebTopicEditTemplate
• TWiki06x00.WebTopicEditTemplate
• TWiki06x01.WebTopicEditTemplate
• WikiWed.WebTopicEditTemplate
• NewBugTemplate
• PatchProposalTemplate
• ?????

-- SamHasler - 01 Nov 2004