advocacy2Add my vote for this tag create new tag
, view all tags

How To Get Internal Buy-In For TWiki

Question: I'm very interested in how people get internal buy-in and encourage wider participation. Since our deployment is in its early stages, I'd like to hear more from people who have actually made it happen and have a sizeable base of contributors.

-- RichardDonkin

For one, I found it helps to take minutes in TWiki while in a manager's meeting, that makes an impression! This helps, especially if it is a conference call. Save the topic once every few minutes.

-- PeterThoeny - 01 Jun 2001

I tend to become one of the people that others come to when they have a question, so I just started to compile lists of information sources (internal and external) and other FAQ's... From that point on, if I had docco'ed it, I would simply reply with, "its on the Wiki", and eventually, other people added, corrected and improved on what was available. Everything snowballed from there. TWiki fills a need that does not seem to be addressed by any other tool - it encourages ego-less collaboration. (OK, the ego is satisfied by being in the Top 10 Contributors list in WebStatistics smile

-- SvenDowideit - 01 Jun 2001

I'm probably in a similar situation - I added quite a lot of content, as and when I needed it (e.g. documenting an internal tool on the TWiki, and then pointing other people to it). However, there is probably a tradeoff between this approach - "get some content in quickly" - and getting people to contribute their own content, although that has started to happen.

Here are a few things I've been thinking about (some are with 20/20 hindsight, and I haven't done them yet!):

  • Writing explicit guidelines on Wiki culture and etiquette would help, covering thread mode and document mode, and how refactoring converts new comments into document mode. Probably some people are put off by making updates to existing pages that are in document mode and look "finished" (even though they never are, almost by definition).

  • Focusing on an application area - do you need a problem/solution base, a FAQ base, better project documentation, a project mini-portal, better inter-departmental communications, or something else? Some experimentation is necessary to understand what TWiki can do, but deciding on such an area and focusing on it would really help.

  • Getting management support is quite key - bottom up initiatives are often less attractive to contributors because of the risk that such things may disappear. But that must be balanced against the fact that TWiki sites may never get off the ground if you ask for permission. Using TWiki as a temporary solution may help - it costs almost nothing to start deploying TWiki in a new area (e.g. to capture FAQ information), and it will fill the gap during procurement of a software tool designed for that function. Temporary solutions often end up being permanent, of course!

  • Getting buy-in from "gatekeeper" departments such as quality management or internal audit - probably best to involve them fairly early on, once you know the application area. If you can agree where TWiki will not be used initially, to avoid conflicts with other tools and processes in early stages, it will give you the scope to experiment.

  • Training (in-person, not just online tutorials) - this helps people to experiment with TWiki and get used to using it. I'm planning a training course quite soon, getting some of the internal gatekeeper depts to review the material up front, and involving managers with the courses to help with legitimacy.

  • Ease of access - for example: a short URL for the TWiki (we use a virtual server in Apache, so you just type twiki in the browser); links to and from other intranet sites; and circulating emails that point people towards the TWiki.

Making the switch to multiple regular contributors is IMO a critical phase for any deployment. We are on the cusp of this, with some users inventing new ways of using TWiki - our engineering dept is doing a mini-portal for one software team that includes links to official docs, build instructions, etc, as well as links into our bug tracking system, and a To-Do and Done list for developers in that team. This has made it much easier for people outside that team to see what is going on, and to induct new hires.

Some useful resources are:

-- RichardDonkin - 02 Jun 2001

It's a little surprising not to see more on this topic. I take it that internal buy-in refers to larger corporations, with IT depts, multi-layered management, all that fun stuff. Out of the blue, I recently started working on a massively scoped "corporate intranet" based on TWiki, but the corp is a good deal smaller - probably smaller than the TWiki plan... But these examples are great, for me as well, especially, of course, the end-user buy-in stuff. And I can't be the only one.

(Mentioned above, TipsForSiteOperators, with all of maybe 100 words worth of tips, is really comprehensive and excellent.)

-- MikeMannix - 05 Jan 2002

My company's about 250 people world-wide, so it's not huge but big enough to need improved knowledge sharing.

I've started doing some one-to-one training about TWiki - this has made me realise that there is a huge cultural gap between web browsing and TWiki editing. Most people, even if they are quite technical and well used to intranets and the Internet, simply don't think in terms of editing and creating web pages, rather than just browsing. Both the people I trained last week were shocked to realise that hitting the Edit link didn't just bring up a test page, it let you edit the 'real' page...

Training is a great way of helping people across this cultural barrier as well as getting them familiar with the basics of TWiki editing. There are quite a few people who registered on TWiki but never got into contributing material, and I'm hopeful that training will help move them forward a bit.

I suspect most people who set up TWiki have a particular mindset that says 'of course websites should be editable', but it's worth remembering that many (perhaps most) other people will not think like this. Giving training is also a good way to find out any usability issues, e.g. where the navigation/searching of the TWiki site needs improvement...

Any ideas on key areas to cover in training would be most useful.

-- RichardDonkin - 06 Jan 2002

I've started a "Brown Bag Lunch" series for my group. We've got about 80 people internal to the group; I'm hoping once these folks get over their various phobias about TWiki, it'll catch on outside the group. The series starts out by going thru the WelcomeGuest pages and how to get around the site as it's currently set up. I let the majority determine what gets covered for the next session, and for more advanced users, I do 1-on-1 training. Each session has a discussion, followed by experimentation in the play area, or on their live web pages. I'll be doing this two days a week, every week, until attendance starts to dwindle.

I've found this is a great way to get feedback on new features or convenience scripts I should implement.

-- PeterNixon - 06 Jan 2002

Having a lunch sounds like a good idea - do you have several PCs available so everyone can have a go at the same time, or is it just the one PC so you can demo things? Any other tips on running this sort of session would be great.

-- RichardDonkin - 07 Jan 2002

Sort of... I'm doing the lunches in a teamroom, which has 8 or 10 Sunray machines. Everyone who wants to play can bring up their session there, while I use the Sunray attached to an overhead projector to do demos or show slides.

-- PeterNixon - 07 Jan 2002

Well, I ran the first 'TWiki Lunch' for 3 people as a beta test. This was during lunchtime since it's hard to get people to take time away from their main work, and took almost two hours altogether. I used a modified set of PeterThoeny's slides (from TWikiPresentations), greatly cut down so that the slides took about 40 mins, including some locally relevant info about our TWiki setup and lots of discussion. Then we did a fairly free-form practical session that took an hour and a bit, which covered page creation, formatting, linking (including local InterWiki setup and customisations), followed by various TWiki features such as Ref-By, attachments, diffs, versions, Index, Changes and Search. Then we finished up by reviewing the main TWiki web that my group uses, including the navigation structure and where to put certain types of pages. All the participants had used TWiki before, occasionally, but found the course was useful as a way of focusing on TWiki use and adoption issues.

So I would definitely encourage people to run short courses on TWiki - because there is such a cultural shift in using Wikis instead of email/newsgroups, there's a big need for a familiar way of communicating this shift (i.e. a course). I made the mistake early on of trying to use TWiki pages, including discussion pages, to try to help this happen, but that's a bootstrap problem - a bit like using email to encourage email adoption back when email was new!

BTW, a comment to the refactorers on this page - 'e.g.' is the accepted abbreviation of 'for example', and 'ex:' is not - by all means use what you prefer, but please don't change my text to use the non-standard one smile
[Richard: e.g. - It was I, refactorer (you did check?!). Started NonInvasiveEditing as related, if you'd like to check! - MM]

-- RichardDonkin - 12 Jan 2002

What DO "most people" think of Wiki-style communication? Since Wikis are quite "underground", most of my Wiki-related reading's been on...Wiki sites (mainly c2, some Meatball, and here), along with the occasional article or review. IOW, I've been exlusively amongst the converted, but somehow didn't realize that until reading a certain post above. Dunno why. Personally, I instantly found T/Wiki natural and...inevitable, like the proper extension of HTTP. And I still believe it could add a whole new direction and era to Web dev, changing widespread impressions that haven't fully settled in (at least, I hope not), but are so far kind of negative and mostly based on mainstream media misrepresentations. Individuals, the owner/operators of millions of smaller, computer-challenged businesses, no doubt even a fair contingent of "minds" in least a few mega-corp/MNCs, who see thousands quietly tyrannized by arbitrary internal info systems - they're all buying in to this kind of browned out, post-DotCom/tech stock crash view of the Web/Net, which is understandle and ridiculous. Meanwhile ther are STILL no real killer sites - in any mood, I can thing of a TV show, movies, books, even consumer mags in any mood, with more anticipation than any comparable Web destinations (I left our newspapers). And no better for a "community". So the Web's there, no one's really figured out how to USE it yet as a one-to-many mass medium (with one-to-one just built in)...and there's T/Wiki... Pretty wild...and far from corporate collab...but there it is!

Then I read RichardDonkin's comments above, with phrases like and the "*huge* cultural gap between web browsing and TWiki editing", "people who set up TWiki have a particular mindset that says 'of course websites should be editable'", and "many (perhaps most) other people will not think like this" (all sounding more negative out of context than in - good thing we're not being constantly comhed for media quotes ;> ). Which led to my first question. It's as much on topic here as the the usual buy-in need easy install to get by IT and QA, or getting a superior to visibly buy-in, or sponsor training sessions, but different. This buy-in quesion, restated, is: *Does TWiki have a actually have limited user base, period?"

Does anyone have specifics: a superior who just hated it from first glance, and almost surely quashed it on that basis? A group where some people just...rejected it, beyond a logical understanding issue?

(I remember using the decidedly "consumer" FileMaker Pro for years, after learning some version of 4th Dimension(?), Fox Pro, and also MS Access (or whatever it was back then if that wasn't FoxP). But FM was "Mac-like", not even OBDC-compatible till the last couple years. So what. It was SUPERSIMPLE, from v2 flatfile, to v3 & 4, fully relational. I could tell someone who'd barely booted a computer, on the phone, in 10 minutes, how to set up a new contact database to enter a bunch of stuff. Let alone, not have to think much myself. Then, a couple years ago, in a quite large, fast-moving, well-funded online dev environment, the MS infrastructure with a centralized production supertool, was breaking down all over. Finally, I rebought FMP4, and created all kinds of things, auto time-calc standard TV cue sheets, printable in multiple reqired formats for different studio positions; a location shoot expense bkkeping system that the accounting dept loved - simply used their line item codes - we used our descriptive ones, so took no time to enter; a stupidly simple tape logging system with autogenserial numbers, tied to very sticky stickers to number tape and case - we could find tape contents by sevearl fields, and pull the tape, while a dedicated 10 person archive department with a dedicated programmer were LOST. And all of that took one all-nighter! Other divisions, fed up with the central intranet tools, got FM and my templates, and were up and running in 30 minutes. Finally, the CTO, the VP Streaming and a couple others, put practicality ahead of pride and formally asked to check out FMP. But just some of the odd ways it does things - like, to redefine a saved Find (Query...), actually perform the new action, then going into Find edit and simply click change instead of leave beside the find field :)- I love that, the reaction it gets - no list, config file, command line alternative way to edit, it freaked them, they couldn't accept it. Why? I don't think they could've verbalized it for months. But before that JUST FROM A MINDSET BASED REJECTION - I could see it, feel it, no ego, just habit they couldn't get past - they went back to their lumbering central production tool, it never fully worked, most channels were off sked, hitting studios without proper cue sheets for half a dozen different positions , production fell behind, marketing and sales followed, it greatly contributing to the inevitable company meltdown....)

Sorry for the long story. But the situation seems kinda familiar. It's interesting, the habits that some people would rather lose with than change. And how you can sometimes change 'em. Maybe discussing "negative" cases head on would actually be good! Unlike FMP, where better people and org could've created way superior networked db tools than my last minute fix, here, the world may be ready for a change, with nothing in the wings (broadband? what's that? what else?)... It sounds...large? Maybe... But it is a mad world, and there are A LOT of people wanting a beter way to connect.

-- MikeMannix - 20 Jan 2002

I'm an optimist, so I don't think TWiki has an inherently limited user base, any more than Linux has - just as Linux has moved into technical workstations and desktops through GUI development, so can TWiki move into the 'end user' arena by becoming more user friendly, including WYSIWYG editing.

I do think that applications sell TWiki - if somebody finds a 'killer app' for TWiki in a particular organisation, that can really move it forward (obvious but true) - if there is no real reason to use TWiki it's hard to get it started. And contributing is very different from browsing, hence the cultural gap. It's definitely a good idea to address these cultural issues up front in a presentation to try to get people to think around them and maybe bypass them.

-- RichardDonkin - 21 Jan 2002

Just gave a one-on-one course to our manager of training services, who is a heavy browser of our TWiki site but an infrequent contributor. He said that the absolute number one reason for not contributing was ... ForgettingPasswords! People who have contributed just a few times frequently ask me to reset their passwords, and I'm sure this is a common problem in general. See ForgettingPasswords for some ideas.

One interesting application he came up with, sparked by discussion of WebForms, was to create a page listing courses scheduled and the number of remaining places - currently this information can't be directly updated by our training administrator, and there's no IT application to handle this. This could well turn into a full form-based application, but the key point is being able to get the page up in literally two minutes and then evolve it from there.

I've also been experimenting with the WikiRssExtension (which publishes WebChanges to third party sites/tools) and a desktop-based RSS tool called FeedReader - see MozillaSidebar#Why_does_this_matter_ for some ideas on this. It could really help by alerting people on their desktop when there are new or updated TWiki pages.

The other big thing that really needs improving is the TWiki search engine - I implemented AND searching already, but the basic search engine returns too many hits with 250 topics in one web. (See SearchEngineVsGrepSearch for a quick solution using an OpenSource grep-replacement called bool - this enables Google-like proximity searching on TWiki with no coding!)

One other plan of mine is to implement the PopupPageIndexForEditing to make it easier to create links - this would have caused severe BackFromPreviewLosesText problems with IE5 but that's now fixed (at least on our intranet site).

Perhaps others could mention their applications of TWiki, particularly web forms type stuff as I think this could be a real benefit in my company... I've heard about bug tracking and action tracking, but it would be great to have a discussion on TWikiApplication.

-- RichardDonkin - 09 Feb 2002

Yes, bug tracking... I started from bug tracking. I was looking for a simple bug-tracking tool, and found link saying somebody implemented bug tracking in wiki. I liked the wiki concept, looked at usemod wiki, and found TWiki - and rest is history.

Our bug tracking is mostly ready but not deployed yet in production. If somebody is interested, I can attach it somewhere. If you want BugTrackingInTWiki topic, create it, and I'll post it there. It might save you some time to start from our app, I guess.

Another application we have for Twiki is storing text of help pages for our (web-based database) application. We just added on each screen links pointing to TWiki Help web. It's pain to write help, of course, but we hope TWiki will help us to distribute workload. Also, we installed excellent CommentPlugin allowing users to ask questions (without authorisation) right on help page. Then authorised expert can Edit topic and answer questions, and link pages together and with development documentation, if appropriate. we hope that ability to ask question in simple way will allow us to improve and clarify help pages in time. Help also required extremely simple default skin.

-- PeterMasiar - 10 Feb 2002

We already have a reasonable bug tracking system, so that's not an immediate application, I was just trawling for interesting TWikiApplication. I would like to do a 'structured FAQ database' a bit like the Know web, and would like to hear of people who've done this successfully (did a bit already, see CategorySearchForm).

I like your help authoring application - sounds like a great way to divide up the work. Commenting directly on the help pages sounds good too - the online PHP man pages let people add comments in as well, see http://www.php.net/manual/en/getting-started.php for how this works.

Do you think it's easier to get people contributing in general with quick comments via CommentPlugin, vs. a normal Edit of the page?

On another note, I've posted the course outline and slides that I have used, at TWikiCourseOutlineExample2 and TWikiPresentations - any comments would be useful!

-- RichardDonkin - 11 Feb 2002

I'd like to jump into this discussion and offer the perspective of a total TWiki newbie. This discussion cuts to the heart of some of my ambivalence about TWiki, but inside of my immense initial excitement about this platform. To offer some perspective, I'm considering using TWiki to create a collaborative environment for low-income farmers. Absurd? I don't think so. I beleive TWiki COULD evolve into a very powerful AND accessible collaborative tool. I'm even optimistic (or perhaps naive) enough to think it could be an easier task then it might at first appear.

I'm glad MikeMannix mentioned Filemaker because his point about that program represents for me an ideal for a certain usability pattern of software. The way I express this is that the software offers a very low initial usability threshold and then offers clear, progressive steps to accessing more and more powerful features. Part of what's important in making this work is having the "power features" essentially hidden to the novice so that these do not distract from or get in the way of meeting simple initial needs. Then when the user realizes they need a more powerful feature, they can find it with a little digging. I personally was drawn into using Filemaker as well as Hypercard in just that way. I still prefer to use Filemaker over any other db because, as an occasional db designer, I like the very simple interface to create a simple db solution. Then, periodically, I get drawn into a more complicated application and delve into the manuals and such. But I HATE applications like Access that make me delve into the manual to do the simplest modifications of a db.

I'd also like to pick up on RichardDonkin comment regarding applications selling TWiki. I totally agree and I think that this might be easier then it first appears. From my initial look around, it looks like the TWiki community already has most of the PIECES to create several elequent "killer apps" for collaboration. Using a combination of Skins, Twiki forms, templates, some sort of minimalist WYSIWYG editing capability, plus very simple sequencing conventions (ways to lead folks through steps) - I think we could create kick-ass virtual applications. Like I say, it looks like all the pieces are there - its a matter of putting them together with a focus on front-end usability and polish. Then I would suggest hiding the back-end guts (under the skin and templates i suppose) until someone needs to see them.

I would propose starting out with the vary basics - creating what amounts to a threaded discussion application. Another very exciting opportunity (at least for my needs) would be a knowledge management system using a pattern language approach. Another piece would be a simple project management set. It seems like each of these could be implemented through sets of skins, forms and templates. Then someone could essential roll their own application set and add on to it as their needs evolve or expand. Am I totally off-base or naive with this concept?

Please forgive me if I've gone on too long and am not appropriately "up to speed" with the present topic. I'd also welcome someone pointing me a more appropriate place to float these ideas if I'm off-topic here. I do feel a bit like a opinionated neophite stumbling into the private deliberations of a group of initiates. But, hey - isn't that part of the risk and potential of the basic design of Wiki?

-- SkyLoom - 22 Feb 2002

Extensive example of TWiki deployment, with arguments in favor and against TWiki from "unintiated" users and management, was posted by TWikiGuest jcline(at)ieee.org at ArgumentsAgainstTWikiOnIntranet.

-- PeterMasiar - 17 Apr 2002

And to make the point how TWiki may contribute to the bottom line, here is PriceTag of some proprietary competitors.

-- PeterMasiar - 06 May 2002

I changed twiki.tmpl to look exactly like our corporate web page standard. Sounds like a trivial thing, but gets you lot of milage. No need to justify why your pages look differently... Another thing that eases entry is to unwikify the Wiki words, using SpacedWikiWordPlugin...

-- ThomasWeigert - 06 May 2002

Revision control for attachements was a key feature for acceptance, I believe. More visiual creation of tables is also a feature that will endear users (I like SimpleTableEntryUsingForms as a starting point).

-- ThomasWeigert - 06 May 2002

I'm just starting to get into the details of TWiki, I was told to write a project management tool for work, (our native office language is perl)so I decided to do some freshmeat research.

I'm very very impressed by what I see so far, my superiors have been likewise pleased with what I've been able to show them. I think the best way of presenting it to them thus far has been to get them to thinkof it less like a "web page", and more like an application that happens to run in the browser window. Realistically, it doesn't really behave like a web page, except when you're reading a list of comments.

It might help that I work for an (at least nominally) computer savvy (web hosting) company. We hire people who are comfortable with compuers, exclusively. (Even the person who answers phones knows how to install software.) Web is a nice way to get (relatively) seamless interaction between diverse operating platforms. The paradigm shift isn't that great, as long as you don't think of it as just a web page. Then again, we have a lot of web apps in house.

And the idea of changing the template to match the corporate stuff, that'll go over very well with the design people. (I haven't dug around in the code, yet, and I suppose I'll know as soon as I do, but does TWiki use HTML::Template, or some other templating package?)

-- OchressandroRettinger - 18 Jun 2002

Interesting comments about being in a web-savvy environment - this is quite unusual, IMO most companies have people who are familiar with Word and Excel, and are happiest with something that works in a similar way (i.e. WYSIWYG, toolbars).

TWiki does not use an external templating package, in order to reduce the number of modules that need installing - it has a simple templating system that can be used quite easily to do new looks and feels. See the *.tmpl files and consider using one of the skins in the Plugins web as a starting point.

-- RichardDonkin - 19 Jun 2002

I'm running a Twiki for a very small group (3 intended users in the private webs; and some publicly editable pages as well), and have had some feedback from users.

  • Implicit Signatures: One user says that the presence of a signature, which appears on every new Wiki page, is daunting. Even though he knows the intent is for him to edit whatever he wants to, it seems to him too much as if he is editing someone else's text, and thereby putting words into someone else's mouth. He thinks this barrier would be absent if wiki pages were unsigned by default. The change history can be used to provide proper attribution.

  • Beginner Finds Login Onerous: Another potential user of one of the public webs was completely stymied by the login process. Can't there be some way of not bothering people who want to edit anonymously with login requests, but allowing them to explicitly request a login it they want to be identified? Of course it they want access to a restricted web, theuy must properly identify themselves. But a default treatment as if they were logged in as Guest, and an explicit mechanism by which they can request not to be anonymous, could be useful.

  • And some have found it initially confusing that the button to use to save and edit is called "Preview Changes".

-- HendrikBoom - 19 Jun 2002

How to edit anonymously: In .htaccess file, you can put guest username and password for anybody to see. (Please note AuthName is a string in quotes.):

AuthName 'TWiki UserName/Password (anon: TWikiGuest/guest)'
Then you can train users to enter password from the screen, and maybe sign in message.

-- PeterMasiar - 20 Jun 2002

Good article about TWiki that refers to this page, by MeganGolding.

-- RichardDonkin - 23 Nov 2002

When you are looking for material to bolster the position that wikis can be better for intranet applications than the high priced content/knowledge management systems make sure you read this short essay at peterme.com: 2, 4, 6, 8, Let's All Collaborate.

My favourite phrases:

  • Anyone who has worked with others knows that the best collaborative tools are the simplest.

  • John Parkinson, from Cap Gemini Ernst and Young, said that after helping spend $1 billion in collaborative software, and developing instruments to study its impact, there was only one tool that had a noticeably positive effect on collaborative productivity: e-mail.

  • ...made abundantly clear is that the solution to enable collaboration is not really a technical one (much beyond the simple tools). It's a management one.
    • this point is extremely relevant to us as it points directly to a weakness inherent in the wiki model. The people who run the wiki must provide structure and work flow ("governance architecture" in the parlance of the essay) else it turns into big chaotic morass of related-but-not-necessarily-relevant documents.

  • "people do dumb things with smart objects, and smart things with dumb ones."

-- MattWilkie - 08 Jan 2003

I just have to pick up on one of those points, Matt; you suggest that the people who run the wiki write the structure and work flow. The problem is that, for our wikis at least, they are far too big and used in far too many different ways for such dictated structures and work flow to be applicable to everyone. Having those flows in place also totally weakens the argument for using TWiki; people look and just say "but Compass does that".

We have used wiki such that interested groups effectively subscribe (get a web) in the wiki, and are then allowed free reign for how they use them. Usually the person who requested the web will be the initiator of some sort of structure, but these structures are often demolished and rebuilt several times by different contributors. Webs usually have a lifecycle, which pulses through discussion - revision - casting. One of the main strengths of TWiki is that unlike other intranet tools it doesn't dictate the structure; it allows you to evolve your own.

On another point, you and others mention e-mail above. Wiki doesn't replace e-mail, but it is a tremendously powerful adjunct to it. Consider automatically creating a mail-list for every web created, auto-populating it from the WebNotify, and putting the wiki address on every mail sent to/from the list. Even better if you write a plugin to access the list archive from a wiki page (no I haven't; I only just thought of this).

People will soon connect e-mail with the wiki.

-- CrawfordCurrie - 09 Jan 2003

"Matt; you suggest that the people who run the wiki write the structure and work flow."

ermmm, that's not quite what I meant. I was thinking more along the lines of: the way the wiki is set up initially is going to influence how latecomers use the wiki. For example: nearly every discussion here on twiki.org is held in ThreadMode. Relative to the total content being produced, very little refactoring occurs. Contrast this with the original wiki where topics are much more likely to be refactored and unsigned submissions are more common. Nothing about twiki's code says it can't run the other way, it just doesn't because the people who use this site use thread mode.

A second example is guidance: Here on twiki.org there are notes in various places which say "Please direct xxxx questions in the Support web". The people who "run" this site follow up by gently moving stray questions to Support when they eventually occur, which they always do. There are other online communities where any deviation from the code of conduct is flamed mercilessly. Again there is nothing in the twiki code which stops this from happening on twiki.org.

As for an email <> twiki connection, Yes Please! (I'm aware of MailInAddOn I just haven't been able to make the time to get it working yet).

-- MattWilkie - 09 Jan 2003

Once I finish JavaPasteAddOn I might get a couple of days to get MailInAddOn a bit more usable. MailInAddOn relies on a horrible hack provide authentication to TWiki.pm without the presence of the CGI environment, so its somewhat yucky.

It does work though, I have it running on a server.

I won't have time to continue maintaining MailInAddOn though as I am about to start a Fulltime Uni course, so if there are any offers to make it real, I'll gladly pass over control of it. I'll get it into the Plugins CVS repository (I can't remember the repository topic name) within the week.

(I didn't write MailInAddOn, I had a member of staff at my last company do so).

-- MartinCleaver - 09 Jan 2003

Powerful arguments here. The cultural side of implementation can not be underestimated. We are lucky to be in a place where the technology is suitably advanced that the tough "people issues" now come into focus. However this presents new and less clearly defined issues compared to "error messages" and reproducable code problems.

-- GrantBow - 09 Jan 2003

Perhaps now that the core code feature set is pretty good, the bulk of development work needs to be focused in other areas. Documentation, plugins, skins, add-ons and additional core APIs can help tie TWiki into other corporate legacy systems.

-- GrantBow - 21 Jan 2003

The American National Public Radio service broadcast a commentary on wiki's a couple of days ago. It is a nice short 3 minute introduction with just the right balance of intrigue (what do you mean a completely open system doesn't degenerate into chaos?). No wiki engine is named but they do mention Motorola who we know use twiki, and talk about http://wikipedia.org/

I plan to send the piece about in advance of any what-is-a-wiki meetings/demos.

-- MattWilkie - 23 Jul 2003

I've introduced TWiki into three different organizations over the last two years. The success factors seemed to center around

  • Creating a skin with reasonable links to related content - javadoc, viewcvs, etc.
  • Having a nice looking skin helps a lot. In the latest organization, I'm using HobbesSkinDev version of the tiger skin
  • Creating an initial "content organization metaphor" matters tremendously. The first group was not using TWiki until I added code that implemented LogicallyNestedWebs. For the latest organization, I'm using TreePlugin

-- StanleyKnutson - 02 Aug 2003

Discussion comparing twiki with confluence moved to TWikiVsConfluence.

See also ConvincingYourBoss for information on how to get buy in from management (which is a separate issue from getting buy in from the end-users). -- AmandaSmith - 05 Jan 2006

Edit | Attach | Watch | Print version | History: r48 < r47 < r46 < r45 < r44 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r48 - 2006-02-05 - PeterThoeny
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2015 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.