Append Only

or read and comment only privileges

Let me start with JimCoplien's note to me (JohnDeBruyn) in OldWikiWikiSandBox? about the read and comment (append only) access proposed for casual users of a modified WikiWiki site:

ThoughtsWeaver also supports AppendOnly pages, ReadOnlyPages??, pages that can be written if a password is provided, and assorted combinations like password-protected append-only pages.

I don't like the way AppendOnly pages work - it's too easy for people to make errors. I would not suggest putting Append Only into WikiWiki as it is implemented in ThoughtsWeaver. I need to find a way so people can see the effects of their changes before committing them permanently. I've thought of clumsy approaches, but am open to suggestions. -- JimCoplien

I agree - full access via EditText is better, much better.

But Append Only lets visitors comment in what would otherwise be a closed environment - an environment that was sealed into glass, read-only cases out of a concern that visitors should not be all be armed with full edit privileges. I noted that WardCunningham's experience was that this was not a problem here at this WikiWikiWeb site of his, which is largely populated by software designers and engineers.

Append Only is a compromise under circumstances where the first-time visitor did not have access. I think that the ability to append to any page would help the regular users of the site - to whom, in my model, full site-wide WikiWiki edit privileges were granted - to grow.

It would be my anticipation that the regular users would edit and integrate the comment into the appropriate page or at a minimum reply to the comment. If the users need to edit their comments, but this means more Perl, the comment could be displayed to the user in processed format with a choice to post or to edit the comment. However, I find working in this little edit window, that WikiWiki provides, as I am now to be far superior to the edit window line editors that I used many years ago and still use out of habit on many BBSs that I occasionally visit now.

In the model that I proposed, every page would be subject to editing by the regular users of the site and only the first-time visitors and casual users (who were not interested in edit privileges) would be limited to making comments. In order to encourage comments from first-time users, I would set up a GuestBook page to introduce themselves by posting a "comment" to describe themselves and their interests and a New User FAQ page where they could post "comments" to ask questions.

My thought is that encouraging interaction and the feeling of acceptance on the first visit (to an otherwise closed site) by a new user that will help build a sense of belonging. I view this as important to the expansion of the regular user base.

I am still struggling with my beginning point in the quest to employ pattern concepts to development of the WikiWiki environment which was how to use a DiscussionGroupInTandem? with WikiWiki. In the model that I propose, the discussion group would be operated in tandem with an adaptation of Wiki Wiki and would - for maximum coverage of the potential audience - be supported by both a listserv mailing list and a Web conference message base, that would be connected by a gateway to each other so that the messages posted would be shared. -- JohnDeBruyn

I've often thought that a Preview button would make Append Only pages work better for me; when I clicked Preview, I would go to a page that showed me how ThoughtsWeaver would display my additions in HTML. By oscillating between Preview and EditText, I could refine my changes until I was satisfied. Then, when I pressed Commit, I could be reasonably confident that my bullets would really be bullets.

You might consider looking at the Salon web site (http://www.salon1999.com), which has an interesting model for collaborative work. They ask for user IDs and passwords. When you add a note to a forum, you (and only you) can edit your note for a period of 24 hours; after that, it's cast in stone. Nice compromise, if you're willing to put up with the requirement for user IDs.

-- BetsyHanesPerry

I like your idea of being able to switch back and forth between the editor and the view of what it looks like.

I took a look at the set up over on the Salon web site. Thanks for the pointer to that site.

There are several levels of security possible and they have chosen to let the reader into the site to read what is there (but not comment) on the basis of leaving the user's registration information. When the email address is confirmed (up to a two hour delay according to their note) as a real email address, the user then gets to make comments.

The confirmation process requires the real user to send a confirmation number back to the server that generated the request for confirmation. This is a method used by some mailing lists that I subscribe to.

My inclination would be to let the new users comment immediately upon leaving the email information. This is the way that many of the mailing list discussion groups have been able to operate without serious problems. -- JohnDeBruyn

P.S. I took the liberty of moving Jim Hebert's note on Apend Only to the next frame. Moving the note was consistent with my thoughts on how comments should be repositioned to fit the organization of the site as it evolves. -- J

Hello hello... guided here by a friend...

Perhaps this is too contrary to entire model of this system, but, with regards to how to correct the problems associated with AppendOnly, why not issue userids and passwords to such a system?

Something tells me that the whole point of this is to avoid such a thing, so perhaps a better option would be a mod only for AppendOnly pages, such as keeping additions to the Sandbox in separate entries for the first N days of their life, and then rolling them into the main text. Meanwhile, the system could build the Sandbox on the fly by concatenating those entries.

Then, issue the submitting user a randomly generated key that would allow them to go back in and correct their mistakes within N days. It could be something as simple as making random the name of the [file/db record] that each entry is stored in, and returning that to the user. Low overhead - the user would simply have to type in the name of the entry she/he wished to edit. Obviously, this capability is 98% present already since the cgi has the ability to fetch/save the entire Sandbox. The cgi already keeps track of the last-mod date, so doing the N day rollovers on the appended comments wouldn't require any new tracking of date stamps.

(I'm wondering if the fact that it's taken me a while to get around to submitting this is going to hose anything, but I'm sure this thing is much smarter than I give it credit for and won't obliterate anything posted in the meantime. Perhaps that's what that diff-looking thing I stumbled into at one point is...)

-- JimHebert?

ThoughtsWeaver doesn't have logins per se, but it uses another mechanism (it's a secret) to distinguish writers from readers. That's what FishBowlMode? is all about. It's a lot like logins.

People without logins can visit and read all pages and can write publicly writable pages. People with "logins" can write all pages that aren't password protected, but they can only append to append-only pages.

Looking at this policy in light of the above discussion puts a whole different bent on this issue for me. I'll have to give it some thought. Keep those ideas comin'...

-- JimCoplien

I didn't get off on the right foot. My thought about Append Only was that the first time users would have Append Only privileges on all of the pages in the site rather than full edit privileges. By Append Only, I was thinking in terms of the limitations of a class of users rather than a class of pages.

Those with edit privileges could edit the comments by combining them, moving them to a more appropriate place and/or integrating them into the main text of a page. So every page in my proposed scheme would be open to editing or appending depending on whether the user had joined the site.

To append comments doesn't differ much from the posting of a message in a discussion group, and there are lots of such groups that I belong to where there has not been a need to screen who may do this. I was even thinking that the posting of a comment could be handled like the posting of a message to such a discussion group. In fact, the comments posted could be both appended to the page and circulated to the members of an email-based discussion group operated in tandem with the Wiki site. A message base on the web would be available so that the members could check on all of the new comments. In the case of a whole new page, it could just be loaded as a comment - and if my entry on the WikiWikiWishList? were granted, it would be circulated as text to the email list participants. I guess the subject line would be the new page name.

In this model, those with edit privileges could be encouraged first to enter their new thoughts as a comment and then in the same sitting move the comment on into the body of the page unless they thought that it worked better as a comment appended at the end of the page. This way, most of the new content would be available by email, in the web-message base and appended or incorporated into the appropriate page.

Many of the on-line participants among lawyers and CPAs to whom the site I envision WikiBridge would be targeted are still back with email only access for various reasons. This way they could participate in the goings on by way of the email-based discussion group. They could by corresponding in the discussion group help develop the information relevant to the site. Those with edit or comment rights could copy such a message from the Web message base over to the appropriate page.

It would not be just the email-only user who would be using the discussion group to participate in the goings on at the Wiki site. Another group of discussion-group users can be found among those who are Web browser enabled but nevertheless still prefer to have new information delivered to their email box as it is published on the Web page rather than having to load up their browser, ride out and round up the information. -- JohnDeBruyn

Early wiki documentation suggested that text written in the first person should be signed and then subjected only to light editing by others, for spelling, grammar and brevity, much like letters to the editor of print publications. The same documentation suggested that third person writing was acceptable or even preferred, and that that writing would belong to the community and could be expected to evolve. In other words, one's signature is wiki's read-only mark. The interpretation of that mark is left to other humans.

Some CPAs, commenting on the WikiBridge site (http://www.c2.com:8000/WelcomeVisitors) have concerns about both inadvertently inappropriate and maliciously editing of another's text. At the CPA side of the site, we have a "project" that incorporates a tandem "Comments" page for each contributed content page. That should help with the inadvertent changes. You might want to vist:

http://www.c2.com:8000/AutomationGuide and select Internet Public Services from the hyper-linked outline.

-- GenePrescott (5/20/97)

Giving people the option of appending a comment rather than opening up the entire page for editing becomes an advantage when introducing concurrency control (collision avoidance) into a wiki clone.

Consider a wiki that provides both edit options. User A begins an edit. User B begins an edit [1]. User A saves. User B attempts to save, but instead is notified of a collision.

If instead user A begins an append edit, followed by user B beginning an append edit, both can complete saves, in either order.

[1] assuming no locking scheme that might prevent B from starting an edit

-- DaveSmith

"AppendOnly encourages thready discussion over document mode. discuss" -- JamesCrook

The option I went with was to divide the page into sections of decreasing levels of restriction. You are allowed to freely edit anything at or below whatever your level is. Material above your level is read only. -- AndyPierce

RenameMe: suggestion AppendOnlyWikiFeature?

CategoryWiki