We once deactivated the CommentPlugin
to increase refactoring and to prevent people from discussing endlessly on the wiki. I do not know, if that worked out right. I see a lot of discussions going on over the mailing lists, but too little activity on the wiki. That is why I would like to vote for enabling CommentPlugin on www.foswiki.org again.
What do you think? Please vote!
- Put Your Name
- Put Your Name
Either way suits me
- ColasNahaboo Either disabled, or enabled with guidelines (see comment colas1)
- Put Your Name
Pros & Cons
- Encourages rewriting of topics.
- Topic is more presentable, neat, to the point and concise.
- Make my work as release manager in Tasks web easier. Also easier for people to follow up.
- Dissuades any form of discussion
- Comment plugin makes a topic more presentable, neat, to the point and concise.
- Takes too long to put in comments in specific areas. It's easier to stick it into the comment section.
- Performance: You can interact very fast through the direct input field.
- It reduces email load on the mailing list.
- It creates much more activity on the wiki itself.
- The disabled plugin hinders interaction. A comment feature is common on other enterprise wikis like Confluence. In a lot of companies the comments are the only way some employees interact with the wiki at all.
- CommentPlugin is much more than a text field. You can make advanced templates so you can comment and change state of a support question or Tasks item. We are prevented from doing these smart things now.
Please insert without Comment Plugin.
- What's great about a wiki is, we are able to strike certain sections out, leave a visible comment on specific places. With a CommentPlugin, we can't. Somehow, we need to adopt a new culture, the wiki-culture. -- KwangErnLiew - 13 Mar 2009.
- We need the ability to round trip with email conversations. -- MartinCleaver - 13 Mar 2009.
I am indifferent to its activation. Though I appreciate Kenneth's point that it helps prevent editors from forgetting to enter a signature, I prefer just to edit a page directly rather than go through a wrapper. The whole point of a wiki is that it is easy to change any page, without requiring an extra layer just to add freeform text. I do appreciate that for the less technical-savvy, having an edit box directly on the page might be useful in some circumstances, though other techniques like the ability to edit sections also help address this.
I disagree with Martin's assertion that there is much discussion on the mailing list -- the only place there is a lot of discussion is on IRC. Having the comment plugin will not generate activity on the wiki by itself. Frankly, scrolling down to the bottom of the text box after clicking on "Edit" isn't onerous at all, so I do not believe the presence or absence of the comment plugin has much effect on the use of the wiki by the developer community. Personally, I believe other features such as a watchlist, a default template topic that included a dangling link to a Talk page, and a "Watch/Unwatch" link on each page would be useful steps to encourage more wiki-based discussions.
I believe that a number of the listed cons are strawmen: that is, they are assuming a certain way of editing topics that in fact is not the intent behind encouraging the rewriting of pages. In particular, the point is not to put comments in specific areas rather than at the end, but to keep the topic coherent, rather than a user having to read it all and then each of the comments in order, chronologically overlaying mentally the adjustments being made by each. For documentation pages, this is expecting far too much from the user. For example, I started to look at some of the topics on user authentication methods on twiki.org to see if I could migrate them to foswiki.org, but because they generally start with one person's configuration and then have a whole pile of comments afterward, each making suggestions and modifications, it is very difficult to understand what is the final set of instructions. Keeping the discussion separate from the actual document would make it much easier to follow. (Imagine trying to understand how to install Foswiki just by reading the installation guide change logs, instead of reading the actual document.)
Of course, there are some pages which do not need to be written into an overall cohesive document, such as pages that host discussions.
- 13 Mar 2009
I think the plugin is good for the convenience, but that its use should be paired with more encouragement to refactor the user comments into the page body itself once in a while. We did this with the original finding a name discussion, and it seemed to work out well. Seeing an old page with tons of comments where more actual content exists in the comments rather than above them IMHO should be blamed on not enough user editing / refactoring rather than having a useful plugin enabled.
Having the plugin disabled may put some focus on refactoring the page up front rather than just drop a note in the comment box, but could also dissuade users who do not have the time or inclination to consider page edits first. Other users (or the same user at a later time) could then edit and refactor later.
- 13 Mar 2009
A clarification - we are only discussing the enablement of CommentPlugin
on the foswiki.org website and it will be fully operational in the installed version of foswiki right?
Regardless of the disucssion above, can we please have the Plugin enabled on the Sandbox web in order to demonstrate how to use it and leave code for others to show ideas for its use......I have left some code but cannot show it working on foswiki so I feel that will hinder others at my stage of development, configuring foswiki, from improving the adoption of the wiki in their installation.
Also, I bet the other wiki to which foswiki is closey related has the plugin enabled and whilst this is not a competition, there are a good number of people (like me) who need a lots of ready made code to help them show the power of the wiki......I need it for my little journey at my company.
For me, operation outside the Sandbox - I think it is good, it separates discussion from agreed, refined text so please enable.
- 13 Mar 2009
The disabling on foswiki.org of a brilliant plugin has made me
- Pissed off because I cannot effectively follow up on Tasks web items.
- Cannot quickly comment on feature proposals
- Cannot make more advanced templates for CommentPlugin to enable comment + state change
The result. I have almost stopped contributing to Development web and Support web. I do not bother.
Most topics end up in discussion mode or a mix of first definition text, and then discussion. This is natural way of working. You cannot force people to not discuss by disabling a plugin
What went wrong on (tm)wiki was that the default topic template on Codev had the plugin COMMENT tag included so all topics ended up as discussions.
The right solution is to have the plugin enabled and used where it makes sense. But NOT have it included in the default topic template for webs like Development web.
The disabling of CommentPlugin has made me mostly ignoring Development web and posting emails on the mailing list where I can quicly discuss things.
And as far as I can see topics are still ending up in discussion mode. So nothing has ben won. And a lot of us are dissatisfied about the whole thing.
Please let is enable the plugin again so we can use it where it is smart.
- 13 Mar 2009
My impression was that disabling was just a try to see if it changed user behaviour. We can as well try now with the plugin enabled to see if we are going in the lazy direction again.
- 14 Mar 2009
I would not
like to see the mailing list discussions change - I think that
is one of the positive sides to our move. I don't think enabling CommentPlugin
really has anything to do with that.
I also don't feel that the level of work on foswiki.org is low in a bad way - we're busy doing, rather than busy discussing things to death.
But, I can't say that I'm worried about CommentPlugin
being on/off is a big deal - just like the fact some people are making Talk pages doesn't fuss me much - I seem to be able to adjust my working profile either way, without it pissing me off to the point where it deprives people of the info they crave.
- 14 Mar 2009
Whether or not you encourage the use of CommentPlugin
not having it is driving me nutz. I tried to answer a question in #foswiki the other day and went to show the questioner the answer in Sandbox only to find it wouldn't work because the plugin was off. Very frustrating and a poor example since foswiki ships with it enabled by default. Mix CommentPlugin
templates with FormPlugin
forms and you have some seriously cool wiki application mojo that can't be demoed on foswiki.org because one of the key coponents is off.
- 14 Mar 2009
Part of me says we should lie in the bed we made, and use foswiki.org as a demonstrator for how effective CommentPlugin
can be. Another part of me shudders when I think of the horrendous %COMMENT-based topics that grew up in (tw)wiki.org.
I think a wiki - any wiki - exists in the context of a set of communication tools, and you should use the tool that is appropriate to the job. When I'm working on Foswiki my communications tend to fall into general classifications, and I have subtly different tool kits for each. I've numbered the tools in order of preference for each classification:
- Bug triage and analysis - (1) IRC, (2) the Tasks web on the wiki and (3) email to foswiki-svn
- Non-time-sensitive, but important, notifications of change, warnings - (1) email to foswiki-discuss
- Community discussion, such as the mail asking about status of the association - (1) email to foswiki-discuss, (2) the Community web
- Serious discussion - such as strategy, design, taxonomy - (1) IRC, (2) the Development and Tasks webs on the wiki
- Chit-chat - what do you think of Obama's latest haircut, what's the weather like, how's your sick parrot? - (1) IRC, (2) personal email
I tend to see the wiki as a backup for other means of more immediate communication. It has it's place, but it is not
a substitute for IRC or email.
So, what has this to do with CommentPlugin
? I find that when CommentPlugin
is enabled, it tends to subsume the role of IRC and email for some people. I remember on (tm)wiki.org it tended to attract people who wanted to throw comments over the wall without staying around to defend or explain them. In the examples above, I do not
want %COMMENT enabled for discussions types 3 and 4 - these are serious enough that careful thought needs to go into contributions. That leaves (1) as the only
place I would currently favour %COMMENT - in the Tasks web, where comments on individual tasks are valuable to maintain a history of the analysis and solution of a task.
Kenneth is right, we should enable the plugin, but keep %COMMENT well away from default templates except in Tasks web (I do not
want it enabled on feature requests for the reasons I gave above).
- 14 Mar 2009
Can the plugin be enabled for some webs and not others? I think it is needed for the Sandbox web otherwise people will not be able to show snippets of code and that will seriously undermine the take up of foswiki......other webs I am easy about. Probably should give some thought to the capabilities of the user contributing to each web.
- 14 Mar 2009
The most funny
thing about this discussion is that CommentPlugin
rather, we defined the
setting, which gets evaluated before the plugin - clever huh?
and so, its quite trivial to do precisely that - remove the setting from SitePreferences
and put it in each of the webs that we'd like to keep.
- 14 Mar 2009
Some people are too clever by half.....
- 14 Mar 2009
I can't assess what impact the CommentPlugin really has on our website, but what I can assess is that our wiki gets way less updated as (tm)wiki when we all were there, and also as when we started the fork (but that's kind of normal).
If CommentPlugin will bring back some life to it, and if that life is good, then why not.
But one thing that I like here is that if you want to comment, you can, and while you're commenting, you can also edit some bits and pieces. For example on this very page, if I only want to give my opinion, with the CommentPlugin, I can just type it in the textarea, and be done with it. Here, I will also update the table at the top to reflect the way I think.
So I allowed myself to add a new kind there, the "I can't be bothered" one. Either way will indeed suit me.
And as a few pointed out, we tried to disable that plugin because of what it did to some pages, like the Dev pages. If people, especially new comers, fell more at ease with it, then why not, let's try it. Pretty easy to do anyway. But if we end up doing something, please make a task
- 14 Mar 2009
I think the current balance of new contents on wiki / mailing lists / IRC is quite nice. I understand however the need to clearly say to visitors that yes, the Foswiki engine can do comments. Perhaps a middle ground to avoid reproducing the mess of orphaned discussion spanning litterally generations of members could be to state guidelines for its use:
- have the comment plugin only on designated "Talk" pages (or "Discussion" as this one)
- state that these page must have (at least) a mandatory maintainer (MartinSeibert here?) in charge of
- either refactoring it or summarizing the points in a "Summary" page. For instance, for the old Dev pages for plugins, this could have meant we had aso a Talk page, and the maintainer would have summarized the points in the Dev page. Here it is done at the top, I think it should be in a separate page (maye %INCLUDED) to ease seeing what has cahnged by History and/or notifications
- announce (once) on the mailing list the existence of the discussion, as Martin did. This can amount just in mentioning it on a "newsletter" page that will weekly be mailed to the list or a special newsletter list (Foswikitask:Item278 ?)
- conclude the discussion after some time. A bit like the 14-day rule, we could set a rule that the maintainer would close and summarize (and archive) after a month a Talk page. If interest re-appear let's start a new page with a new maintainer
- 14 Mar 2009
Re: the guidelines proposed by Colas
: they are very useful for specific types of discussions — most notably, proposals — but not necessarily all discussions. I suggest that any guidelines be based on the type of discussion, and not the tools being used to enable the discussion. -- IsaacLin
- 14 Mar 2009
, i am enabling
for the Sandbox and Tasks web, which i believe have universal acceptance for CommentPlugin
availability. (Sandbox is needed for experimentation, and Tasks because too many items aren't signed, and those pages are geared towards sequential annotations.)
eventually, i envision many pages having actual *Discussion ("Talk") pages, with the comment box being on that page (perhaps included from the main page itself, much like the php documentation). but for now, my goal is merely to restore
in the Sandbox and Tasks webs.
- 19 Mar 2009
To me it's all about choice, and encouragement to participate. I like to have the choice
of which way to comment, wherever that is appropriate, and choice is removed if the plugin is not ever available. Removal is a strong blunt technical non-solution to a community interaction preference: it is not the appropriate mode of solution.
There have been times that I added a trivial tech observation, quickly as a comment, and it turned out surprisingly useful. So then I extended it later, when I had time. (I usually have to edit twice, because I forget to sign!) Being in a hurry that day, had I found no comment box, I would not have contributed and the work would have been slightly more difficult to complete. Having not contributed, I would have quickly forgotten that topic (and work) existed.
I do remember hating it when I felt forced or obliged to use that damn box when I'd rather just edit the page. Once I tried to edit but emulate a comment entry... and made an error which exposed my foolish act. But I don't think anyone here is talking about making its use compulsory. If being available means choice of mode of participation for some topics, I'm enthusiastic. Better for people to use any preferred medium than to remain silent, after all, what's a wiki for.
PS, if the comment box had been available here now, I would have used it conservatively and not rambled on so much.
Also let's not fall into the trap of thinking of foswiki.org as a site for developers, rather, let's give the ordinary wiki admins and newcomers everything we can to help make it feel like foswiki.org is built for them, and we are their helpful guests.
- 13 Apr 2009
is first and foremost Convenient. Add a comment quickly and easily in a conventional format witout an edit/save cycle.
I use this plugin for so many things. Want a simple comment? A table? Comments at the bottom of the page? Datestamped? With signature? A special format? Quick and easy. A page without comment format tells me "the author of this page wants you to jump through hoops. S/he is not interested in your comments, not really. Not enough to make it easyy."
"Pros for disabling" claim: "Topic is more presentable, neat, to the point and concise." This is absolutely false (and laughable). In fact, I say the use of CommentPlugin
makes a topic far more presentable, neat, to the point and concise. (So I added that to the cons section too.)
- 09 Jun 2009
I think the Pros and Cons section at the top of this page is confusing. I think some people are reading "Pro CommentPlugin
" instead of "Pro disable".
For example, I moved CommentPlugin is much more than a text field. You can make advanced templates so you can comment and change state of a support question or Tasks item. We are prevented from doing these smart things now.
from the Pros to the Cons. This is a reason for having CommentPlugin available*and a reason *against disabling it. (This is also my personal reason for why CommentPlugin is one of my favorite plugins; it's so much more than "add a few lines of text.".
Item 3 under "Pros for disabling" also looks like it should be under Cons. I'm not so sure about "Make my work as release manager in Tasks web easier." but it's impossible to see how disabling CommentPlugin could make it "Also easier for people to follow up."
Date-stamping my comment myself (soooooo lame :-)
-- VickiBrown - 09 Jun 2009
Actually I considered disabling the CommentPlugin on foswiki.org more of an interesting experiment to see which influence it had on the discussion culture. I can't say that it dramatically changed anything. Fact is that we have discussions going on on topics and that most of them unfold linearly with some rare exceptions where people inline their comments. And if they do they at least add a bottom comment saying "added more inline".
So we did not behave different by magic just because the CommentPlugin was disabled. Instead we created discussion topics with the remaining means, that is by going to full edit and then scroll down the textarea all the way down and start typing. That's why I have to agree with Vicki that infact we lost convenience and that this treatment had nearly zero positive influence on refactoring topics. Which is okay because most discussions simply go on linearly and no refactoring is needed.
Some of the topics have a parallel ...Talk or ...Discussion topics where discussions have been moved "out of the way". While this kept the original proposal free from "noise", things still did not get more convenient, au contraire.
But honestly, CommentPlugin isn't the best thing on earth either. Stuffing a comment into these little textareas is a nuisance.
No question, CommentPlugin allows you to do fancy stuff, a sort of swiss army knife for wiki champions.
Face it, Foswiki lacks a decent comment system for normal users that fosters discussion-like collaboration.
None of the available extensions cuts it, including CommentPlugin.
-- MichaelDaum - 09 Jun 2009
I don't care if CommentPlugin is enabled or disabled. But then I'm an advanced user quite comfortable with wiki syntax. Beginners may feel threatened editing a whole page when they just want to add their 2 cents' (or pennies') worth.
What I do care about is the WYSIWYG editor plug-in. I believe it is incredibly destructive. I personally disable it on any TWikis I happen to get administrative rights to. What people don't realise is that TWiki permits one to add HTML tags to their Wiki syntax. This can be very useful for code examples with CSS to highlight comments, etc. The WYSIWYG editor, however, just eliminates mark-up it doesn't understand. So it takes just one careless person to press "edit" on a page and "save" and a lot of mark-up effort is instantly lost.
-- PeterPayne - 09 Jul 2009
CommentPlugin is one of the most used features in the wiki of my company. I don't want to know what my users would say if I'd disable it, but I can tell you as a user of foswiki.org what I think: Re-enable it! Now!
-- JoachimBlum - 02 Sep 2009
Time has shown that switching off CommentPlugin did not lead to wiki content being refactored more often than without it. As this topic demonstrates as well, discussions still proceed linearly. And this is totally fine because that's most easy to track and contribute to as a human being. It makes no difference if either you click on full-edit to add your 2cent to the bottom of the topic ... or you'd use something like CommentPlugin right away.
The only point against CommentPlugin is that its standard interface is too inefficient from a usability point of view.
-- MichaelDaum - 03 Sep 2009
To sum up the conclusions
- Some would call this a feature ;-), cause adding manual markup to Wiki pages isn't good practice. Advanced wiki application developers can prevent the WYSIWYG editor from destroying their applications by careful design and usage of the appropriate features. Just deactivating the editor, that may help novices, isn't going to improve it, is it? -- FJ ps: I also don't like or use the WYSIWYG editor much, but like the commenting functionality it has its -- appropriateness.
I will action the
- There is a clear majority for having the plugin enabled.
- The original intensions of the disabling has proven to not work. People still threadmode edit.
- There are templates where the COMMENT invites to discuss instead of refactor where we want to encourage refactor. The COMMENT should be removed from these templates.
-- KennethLavrsen - 30 Sep 2009
- Removing from the templates where COMMENT makes more damage than good