Domain: twiki.org
Stories and comments across the archive that link to twiki.org.
Comments · 128
-
Re:Knowledge Base
For me, KB is not really a pure category. More of a hybrid that fits somewhere
between/within a ContentMgmtSys and a DocMgmtSysYou mention mediawiki, which I feel is quite impressive, as a collaborative CMS.
If mediawiki is overly-complex then maybe a different one would work better:
http://twiki.org/
http://www.splitbrain.org/projects/dokuwiki
http://moinmo.in/
http://www.pmwiki.org/OTOH, if yo mean a KB that is concerned about DocMgmt, then you probably know that
many Document Managements Systems, though ofter synonomous with a "Knowledge Base Systems" (KBS), but probably contain better features related to lifecycle management for documents,
publication workflow and access rights management.
http://www.alfresco.com/
http://www.knowledgetree.com/
http://www.epiware.com/
http://www.jaspersoft.com/
http://www.jivesoftware.com/clearspace/
is not free for use, but I've deployed it and can say 1st hand its worth mentioning;
you can download a free 30-day trial for evaluation. -
Response from TWIKI.NET Interim CEO
I wanted to respond to the recent postings regarding TWIKI.NET and the TWiki.org project.
On Monday October 27, we posted a communication regarding a "relaunch" of the TWiki.org community to the TWiki.org website.
Please see: http://www.twiki.org/cgi-bin/view/Codev/RelaunchTWikiOrgProject
The key points in that communication are:
- exposition of a new governance model (an Ubuntu-style model)
- expansion of the charter of the project to encompass open standards around enterprise Web 2.0 collaboration (not just the wiki)
- greater focus on enterprise scaleability and integration standardsI want to clarify a few things to start off:
- We invite participation in the project. We took the actions that we did in order to increase the long run relevance of the project and increase the number of developers and users. We are not naïve; we certainly recognized that it would create some turmoil in the short run and that many key developers would choose to fork.
- Anyone is free to join this project. In this sense, no one has been "locked out". What we have done is ask that anyone who registers and contributes to the site adhere to a new code of conduct which very clearly specifies the new governance model. And it is important to note that the governance model isn't democratic (more on that later).
- Both TWiki.org and TWIKI.NET are fully compliant with the GPL, and furthermore, the
.org is committed to an exclusively open source approach. Under the prior governance model, there were examples of closed source object modules on the site, such as various installers. We didn't think that was right.I also want to provide a bit of background as to how I see the open source wiki and collaboration space today as a precursor to why we went with the Ubuntu-style model and adopted what is admittedly a pretty radical move.
I would characterize all of the open source projects in this space as being relatively small efforts, and all of them appear to be "thinking small" to me. That is to say they are fairly narrowly focused on some aspect of collaboration (e.g., originally TWiki was focused primarily on the wiki), or for some specific purpose (e.g., MediaWiki's primary purpose is to support Wikipedia). There simply isn't any large effort that is focused on setting open standards and providing an end-to-end open source solution for the full range of enterprise collaboration needs.
Is anyone thinking about how to create a framework and set of APIs to make it easy for arbitrary blog engines or social networking engines to attach into an enterprise collaboration framework? Is anyone thinking about how to standardize data about people, so that it can be shared between different collaboration apps? AD/LDAP approaches are all aimed at authentication and access control, not at capturing richer information about people. Is anyone thinking about how to augment the OpenSocial API to make it more relevant for enterprises and allow people to manage their social graphs between their consumer and enterprise lives, and implement clear privacy rules between the two?
The answer to all of these questions is no. I'm pretty sure the only group of people that are thinking about these problems, while using an open source and open standard approach, are the people at TWIKI.NET, some university researchers and a small number corporations that we have had discussions with.
Our vision of what we want to do for open source enterprise collaboration is pretty broad. It's going to require a lot of resource to get there. Some of that resource will be provided by open source developers, but realistically it will most likely require a lot of commercially focused effort as well. Most of the successful open source efforts out there have some closely aligned commercial entity. When I was at Cygnus Solutions from 1996-2000, roughly 80% of the development in gcc/egcs was directly f
-
Re:Wrong logs
--- Log opened Mon Oct 27 17:55:35 2008
17:55 -!- gmc [n=gmc@freenode/sponsor/gmc] has joined #twiki_release
17:55 -!- Irssi: #twiki_release: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
17:55 -!- Irssi: Join to #twiki_release was synced in 0 secs
19:02 -!- CDot1 [n=crawford@crawfordcurrie.plus.com] has joined #twiki_release
19:03 -!- CDot1 changed the topic of #twiki_release to: http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
19:34 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has joined #twiki_release
19:45 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has left #twiki_release []
19:45 -!- EugenMayer [n=EugenMay@dslb-092-074-254-018.pools.arcor-ip.net] has joined #twiki_release
19:45 Hello
19:46 CDot1: are you arround?
19:48 What time is it in London?
19:49 19:42 i guess
19:49 its 20:42 in .nl
19:49 so it starts in 10min?
19:49 think so yes.. but we just had wintertime.. so it might all be a mess.. lets check the world clock
19:49 i believe cdot is having dinner atm btw
19:50 daylight saving just changed here, too. Thats why Im asking. :)
19:51 ah.. ntpd was not running.. it's 8:51 here :)
19:52 7 mins,... gone forever... ;)
19:52 19:51 in london indeed, according to the/a world clock
19:52 -!- TomBarton [n=TomBarto@63.146.69.17] has joined #twiki_release
19:54 Hi Tom
19:55 Hi Marcus
19:55 Hi Tom.
19:55 Hello
19:57 So the meating starts in some minutes or am i wrong?
19:58 you're not wrong, unless i am too
19:58 -!- Lavr_ [n=donotlik@cpe.atm2-0-103309.0x3ef3d076.albnxx13.customer.tele.dk] has joined #twiki_release
19:58 i used the "meating" word again
19:58 -!- SopanShewale [n=chatzill@123.252.224.74] has joined #twiki_release
19:59 :)
19:59 hi andre, crawford, eugen, koen, kenneth, oliver, sopan, sven, tom, markus
19:59 i mean, whats wrong? it sounds the same :)
19:59 Hi Peter
19:59 Hi Peter.
19:59 who is actually at the keyboard?
19:59 Kenneth is
19:59 * gmc Markus is set to "away".
20:00 so as CDot
20:00 i'll be mostly in lurking mode though, i've caught a bug again
20:01 Im busy with some kinosearch issues, too. Please shout, if you want me to comment on something.
20:01 -!- will_t1 [n=wii_t1@63.146.69.17] has joined #twiki_release
20:01 hi will
20:02 who will be facilitating? who will be taking notes?
20:03 proposed agenda items are posted at http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
20:03 # 1. Review Urgent Bugs - for TWiki 4.2.4
20:03 # 2. Feature requests for Georgetown Release
20:03 i would like to start with a new agenda item
20:03 ---++ Relaunch TWiki.org Project
20:04 http://twiki.org/cgi-bin/view/Codev/RelaunchTWikiOrgProject
20:04 please review, i also sent this content to twiki-dev and twiki-announce
20:05 Did you change the default skin?
20:05 yes
20:05 that is one of the changes
20:05 looks a lot better. Not perfect, but years better.
20:06 once arthur's twiki.org specific skin is ready we can change it to his
20:07 -!- MichaelDaum__ [n=micha@dslb-082-083-134-003.pools.arcor-ip.net] has joined #twiki_release
20:07 PeterThoeny_: just to get one point, t.n. is not heading to follow the debian licence model for projects, because there are believes, the trademark can then not be protected by t.n?
20:08 just one question peter, this is it now? either go with t.n or not?
20:08 Are there any news related to the "negotiations" between t.n. and "us"?
20:08 here now; was eating supper, sorry
20:08 Hi CDot.
20:09 hi crawfo -
Re:Wrong logs
--- Log opened Mon Oct 27 17:55:35 2008
17:55 -!- gmc [n=gmc@freenode/sponsor/gmc] has joined #twiki_release
17:55 -!- Irssi: #twiki_release: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
17:55 -!- Irssi: Join to #twiki_release was synced in 0 secs
19:02 -!- CDot1 [n=crawford@crawfordcurrie.plus.com] has joined #twiki_release
19:03 -!- CDot1 changed the topic of #twiki_release to: http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
19:34 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has joined #twiki_release
19:45 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has left #twiki_release []
19:45 -!- EugenMayer [n=EugenMay@dslb-092-074-254-018.pools.arcor-ip.net] has joined #twiki_release
19:45 Hello
19:46 CDot1: are you arround?
19:48 What time is it in London?
19:49 19:42 i guess
19:49 its 20:42 in .nl
19:49 so it starts in 10min?
19:49 think so yes.. but we just had wintertime.. so it might all be a mess.. lets check the world clock
19:49 i believe cdot is having dinner atm btw
19:50 daylight saving just changed here, too. Thats why Im asking. :)
19:51 ah.. ntpd was not running.. it's 8:51 here :)
19:52 7 mins,... gone forever... ;)
19:52 19:51 in london indeed, according to the/a world clock
19:52 -!- TomBarton [n=TomBarto@63.146.69.17] has joined #twiki_release
19:54 Hi Tom
19:55 Hi Marcus
19:55 Hi Tom.
19:55 Hello
19:57 So the meating starts in some minutes or am i wrong?
19:58 you're not wrong, unless i am too
19:58 -!- Lavr_ [n=donotlik@cpe.atm2-0-103309.0x3ef3d076.albnxx13.customer.tele.dk] has joined #twiki_release
19:58 i used the "meating" word again
19:58 -!- SopanShewale [n=chatzill@123.252.224.74] has joined #twiki_release
19:59 :)
19:59 hi andre, crawford, eugen, koen, kenneth, oliver, sopan, sven, tom, markus
19:59 i mean, whats wrong? it sounds the same :)
19:59 Hi Peter
19:59 Hi Peter.
19:59 who is actually at the keyboard?
19:59 Kenneth is
19:59 * gmc Markus is set to "away".
20:00 so as CDot
20:00 i'll be mostly in lurking mode though, i've caught a bug again
20:01 Im busy with some kinosearch issues, too. Please shout, if you want me to comment on something.
20:01 -!- will_t1 [n=wii_t1@63.146.69.17] has joined #twiki_release
20:01 hi will
20:02 who will be facilitating? who will be taking notes?
20:03 proposed agenda items are posted at http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
20:03 # 1. Review Urgent Bugs - for TWiki 4.2.4
20:03 # 2. Feature requests for Georgetown Release
20:03 i would like to start with a new agenda item
20:03 ---++ Relaunch TWiki.org Project
20:04 http://twiki.org/cgi-bin/view/Codev/RelaunchTWikiOrgProject
20:04 please review, i also sent this content to twiki-dev and twiki-announce
20:05 Did you change the default skin?
20:05 yes
20:05 that is one of the changes
20:05 looks a lot better. Not perfect, but years better.
20:06 once arthur's twiki.org specific skin is ready we can change it to his
20:07 -!- MichaelDaum__ [n=micha@dslb-082-083-134-003.pools.arcor-ip.net] has joined #twiki_release
20:07 PeterThoeny_: just to get one point, t.n. is not heading to follow the debian licence model for projects, because there are believes, the trademark can then not be protected by t.n?
20:08 just one question peter, this is it now? either go with t.n or not?
20:08 Are there any news related to the "negotiations" between t.n. and "us"?
20:08 here now; was eating supper, sorry
20:08 Hi CDot.
20:09 hi crawfo -
Re:Wrong logs
--- Log opened Mon Oct 27 17:55:35 2008
17:55 -!- gmc [n=gmc@freenode/sponsor/gmc] has joined #twiki_release
17:55 -!- Irssi: #twiki_release: Total of 7 nicks [0 ops, 0 halfops, 0 voices, 7 normal]
17:55 -!- Irssi: Join to #twiki_release was synced in 0 secs
19:02 -!- CDot1 [n=crawford@crawfordcurrie.plus.com] has joined #twiki_release
19:03 -!- CDot1 changed the topic of #twiki_release to: http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
19:34 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has joined #twiki_release
19:45 -!- FranzJosefGigler [n=chatzill@chello084115142036.6.graz.surfer.at] has left #twiki_release []
19:45 -!- EugenMayer [n=EugenMay@dslb-092-074-254-018.pools.arcor-ip.net] has joined #twiki_release
19:45 Hello
19:46 CDot1: are you arround?
19:48 What time is it in London?
19:49 19:42 i guess
19:49 its 20:42 in .nl
19:49 so it starts in 10min?
19:49 think so yes.. but we just had wintertime.. so it might all be a mess.. lets check the world clock
19:49 i believe cdot is having dinner atm btw
19:50 daylight saving just changed here, too. Thats why Im asking. :)
19:51 ah.. ntpd was not running.. it's 8:51 here :)
19:52 7 mins,... gone forever... ;)
19:52 19:51 in london indeed, according to the/a world clock
19:52 -!- TomBarton [n=TomBarto@63.146.69.17] has joined #twiki_release
19:54 Hi Tom
19:55 Hi Marcus
19:55 Hi Tom.
19:55 Hello
19:57 So the meating starts in some minutes or am i wrong?
19:58 you're not wrong, unless i am too
19:58 -!- Lavr_ [n=donotlik@cpe.atm2-0-103309.0x3ef3d076.albnxx13.customer.tele.dk] has joined #twiki_release
19:58 i used the "meating" word again
19:58 -!- SopanShewale [n=chatzill@123.252.224.74] has joined #twiki_release
19:59 :)
19:59 hi andre, crawford, eugen, koen, kenneth, oliver, sopan, sven, tom, markus
19:59 i mean, whats wrong? it sounds the same :)
19:59 Hi Peter
19:59 Hi Peter.
19:59 who is actually at the keyboard?
19:59 Kenneth is
19:59 * gmc Markus is set to "away".
20:00 so as CDot
20:00 i'll be mostly in lurking mode though, i've caught a bug again
20:01 Im busy with some kinosearch issues, too. Please shout, if you want me to comment on something.
20:01 -!- will_t1 [n=wii_t1@63.146.69.17] has joined #twiki_release
20:01 hi will
20:02 who will be facilitating? who will be taking notes?
20:03 proposed agenda items are posted at http://twiki.org/cgi-bin/view/Codev/GeorgetownReleaseMeeting2008x10x27
20:03 # 1. Review Urgent Bugs - for TWiki 4.2.4
20:03 # 2. Feature requests for Georgetown Release
20:03 i would like to start with a new agenda item
20:03 ---++ Relaunch TWiki.org Project
20:04 http://twiki.org/cgi-bin/view/Codev/RelaunchTWikiOrgProject
20:04 please review, i also sent this content to twiki-dev and twiki-announce
20:05 Did you change the default skin?
20:05 yes
20:05 that is one of the changes
20:05 looks a lot better. Not perfect, but years better.
20:06 once arthur's twiki.org specific skin is ready we can change it to his
20:07 -!- MichaelDaum__ [n=micha@dslb-082-083-134-003.pools.arcor-ip.net] has joined #twiki_release
20:07 PeterThoeny_: just to get one point, t.n. is not heading to follow the debian licence model for projects, because there are believes, the trademark can then not be protected by t.n?
20:08 just one question peter, this is it now? either go with t.n or not?
20:08 Are there any news related to the "negotiations" between t.n. and "us"?
20:08 here now; was eating supper, sorry
20:08 Hi CDot.
20:09 hi crawfo -
Re:Lucene
You might also like to investigate Plucene and KinoSearch which are both Perl ports of the Lucene engine. It's also worth considering combining your search engine with Wikis where possible - then you can find documents by keywords and also navigate to a Wiki page providing context and ralted documents or Wiki pages. TWiki, which is the most popular open source enterprise Wiki engine, has plugins for both these engines, see http://twiki.org/cgi-bin/view/Plugins/SearchEnginePluceneAddOn
-
Solaris
I don't think it's fair to suggest that resistance to Solaris is just a matter of prejudice. It's more a matter of not being able to find the tools you need. Linux folk often try Solaris, but quickly give up on it because the administrative tools they're familiar with aren't there, and they don't feel like starting over from scratch.
You might call that laziness, but it's deeper than that. As an example let me cite my own experience with implementing a TWiki for my group. I was given an old Sun V20z to run it on, which already had Solaris 10 installed. I tried very hard to get the TWiki running under Solaris. The TWiki itself wasn't that hard (and there's a lot of helpful Solaris info on twiki.org) but I was utterly defeated when I tried to install all the various TWiki plugins I needed.
The problem is that TWiki plugins are written in Perl, and mostly require that you install additional Perl modules. Now Perl itself runs very nicely on Solaris, but it's pretty obvious that few Perl module developers bother to test their work on Solaris. That seems to include the CPAN module (which provides a shell that most Perl developers use to download and install new modules), so you end up downloading the modules by hand. Fortunately, Perl modules always have neat little install scripts...
Oops! A lot of install scripts don't work on Solaris either. OK, installation is not rocket science, you just have to make sure the module files are in the include path. Easy enough, though the results are disturbingly messy. Oh well, as long as it work. Just need to Make a few more modules...
Oops! Here's a module that uses a library written in C. And the library has to compile on a particular C compiler. Solaris has that compiler, but the Solaris version doesn't have all the features the library needs to compile! That's where I gave up.
So I wiped the Solaris partition (feeling a bit like a murderer) and installed Fedora 6. Now, I'm not happy about the rough edges I saw (unforgivable in a distro that's been under development for 13 years!) but I can't complain about the sheer simplicity of installing Perl modules and TWiki plugins on that platform. You give the CPAN shell a list of Perl modules you need, give it permission to also download and install dependencies, and sit back. Then you download the TWiki plugins and run their installers -- some of which use the CPAN shell to install the Perl modules you forgot. Simple and easy.
So, until ZFS is available "in the box" for Linux, it's just not an option for a lot of Linux people. That's not prejudice, that's practically. -
Re:alternatively...
Thanks you. All I see is the discussion of "Make them read the bill". That's all fine and good but the original problem I wrote about was the issue of a transparent *modification* system. That is, who made (or at least under which legislator's login-id) that particular change. Who inserted that line that grants Cowtown, WI a 20 million grant to fight terrorism etc? Those are the questions that can be easily answered via a revision control system with public read access (perhaps with a nice web front-end... something like what Twiki provides...)
-
mantis + scmbug
Our group evaluated a handful of workgroup tools: issue tracking, revision control, documentation. Trac was in the list, but it fell short on a number of points after we tried it for a simple project. We wanted SVN integration and liked Mantis, so we hooked in scmbug. It took a little tweaking to setup the 'products' in scmbug to meet our Mantis usage pattern, but it does the trick. Throw on your favorite wiki (mediawiki, twiki, moinmoin, etc.), and you are covered.
-
TWiki too
If you're just looking for a business-grade Wiki, TWiki ( http://www.twiki.org/ ) is another possibility. It doesn't have the source code repository features of Trac, but it has all sorts of business-oriented modules to do all hosts of business things.
Sys Admin Mag ran an article about tweaking its read only performance a few months ago: http://www.samag.com/articles/2006/0604/ -
Access Keys are brokenOne of the key features that I used to promote the use of twiki is now gone.
editing a twiki web page and saving it used to be:[Alt-e] [tab] [tab] type type type [Alt-s]
But in 2.0 'access keys' is now either removed or overridden - either way, I think it's a bad change -
TWiki with plugins
TWiki (http://twiki.org/) has plugins that handle source code formatting (see http://twiki.org/cgi-bin/view/Plugins/SourceHighl
i ghtPlugin and http://twiki.org/cgi-bin/view/Plugins/SyntaxHighli ghtingPluginDev) and others provide blog features (http://twiki.org/cgi-bin/view/Plugins/BlogPlugin looks pretty good). (Some tweaking required for the syntax highlighting plugins to work with latest TWiki version).
TWiki's generally great for intranet collaboration as it has good revision tracking, WYSIWYG editing (beta) and other nice features, as well as over 200 plugins including some that support action tracking, Extreme Programming support, etc. -
TWiki with plugins
TWiki (http://twiki.org/) has plugins that handle source code formatting (see http://twiki.org/cgi-bin/view/Plugins/SourceHighl
i ghtPlugin and http://twiki.org/cgi-bin/view/Plugins/SyntaxHighli ghtingPluginDev) and others provide blog features (http://twiki.org/cgi-bin/view/Plugins/BlogPlugin looks pretty good). (Some tweaking required for the syntax highlighting plugins to work with latest TWiki version).
TWiki's generally great for intranet collaboration as it has good revision tracking, WYSIWYG editing (beta) and other nice features, as well as over 200 plugins including some that support action tracking, Extreme Programming support, etc. -
Re:No, it's pretty easy.
[...] or you can download pre-configured virtual machines [...]
See TwikiVM for the fastest wiki installation, ever.
Configuring it takes a bit longer, if you're into graphics, but if you just want to start adding content it takes about 5 minutes to boot it up and connect to it via a browser and get going.
-
Why not use a wiki?
Saw a lot of posts about software that costs a lot of money, why not get something like twiki.org and pay someone to write a small call center app? All that's really needed to be done is to make a form that a phone operator can easily fill out and have it entered into the wiki.
You get searching for free, and you can point the caller to it so they can see action done. Also they can look up information on the wiki itself.
I'm not sure why it needs to work with LDAP, is there a particular reason? -
Evaluating Wikis using VMware virtual machinesExactly - the TWiki project, which I'm involved in, has created a VM that enables a Windows user to download a complete, working TWiki system to evaluate for use as an enterprise Wiki for group collaboration. This radically simplifies installation for people who used to take many hours to install on Windows (primarily the issue was getting Cygwin, Apache, Perl and RCS installed properly) - the VM is actually a Debian GNU/Linux system but that's pretty much invisible to the person installing the VM. The result is that after a hefty download you can have a working Wiki within 5 to 10 minutes, most of which is waiting for Linux to boot in the VM.
See this page for more information and download links.
-
Use a Wiki!
Heck, I just use a private TWiki. Authenticated, simple, lots of cool plug-ins. Works for Me and my Family.
-
Consider Wikis - works for Yahoo!http://twiki.org/cgi-bin/view/Main/TWikiSuccessSt
o ryOfYahoo
I'm hardly an official Yahoo! source, but I can tell you that we use TWiki internally to manage documentation and project planning for our products. Our development team includes hundreds of people in various locations all over the world, so web collaboration is VERY important to us. TWiki has changed the way we run meetings, plan releases, document our product and generally communicate with each other. We're great fans of your work! Thanks! Eric Baldeschwieler - Director of Software Development...
Yahoo's TWiki is currently over 60+gigs and growing. It works great. Thanks for the great product!
I think the beauty of Wikis is the zero cost publishing and viewing. SVN over WebDav that someone else here came up with sounds like a great idea too, I'd never thought of that. The very light-weight-ness of TWiki (doesn't need to be that particular Wiki implementation) is what makes it successful. You really don't have to think about going from viewing to editing or anything, it's got a trivial UI on seeing revisions that untrained newbies pick up, etc. It's seriously changed our ability to do collaboration. -
Twiki.org
Twiki.org = powerful version controlled wiki, very easy to use. Check out the case studies and customer list!
-
Twiki.org
Twiki.org = powerful version controlled wiki, very easy to use. Check out the case studies and customer list!
-
Re:Collaboration
And, TBH, I'm not aware of any OSS that lets you throw together an intranet with shared documents, task lists, announcements and other dynamic elements as easily as Sharepoint.
Twiki and Mediawiki are easier, and more featureful. They don't have a whole ton of desktop integration, but it's phenominally easy to throw together an intranet with all the stuff you listed (plus a bunch more) using a wiki. -
Re:Not tools, but processI will wholeheartedly agree with the parent post on many points.
Coming from someone who was a ConfigMgmt person for my company, I faced a lot of these issues. First and formost, get a plan, even a simple one, and get it written down. Then modify it as needed. Also, Label every time you build. Any decent source control tool will allow you to do this. Be consistent with your labels, and be clear with them. This way, when a need to build version x.y.z arises, you can get back to it. Trackability is key. Make sure your plan is built around it, because ultimately what you're looking at is being able to build at any time the same x.y.z that you released.
I also must second the phrase "There Is No Quick Fix For Quality". Do it right the first time (even if it takes a lot of time) because you won't need to go back and fix it later. This goes for your end product, but also for your process, as ripping up processes to replace them is tough. THis is not to say that you can't use prototype processes, but when you decide on one, stick with it.
Other tips & tricks:
- the wiki idea posted above is wonderful. I've worked with them for quite a few years now, and in a dev environment, they can be awesome. One caveat: make sure you get a wiki that does revisioning of the pages, one example would be TWiki (http://twiki.org./ This can be a godsend, just like figuring out code changes with CVS.
- I've managed 6 different revision control systems in my career, even being certified as a ClearCase admin. I'd have to say, Subversion is a pretty competent version control tool, and not terribly hard to learn. It's worth the time for the features it offers. As for the others? I'd say stick with subversion or CVS because:- the userbase is larger, therefore easier to find help
- they're more than adequate for most development houses
- they don't cost anything (compared to $3k per seat for ClearCase)
- usually, you can get your data out of them in case disaster strikes (and don't think it won't, cuz it's happened to me more times than i care to think of).
- the userbase is larger, therefore easier to find help
-
Re:MediaWiki
If you are (or someone you know is) moderately familiar with Perl, I would highly recommend http://twiki.org/ over MediaWiki.
TWiki supports standard XHTML 1.0 in combination with traditional wiki-style markup (e.g., *important text* for bold in TWiki as opposed to '''important text''' as bold in MediaWiki).
TWiki runs via standard CGI scripts and uses an RCS back-end for tracking document revisions and facilitating roll-backs.
TWiki was designed to support a thorough plug-in architecture and a great deal of the functionality included in the latest stable release (TWiki-4.0.1 from 07 Feb 2006) is provided through plug-ins.
There are lots of skins too (driven by CSS) which are easy to install if you don't like the default.
I've recently gotten into deploying and administrating installations of both TWiki and MediaWiki. I have also been modifying lots of the code of each while working in Sony's R&D department. Management decided to abandon MediaWiki (and possibly also Confluence shortly) in favor of TWiki's advantages. I'm working on some specialized new plug-ins for our intranet to aid project management. I highly recommend TWiki for collaborative web pages where you might want to extend the functionality.
MediaWiki is simple and clean and very well-suited to encyclopedic content. If that fits your problem-domain (i.e., you don't need to make substantial functional enhancements), it is a nearly ideal choice.
This http://wikimatrix.org/compare/MediaWiki+TWiki site can be extremely helpful in evaluating wiki alternatives too.
I hope that helps. =)
-Pip -
TWiki plugins can do thisThe SyntaxHighlightingPlugin supports over 50 languages.
And they just released a nice shiny version 4.0.0 of TWiki, which I can't wait to try out.
-
TWiki plugins can do thisThe SyntaxHighlightingPlugin supports over 50 languages.
And they just released a nice shiny version 4.0.0 of TWiki, which I can't wait to try out.
-
TWiki plugins can do thisThe SyntaxHighlightingPlugin supports over 50 languages.
And they just released a nice shiny version 4.0.0 of TWiki, which I can't wait to try out.
-
Re:TWiki already uses RCS
TWiki uses RCS as its backend.
TWiki also includes some plug-ins that may be useful for the author of this article, such as the SyntaxHighlightingPlugin (which uses enscript as a back-end).
I am not sure that I would use a wiki for viewing source code because there are better tools for that (from viewcvs to gforge). But if you really want to, then TWiki is probably the one that has the most useful features for a corporate environment.
-
Re:TWiki already uses RCS
TWiki uses RCS as its backend.
TWiki also includes some plug-ins that may be useful for the author of this article, such as the SyntaxHighlightingPlugin (which uses enscript as a back-end).
I am not sure that I would use a wiki for viewing source code because there are better tools for that (from viewcvs to gforge). But if you really want to, then TWiki is probably the one that has the most useful features for a corporate environment.
-
Re:TWiki already uses RCS
TWiki uses RCS as its backend.
TWiki also includes some plug-ins that may be useful for the author of this article, such as the SyntaxHighlightingPlugin (which uses enscript as a back-end).
I am not sure that I would use a wiki for viewing source code because there are better tools for that (from viewcvs to gforge). But if you really want to, then TWiki is probably the one that has the most useful features for a corporate environment.
-
TWiki already uses RCS
Interesting idea to integrate a Wiki with a version-control browser. I wouldn't want to use a Wiki as my editor however.
TWiki uses RCS as its backend. Thus if you use CVS for version control (which is based on RCS), modifying the Perl-based TWiki to talk with your CVS repository should be feasible. -
Re:Yup, exactly what buisness needs
Twiki http://twiki.org/ has a module that lets you edit cells. See Edittable in the list at http://twiki.org/cgi-bin/view/Plugins/PluginPacka
g e. -
Re:Yup, exactly what buisness needs
Twiki http://twiki.org/ has a module that lets you edit cells. See Edittable in the list at http://twiki.org/cgi-bin/view/Plugins/PluginPacka
g e. -
Re:Yup, exactly what buisness needs
TWikiCalc already exists, but could be better. If anyone used it (they don't locally anyway). Someone imagines this can be turned into a business?
-
Re:CVS, anyone?
That's a bit like saying that Bugzilla is built on MySQL, and is really only a thin layer over it, so you might as well just use SQL directly to submit your bugs. For example, TWiki has a huge feature set, and over 100 plugins, including a LaTeX plugin if you want to use it for some content. See http://twiki.org/
-
TWiki got safe with the new releaseTWikis next generation (codename Dakar) release will be out in about 10 days from now and it got really changed in every way. For example it got a brand new security model to prevent such hacks very effectively see http://develop.twiki.org/~develop/cgi-bin/view/TW
i ki/DakarReleaseNotes#Security:
Dakar Release introduces the use of 'safe pipes' to prevent any malicious request from executing code on the server. This strategy stops any of the known attacks dead in its tracks. The Dakar codebase has not been impacted by any of the recent security advisories in any way. Several public sites have been running Dakar code for some months now, and to the best of our knowledge none has been hacked.
Besides that the codebase got an complete overhaul for better maintainance and stability. Installing it is a breeze with the new configure script!
Beta 2 is already out (http://twiki.org/cgi-bin/view/Plugins/TWiki) , is rock solid and best of all SAFE! We decided 2 months ago, that it is stable and so our customers already run TWiki-Dakar with its new security features :-) -
TWiki got safe with the new releaseTWikis next generation (codename Dakar) release will be out in about 10 days from now and it got really changed in every way. For example it got a brand new security model to prevent such hacks very effectively see http://develop.twiki.org/~develop/cgi-bin/view/TW
i ki/DakarReleaseNotes#Security:
Dakar Release introduces the use of 'safe pipes' to prevent any malicious request from executing code on the server. This strategy stops any of the known attacks dead in its tracks. The Dakar codebase has not been impacted by any of the recent security advisories in any way. Several public sites have been running Dakar code for some months now, and to the best of our knowledge none has been hacked.
Besides that the codebase got an complete overhaul for better maintainance and stability. Installing it is a breeze with the new configure script!
Beta 2 is already out (http://twiki.org/cgi-bin/view/Plugins/TWiki) , is rock solid and best of all SAFE! We decided 2 months ago, that it is stable and so our customers already run TWiki-Dakar with its new security features :-) -
Re:We're done with TWiki
I also recently had my TWiki-based wiki farm broken into, for the 3rd time in 4 years, despite trying to stay up to date at least with Debian releases. Fortunately, I had each wiki set up to run suexec as an individual user, so the damage was reasonably well contained.
I'm running the TWiki Debian packages (from Unstable) but follow the security mailing list and fortunately have patched (just) in time (so far). The first of the two recent vulnerabilities brought an attempted attack on my server around 12 hours after getting the initial email warning.
Since TWiki's security problems seem intractable (giant Perl codebase that's very difficult to audit and doesn't seem to have been designed to handle security) I decided that enough is enough and followed freedesktop.org's lead in moving the whole farm to MoinMoin
It's probably not much consolation, but the upcoming Dakar release features a much revised code base with security in mind.
-
Re:We're done with TWiki
I also recently had my TWiki-based wiki farm broken into, for the 3rd time in 4 years, despite trying to stay up to date at least with Debian releases. Fortunately, I had each wiki set up to run suexec as an individual user, so the damage was reasonably well contained.
I'm running the TWiki Debian packages (from Unstable) but follow the security mailing list and fortunately have patched (just) in time (so far). The first of the two recent vulnerabilities brought an attempted attack on my server around 12 hours after getting the initial email warning.
Since TWiki's security problems seem intractable (giant Perl codebase that's very difficult to audit and doesn't seem to have been designed to handle security) I decided that enough is enough and followed freedesktop.org's lead in moving the whole farm to MoinMoin
It's probably not much consolation, but the upcoming Dakar release features a much revised code base with security in mind.
-
Re:We're done with TWiki
I also recently had my TWiki-based wiki farm broken into, for the 3rd time in 4 years, despite trying to stay up to date at least with Debian releases. Fortunately, I had each wiki set up to run suexec as an individual user, so the damage was reasonably well contained.
I'm running the TWiki Debian packages (from Unstable) but follow the security mailing list and fortunately have patched (just) in time (so far). The first of the two recent vulnerabilities brought an attempted attack on my server around 12 hours after getting the initial email warning.
Since TWiki's security problems seem intractable (giant Perl codebase that's very difficult to audit and doesn't seem to have been designed to handle security) I decided that enough is enough and followed freedesktop.org's lead in moving the whole farm to MoinMoin
It's probably not much consolation, but the upcoming Dakar release features a much revised code base with security in mind.
-
Re:We're done with TWiki
I also recently had my TWiki-based wiki farm broken into, for the 3rd time in 4 years, despite trying to stay up to date at least with Debian releases. Fortunately, I had each wiki set up to run suexec as an individual user, so the damage was reasonably well contained.
I'm running the TWiki Debian packages (from Unstable) but follow the security mailing list and fortunately have patched (just) in time (so far). The first of the two recent vulnerabilities brought an attempted attack on my server around 12 hours after getting the initial email warning.
Since TWiki's security problems seem intractable (giant Perl codebase that's very difficult to audit and doesn't seem to have been designed to handle security) I decided that enough is enough and followed freedesktop.org's lead in moving the whole farm to MoinMoin
It's probably not much consolation, but the upcoming Dakar release features a much revised code base with security in mind.
-
It's all about the right security processBesides writing code with security in mind in the first place, it is all about establishing the right security process and acting quickly.
The TWiki community has a well established security alert process, summarised at TWikiSecurity. The security team acted very quickly on the last incident, as documented in the timeline.
Like other web based software, TWiki is safe to use on public sites if site administrators establish the right security process and act quickly on an incident.
-
It's all about the right security processBesides writing code with security in mind in the first place, it is all about establishing the right security process and acting quickly.
The TWiki community has a well established security alert process, summarised at TWikiSecurity. The security team acted very quickly on the last incident, as documented in the timeline.
Like other web based software, TWiki is safe to use on public sites if site administrators establish the right security process and act quickly on an incident.
-
It's all about the right security processBesides writing code with security in mind in the first place, it is all about establishing the right security process and acting quickly.
The TWiki community has a well established security alert process, summarised at TWikiSecurity. The security team acted very quickly on the last incident, as documented in the timeline.
Like other web based software, TWiki is safe to use on public sites if site administrators establish the right security process and act quickly on an incident.
-
Re:Not Mozilla software that was hacked
-
Re:Wow, on the heels of the HP/Netscape news...
Right. Of course.
Because the guys behind Mozilla/Firefox are clearly the same people as those who write TWiki, right? And the guys who run the Firefox marketing site are clearly exactly the same guys who do the hardcore browser development too.
I'm all for pointing out when anyone fucks up, regardless of if they're saintly Firefox developers or "t3h evil 0ne5" at Microsoft. Nevertheless, if we're going to start pointing fingers at anyone and scoring cheap points, can we at least make sure it's, y'know... their fault?
Short-sightedly knee-jerking and implying a marketing-run website crack is in any way a reflection of the security of an entirely separate developer-run product is just as bad as the people you're having a go at that think FL/OSS developers' shit smells of roses. -
We're done with TWiki
I also recently had my TWiki-based wiki farm broken into, for the 3rd time in 4 years, despite trying to stay up to date at least with Debian releases. Fortunately, I had each wiki set up to run suexec as an individual user, so the damage was reasonably well contained.
Since TWiki's security problems seem intractable (giant Perl codebase that's very difficult to audit and doesn't seem to have been designed to handle security) I decided that enough is enough and followed freedesktop.org's lead in moving the whole farm to MoinMoin. MoinMoin is written in Python rather than Perl, and seems to be better thought out in terms of security, although I had to hack up the source some to get what I wanted. Some open source migration tools will be made available shortly.
I wouldn't recommend to anyone that they run a publically-viewable TWiki installation at this point.
-
use a Wiki ?
If you have a unixy laptop, installing a local wiki might be a solution.
There are many different wiki sistems, from very simple, to very very extensive. Im sure yu can find soemthing you like. Take your pick here http://c2.com/cgi/wiki?WikiEngines
Many will have plugins to draw simple diagrams, can attach files etc.
The one I use extensively is TWiki : http://twiki.org/
Both for note taking and group collaboration in my university department. -
TWiki
We ue TWiki, http://twiki.org/ as a center of a international scientific collaboration. We have currently about 70 users, not all equally active.
It has fairly extensive plugin structure, a very nice pdf export functions and extensive access controls. Sometime IM chats logs are just copy-pasted straight in. If you use your wiki words consistently, it all tightly integrates conceptually. The RSS feeds are also very useful. Kind of a delayed chat...
This is especially great since we have people on four continents collaborating, and timezones are widely spread.
We use it mainly to build knowledge and internally peer-review it and co-author scientific papers. You can even use it as a presentation tool, with a browser on full screen.
Dont know if this is what you need but it works like a charm for us. And it is all GPL, and written in perl. -
Listen up Slashdot Owners/Coders!just allowing the submitter to correct their own posts might go a long way toward making the Slashdot audience seem a bit more literate.
This is a brilliant idea. This will allow people to correct their language.
To prevent hit and run comments, people should be able to edit their posts and have the old version saved. The post should be clearly marked as editted, and the older versions available to all. So people could correct spelling mistakes, and not be able to engage in correctionism. There should be a limit, say of 3, corrections, which should keep the volume down.
See http://twiki.org/ for inspiration.
-
Re:Worst logo ever
Really? I guess you haven't seen TWiki's logos: http://twiki.org/cgi-bin/view/TWiki/TWikiLogos