[Process] Wiki madness

[patrickdlogan]

Let me say this up front... pardon me. Please.

I have to say I cannot fathom how the OSAF Wiki works, and the interface leaves
me discouraged to try harder.

Given the original Wiki's success and simple open software, how does one end up
with such a complex beast (IMHO) as what's at the other end of
wiki.osafoundation.org?

I am not trying to be rude, but this web site is absolutely shocking. It's like
the Ada of Wikis.

Am I just off base? Do people generally find this to be as simple as the
original, or even close?

-Patrick-donning-asbestos-suit

[Kaitlin Duck Sherwood]

Post by patrickdlogan
Given the original Wiki's success and simple open software, how
does one end up with such a complex beast (IMHO) as what's at the
other end of
wiki.osafoundation.org?

Patrick --

Can you be more specific? Is it the technology or the content that
you don't like?

[patrickdlogan]

Post by Kaitlin Duck Sherwood
Can you be more specific? Is it the technology or the content that
you don't like?

It's the look and feel of the Wiki implementation, from the annoying
registration interface (I don't mind registering, but please
distinguish more clearly between registering the first time and
logging in on return) to the overall look and feel (the content is all
boxed up with annoying rows of commands more prominent than the boxed
content).

And the form pages are so much more complex than the original Wiki,
and what/why would I change the parent of some page? Why does a page
even have a parent?

Maybe I'm just a middle age curmudgeon intolerant of change, but this
system has simply lost the ease of Ward Cunningham's original. BTW
the original was intended to be as simple as creating a Hypercard
stack... this Wiki feels more like using VisualStudio rather than
Hypercard.

-Patrick

[Erik Moeller]

Post by patrickdlogan
Let me say this up front... pardon me. Please.
I have to say I cannot fathom how the OSAF Wiki works, and the interface leaves
me discouraged to try harder.

Of course I warned OSAF from the beginning that this would happen:

http://lists.osafoundation.org/pipermail/design/2002-October/000338.html
-> problems with CamelCase syntax
http://lists.osafoundation.org/pipermail/design/2002-October/000381.html
-> problems with TWiki

Had they decided to use Wikipedia, as I recommended, there would be no
such usability problems now. I have just setup another Wikipedia and the
complaint that it is too encyclopedia-centric is not understandable. You
just have to replace all instances of "Wikipedia" with whatever you
want. Now the OSAF wiki already has nightmare-inducing links like
"RepresentUserImprovingMemoryAndImprovingSkills". That this kind of
nonsense is tolerated does not bode well for the usability of future
Chandler products. :-(

Regards,

Erik

[Kaitlin Duck Sherwood]

Post by Erik Moeller
http://lists.osafoundation.org/pipermail/design/2002-October/000338.html
-> problems with CamelCase syntax

Um, this Twiki doesn't mandate CamelCase. You can use the exact same
syntax as wikipedia, e.g.
[[some topic]]
in addition to
SomeTopic

Or, in Wikipedia,
[[some topic|some other way of describing the topic]]
versus this twiki's
[[some topic][some other way of describing the topic]]

[Erik Moeller]

Post by Kaitlin Duck Sherwood

Post by Erik Moeller
http://lists.osafoundation.org/pipermail/design/2002-October/000338.html
-> problems with CamelCase syntax

Um, this Twiki doesn't mandate CamelCase. You can use the exact same
syntax as wikipedia, e.g.
[[some topic]]
in addition to
SomeTopic

Yes, I know that, Kaitlin. The problem is that TWiki generates a
CamelCase page in the background. This makes the creation of UgLy page
titles even more likely, as people create pages like

[[Chandler Wiki Goals and Structure]]

which results in

ChandlerWikiGoalsAndStructure.

On the
http://wiki.osafoundation.org/bin/view/Main/ChandlerWikiGoalsAndStructure
page

you thus get a mix of both styles (CamelCase in the subtitle, free links
in the title). People are likely to use both forms of links, too. This
generates even *more* confusion as users come across both well-formatted
links and long, UgLy link patterns which link to the *same pages*!

Post by Kaitlin Duck Sherwood
From a usability perspective, the transparent creation of CamelCase even

when free links are specified invokes nightmarish images in my mind. I
also find it quite schizophrenic that you are currently wasting a lot of
precious time to show CamelCase links as free links. For example, from
ChandlerDiscussionTopics:

* [[AgentIssues][Agents]]
* [[ContentParsingFrameworkIssues][Content parsing framework]]
* [[EndUserScriptingIssues][End-user scripting]]
* [[InterApplicationsIssues][Inter-application issues]]
* [[InternationalizationIssues][Internationalization]]
* [[MediaHandlerIssues][Media handlers]]
* [[PlatformSpecificIssues][Platform-specific issues]]
* [[PreferencesIssues][Preferences]]

You wouldn't have this uneditable and confusing mess if you had decided
to use free links in the first place. Even the maintainers of some of
the first CamelCase wikis are now expressing support for free links --
but they have no way back, as their wikis are far too large to convert
them. <voice type="sensei">You still have a choice ..</voice>

Regards,

Erik
Anti-CamelCase Crusader #1

[Kaitlin Duck Sherwood]

I also find it quite schizophrenic that you are currently wasting a lot of
precious time to show CamelCase links as free links. For example, from
* [[AgentIssues][Agents]]
* [[ContentParsingFrameworkIssues][Content parsing framework]]
* [[EndUserScriptingIssues][End-user scripting]]
* [[InterApplicationsIssues][Inter-application issues]]
* [[InternationalizationIssues][Internationalization]]
* [[MediaHandlerIssues][Media handlers]]
* [[PlatformSpecificIssues][Platform-specific issues]]
* [[PreferencesIssues][Preferences]]
You wouldn't have this uneditable and confusing mess if you had decided
to use free links in the first place.

Actually, the reason that there is such a difference is because the
Wiki was built by committee, and we changed our minds several times
about what the right name for a page should be. Something is (or
was) broken in the OSAF wiki such that changing the name of the page
wouldn't change the pages that linked to the page.

I've asked Juergen to fix that bug but haven't followed up.

[Mitch Kapor]

To be honest, I wasn't thrilled with any of the many wiki
alternatives. None of them even came close to the kind of collaborative
tool I'd like to see. The great advantage of wikis is that they are easy
to set up and get going with. There were offsetting pluses and minuses to
each of the several variants, not only having to do with features but also
such things as the ability to roll back to an earlier version in case there
was malicious or unintentional damage to a very open system.

What drove the decision to use any twiki was to have something, rather than
nothing, and to have a something that could be improved on as needed. I'll
also say that none of us who have worked on putting up the wiki had prior
experience using it as a tool to promote collaboration, which stands in
contrast to prior experience designing applications software. So we're
going up the learning curve in setting it up.

What would be useful and helpful is feedback on specific problems and
specific suggestions on what you think can be done to improve it and make
it more useable.

Post by patrickdlogan

Post by patrickdlogan
Let me say this up front... pardon me. Please.
I have to say I cannot fathom how the OSAF Wiki works, and the

interface leaves

Post by patrickdlogan
me discouraged to try harder.

http://lists.osafoundation.org/pipermail/design/2002-October/000338.html
-> problems with CamelCase syntax
http://lists.osafoundation.org/pipermail/design/2002-October/000381.html
-> problems with TWiki
Had they decided to use Wikipedia, as I recommended, there would be no
such usability problems now. I have just setup another Wikipedia and the
complaint that it is too encyclopedia-centric is not understandable. You
just have to replace all instances of "Wikipedia" with whatever you
want. Now the OSAF wiki already has nightmare-inducing links like
"RepresentUserImprovingMemoryAndImprovingSkills". That this kind of
nonsense is tolerated does not bode well for the usability of future
Chandler products. :-(
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

[patrickdlogan]

Post by Mitch Kapor
What would be useful and helpful is feedback on specific problems
and specific suggestions on what you think can be done to improve it
and make it more useable.

My main complaints have been described on this list:

* Registration/login is confusing. I agree with Erik that it's even
unnecessary and against the Wiki Way.

* Look and feel is complex. I don't care whether CamelLinks are
necessary, but it's nice to have a simple alternative. OTOH all the
other window dressing in TWiki is just discouraging to see.

In short, Ward Cunningham's original, see

http://www.c2.com/cgi/wiki?WelcomeVisitors,

is in almost every way an improvement on its successors. Simple,
clean, and fluid. All the safeguards are behind the scenes. No frames,
sidebars, rows of commands, etc.

-Patrick

[Andrew Gilmartin]

Post by patrickdlogan
In short, Ward Cunningham's original, see
http://www.c2.com/cgi/wiki?WelcomeVisitors,

"Ask yourself: if the page you cite were to be created, would it serve wiki
well as a point of entry in this web of knowledge?" -- WardCunningham

-- Andrew

--
Andrew Gilmartin
***@ingenta.com
401-743-3713 (cell)
andrewgilmartin (aim)

[Pito Salas]

Post by Mitch Kapor
To be honest, I wasn't thrilled with any of the many wiki
alternatives.

My experience with Wikis is that they are fairly terrible as a collaborative
tool, for the following reasons:

- the formatting is way too weak. You have to learn a strange pidgin html to
do simple things like bold etc. I am not even sure how you'd get an image
(e.g. a screenshot) onto an entry

- it's hard to comment on stuff. Comments become inline modifications of the
original material. When multiple people comment you get a total mess. When
the origninal material is then revised, forget about it!

- when content is created elsewhere (e.g. a graphics or wordprocessing app)
there's no way to "attach" those documents

- The ability to control access, as far as I can tell, is fairly minimal.
Yes you want an open process, but I bet you will want at least a little
control.

- And lastly, and most significantly, it's hard to keep up with changes.
Unread tracking, change notifications, etc are either absent or primitive.

Yes, it has the benefit of being implemented quickly but IMHO it doesn't at
all scale for this kind of project.

I frankly have no idea how much time was spent populating it with the
original content but I wouldn't be surprised if it was substantial...

It's still early. Maybe we should consider a different tool.

FWIW/IMHO

- Pito

[Erik Moeller]

Post by Pito Salas
- the formatting is way too weak. You have to learn a strange pidgin html to
do simple things like bold etc. I am not even sure how you'd get an image
(e.g. a screenshot) onto an entry

Wikis are intended for an audience that is as general as possible. The
use of a very simple syntax has advantages for new users, but it has
disadvantages for those who are familiar with HTML or another formatting
syntax (such as those used by many discussion forums). Even for them,
however, being able to type

[http://www.cnn.com CNN]

instead of

<A HREF="http://www.cnn.com/">CNN</A>

has its advantages, as do the lack of <P></P> tags, the easy internal
linking and so on. Wikipedia supports HTML, too, which is used
especially for tables. In Wikipedia, the image syntax is very similar to
the one used for normal linking:

[[Image:foo.jpg]]

There are currently several efforts to standardize wikitext syntax. The
UseMod syntax is fairly common and also used by the Linux Documentation
Project to prepare documents which are then converted to DocBook/XML.
Wikipedia's syntax is mostly identical to UseMod.

Post by Pito Salas
- it's hard to comment on stuff. Comments become inline modifications of the
original material. When multiple people comment you get a total mess. When
the origninal material is then revised, forget about it!

Usemod-based wikis typically use subpages for discussions. You insert a

[[/Talk]]

link in the page, follow it and put the comments on this subpage. A
backlink to the article is automatically put on the subpage. On
Wikipedia, there are several different namespaces: the article namespace
(no prefix), the image namespace (Image:), the meta namespace
(Wikipedia:) and the discussion namespace (Talk:). Any page
automatically gets an associated Talk: page, so if you wanted to talk
about [[Chandler design]], you would follow the link "Discuss this
page", which would automatically lead to [[Talk:Chandler design]].

Talk pages are cleaned up regularly if they get too long. As the
complete history of a page is stored, you can simply remove previous
comments and insert something like

* Removed all comments: --~~~~

where the ~~~~ will be automatically replaced with your username and
date. Someone who wants to see previous comments can then check the
revision history and view a version preceding that date.

Post by Pito Salas
- when content is created elsewhere (e.g. a graphics or wordprocessing app)
there's no way to "attach" those documents

On Wikipedia, you can upload any type of file and include it either
inline or link to it. There is also a LaTeX backend; a GNU LilyPond and
SVG backend are being planned. This backend-supported content can be
inserted as text and is rendered on demand (also cached).

Post by Pito Salas
- The ability to control access, as far as I can tell, is fairly minimal.
Yes you want an open process, but I bet you will want at least a little
control.

Not necessary. If you ask for access control, you don't understand
wikis. There are a few pages which may need protection against
vandalism, but even here there are alternatives such as FileReplacement:
http://www.wikipedia.org/pipermail/wikipedia-l/2003-January/008537.html

Post by Pito Salas
- And lastly, and most significantly, it's hard to keep up with changes.
Unread tracking, change notifications, etc are either absent or primitive.

Wikipedia has both a simple and advanced "Recent changes" view, as well
as personal watch lists. You can also view only newly created pages,
chronologically sorted. Read/unread tracking is currently only
implemented for user discussion pages where it makes the most sense --
with hundreds of articles added every week, it's simply impossible to
keep up with *all* changes, plus tracking this for thousands of users
would be quite database-heavy.

Post by Pito Salas
Yes, it has the benefit of being implemented quickly but IMHO it doesn't at
all scale for this kind of project.

Wikipedia as a collaborative writing project is far larger than Chandler
ever will be. See
http://www.wikipedia.org/wiki/Wikipedia%3AStatistics

Regards,

Erik

[Andrew Gilmartin]

Post by Erik Moeller

Post by Pito Salas
- it's hard to comment on stuff.

Usemod-based wikis typically use subpages for discussions.

We have tried to use a wiki for discussion and it does not work. Restricting
yourself to commenting only at the bottom of the page or using another page
raises the need for a referencing system (eg "Re paragraph 27"). While you
can create such a system that you have to create one in at all indicates you
are using the wrong system.

A useful addition to a wiki would be a syntax for comments to be displayed
as marginalia. With this it would be much easier for the reader to be able
to choose to read the main text of heavily commented page with only being
peripherally being aware of the comments. For example

We've also left a corner of the Wiki -- | The jungle does
the "Jungle" -- with no structure. You | suggest an US vs
can put anything that you want in the | THEM attitude.
Jungle, regardless of whether it fits | -- AJG
nicely in the structured hierarchy or
not. Ideas that are so visionary that
they are probably not practical should
go in the Jungle. The Jungle can also
be used for ideas that clearly relate
to a Topic, ...

And allow the writer to add comments inline.

[comment The jungle ...] We've also left a corner ...

Since comments on comments should be allowed the common linear flow of the
wiki text formatting syntax does not naturally extend to this need. You need
a new syntax -- which everyone will dislike.

-- Andrew

--
Andrew Gilmartin
US Engineering Team Lead
***@ingenta.com
401-743-3713 (cell)
andrewgilmartin (aim)

[Mitchell Baker]

The marginalia idea sounds very helpful. Does anyone know about the
amount of work that would be involved?

We have no objection to inline comments. We mark certain areas as
"Current OSAF Thinking" and ask people not to edit these areas. As to
other areas, we hope people will find the work style that is most
effective. I would imagine that involves actual editing of documents.

And as to your marginalia comment, we did not intend the Jungle to
reflect or encourage an "us" vs. "them" feeling. I wanted to be sure
there was a place people could use for topics or workstyles that don't
fit well in the Chandler Discussion Topic area. This latter area
reflects OSAF's view of Chandler and how we think we can work
effectively. Some peole may not like the structure, or want a place to
work in a very informal setting. We wanted to be sure to provide a
resource for this.


Mitchell

Post by Andrew Gilmartin

Post by Erik Moeller

Post by Pito Salas
- it's hard to comment on stuff.

Usemod-based wikis typically use subpages for discussions.

We have tried to use a wiki for discussion and it does not work. Restricting
yourself to commenting only at the bottom of the page or using another page
raises the need for a referencing system (eg "Re paragraph 27"). While you
can create such a system that you have to create one in at all indicates you
are using the wrong system.
A useful addition to a wiki would be a syntax for comments to be displayed
as marginalia. With this it would be much easier for the reader to be able
to choose to read the main text of heavily commented page with only being
peripherally being aware of the comments. For example
We've also left a corner of the Wiki -- | The jungle does
the "Jungle" -- with no structure. You | suggest an US vs
can put anything that you want in the | THEM attitude.
Jungle, regardless of whether it fits | -- AJG
nicely in the structured hierarchy or
not. Ideas that are so visionary that
they are probably not practical should
go in the Jungle. The Jungle can also
be used for ideas that clearly relate
to a Topic, ...
And allow the writer to add comments inline.
[comment The jungle ...] We've also left a corner ...
Since comments on comments should be allowed the common linear flow of the
wiki text formatting syntax does not naturally extend to this need. You need
a new syntax -- which everyone will dislike.
-- Andrew
--
Andrew Gilmartin
US Engineering Team Lead
401-743-3713 (cell)
andrewgilmartin (aim)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

[Bill Seitz]

Marginalia is not likely to be easy. Probably the approach would be to
use table tags (not sure how twiki supports those), which would probably
end up broken half the time.

I'd encourage people to make inline comments as bullet sub-paragraphs to
the paragraph they're commenting on, and to make sure their entry ends
with a "signature" (and maybe date).

But, really, I've personally found that most discussion is handled best
by email. If someone has a long meaty idea, then a wiki page is a great
place to stick that, then it can be discussed by email, with the wiki
page changing over time to reflect the discussion. In a sense, each wiki
page/idea gets a single owner (or a small group of people who end up in
agreement) assembling a coherent point of view. But I know other people
don't like this approach. My main reason for this model is because it's
just easier to follow discussions via email (or discussion-oriented web
interface), with wiki providing a snapshot web of coherent thinking (the
problem with most discussion-oriented collaboration media is that the
coherence is never reached).
http://webseitz.fluxent.com/wiki/WikiForCollaborationWare

Post by Mitchell Baker
The marginalia idea sounds very helpful. Does anyone know about the
amount of work that would be involved?
We have no objection to inline comments. We mark certain areas as
"Current OSAF Thinking" and ask people not to edit these areas. As to
other areas, we hope people will find the work style that is most
effective. I would imagine that involves actual editing of documents.
And as to your marginalia comment, we did not intend the Jungle to
reflect or encourage an "us" vs. "them" feeling. I wanted to be sure
there was a place people could use for topics or workstyles that don't
fit well in the Chandler Discussion Topic area. This latter area
reflects OSAF's view of Chandler and how we think we can work
effectively. Some peole may not like the structure, or want a place
to work in a very informal setting. We wanted to be sure to provide a
resource for this.
Mitchell

Post by Andrew Gilmartin

Post by Erik Moeller

Post by Pito Salas
- it's hard to comment on stuff.

Usemod-based wikis typically use subpages for discussions.

We have tried to use a wiki for discussion and it does not work. Restricting
yourself to commenting only at the bottom of the page or using another page
raises the need for a referencing system (eg "Re paragraph 27"). While you
can create such a system that you have to create one in at all indicates you
are using the wrong system.
A useful addition to a wiki would be a syntax for comments to be displayed
as marginalia. With this it would be much easier for the reader to be able
to choose to read the main text of heavily commented page with only being
peripherally being aware of the comments. For example
We've also left a corner of the Wiki -- | The jungle does
the "Jungle" -- with no structure. You | suggest an US vs
can put anything that you want in the | THEM attitude.
Jungle, regardless of whether it fits | -- AJG
nicely in the structured hierarchy or
not. Ideas that are so visionary that
they are probably not practical should
go in the Jungle. The Jungle can also
be used for ideas that clearly relate
to a Topic, ...
And allow the writer to add comments inline.
[comment The jungle ...] We've also left a corner ...
Since comments on comments should be allowed the common linear flow of the
wiki text formatting syntax does not naturally extend to this need. You need
a new syntax -- which everyone will dislike.
-- Andrew
--
Andrew Gilmartin
US Engineering Team Lead
401-743-3713 (cell)
andrewgilmartin (aim)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

[Erik Moeller]

Post by Andrew Gilmartin

Post by Erik Moeller

Post by Pito Salas
- it's hard to comment on stuff.

Usemod-based wikis typically use subpages for discussions.

We have tried to use a wiki for discussion and it does not work. Restricting
yourself to commenting only at the bottom of the page or using another page
raises the need for a referencing system (eg "Re paragraph 27"). While you
can create such a system that you have to create one in at all indicates you
are using the wrong system.

I don't know how you did it, but on Wikipedia and UseMod discussions
work like this:


first post

: reply to post

:: reply to post

---------

another post

: reply to post

: reply to post

:: reply to post

---------

And so on, where the "----"s are translated to horizontal lines and the
":"s to indentations. The end result is very similar to any threaded
discussion forum, but you can refactor discussions in ways that are
impossible in a forum. In my experience, this is often more productive
than mailing lists or forums. Trying to find the right place to insert a
response, however, can be counterintuitive.

There has been some discussion to make wiki talk pages easier to use by
providing links that 1) append a new comment, 2) reply to an existing
comment. (To this end, comments have to be tagged. This is already done
by signing them, so the signature could include the tag.)

Regards,

Erik

[tom_hoffman]

Post by Pito Salas
My experience with Wikis is that they are fairly terrible as a
collaborative
<snip>

Slagging the wiki at this point seems counterproductive. I'm just
happy to have more information available.

OSAF put themselves in a tricky position. Announcing this project has
put them under a big microscope in the community, and I think picking
on every little detail at this point will just make them weary and wary
of engaging the community.

The wiki is adequate. Save your energy for the Chandler.

--Tom

[Mitchell Baker]

Thanks, Tom, you've expressed what we are trying to do. Yes, we know we
don't have a perfect tool. But even so, it has already given OSAF
staff a framework in which to get information out of our heads and on
paper, and seek involvement from those who aren't in the building. And
we hope that it allows a degree of collobative development that would be
harder without any such tool. We're going to work with this for a while.

Mitchell

Post by tom_hoffman

Post by Pito Salas
My experience with Wikis is that they are fairly terrible as a
collaborative
<snip>

Slagging the wiki at this point seems counterproductive. I'm just
happy to have more information available.
OSAF put themselves in a tricky position. Announcing this project has
put them under a big microscope in the community, and I think picking
on every little detail at this point will just make them weary and
wary of engaging the community.
The wiki is adequate. Save your energy for the Chandler.
--Tom
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

[Jim McCusker]

Agreed. Sometimes you have to bite the bullet, make a decision and go with
it. Also, there was a negative comment regarding the wiki being
representative of OSAF's future coding quality. This type of rhetoric is
unnecessary, and hopefully we'll all be able to focus on the task at hand
(designing great features into Chandler). I'm hoping we can avoid getting
into unnecessary online debates and flame-wars, that would really lower the
signal-to-noise of this listsev. There's some great conversations going on
right now and I'd like to see that continue.

--Jim

Post by Mitchell Baker
Thanks, Tom, you've expressed what we are trying to do. Yes, we know we
don't have a perfect tool. But even so, it has already given OSAF staff
a framework in which to get information out of our heads and on paper, and
seek involvement from those who aren't in the building. And we hope that
it allows a degree of collobative development that would be harder without
any such tool. We're going to work with this for a while.
Mitchell

Post by Pito Salas
My experience with Wikis is that they are fairly terrible as a
collaborative
<snip>

Slagging the wiki at this point seems counterproductive. I'm just happy
to have more information available.
OSAF put themselves in a tricky position. Announcing this project has put
them under a big microscope in the community, and I think picking on every
little detail at this point will just make them weary and wary of engaging
the community.
The wiki is adequate. Save your energy for the Chandler.
--Tom
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

_________________________________________________________________
MSN 8: advanced junk mail protection and 2 months FREE*.
http://join.msn.com/?page=features/junkmail

[Erik Moeller]

Post by Jim McCusker
Agreed. Sometimes you have to bite the bullet, make a decision and go with
it.

Why?

Regards,

Erik

[Kent Sandvik]

Post by Pito Salas
It's still early. Maybe we should consider a different tool.

You could take a look at something like the 'slashdot model', there's
actually collaboration happening in the threads... I agree, wikis are
tough for building specs, but very good for building online
documentation, providing someone is always active and cleaning up the
pages. --Kent

[tom_hoffman]

Post by Jim McCusker
Agreed. Sometimes you have to bite the bullet, make a decision and
go with
it.

Why?

One would imagine that it is enough work to create an innovative PIM.
Trying to create the _perfect_ wiki would be a distraction.

Time is a limited resource.

--Tom

[Jim McCusker]

Simply because there are bigger fish to fry. The Wiki is a tool that looks
like it'll be 'good enough' for OSAF's needs. OSAF shouldn't get bogged
down in creating the perfect collaboration tool at the sacrifice of moving
the product development/architecture forward.

I understand the issues about the current OSAF Wiki, but the system seems to
provide a good enough platform to get collaboration going, despite it's
limitations.

My thoughts are that we need to keep our eyes on the goal --> Chandler
Design/Development. The Wiki is just a tool.

Lastly, if this is such a major issue I suspect that someone in the OSAF
community to create their own Wiki (Wikipedia, etc) and get OSAF to provide
a link to it.

--Jim

Post by Erik Moeller

Post by Jim McCusker
Agreed. Sometimes you have to bite the bullet, make a decision and go

with

Post by Jim McCusker
it.

Why?
Regards,
Erik
--
FOKUS - Fraunhofer Insitute for Open Communication Systems
Project BerliOS - http://www.berlios.de
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Process" mailing list
http://lists.osafoundation.org/mailman/listinfo/process

_________________________________________________________________
MSN 8 with e-mail virus protection service: 2 months FREE*
http://join.msn.com/?page=features/virus