?tron suggests that non-developers should be able to post content to a staging area, to be approved (possibly after editing) by developers. schmonz likes this idea a lot.

what about to make a sub-page called e.g. User contributed documentation an give non-developers rw access there while editing other parts(TNF contributed) of wiki will require developers account or possible some sort of bless from a developer. --haad

From ikiwiki's PoV, this is equivalent to the Discussion-subpage approach (merely a tweak to a PageSpec). From the human PoV, it's a tradeoff. If we make a whole hierarchy world-editable, users will be able to directly edit any page in that hierarchy, but we'll wind up with two pages on every topic of interest and readers will have to check both. A discussion subpage isn't the page itself, but the relation of the two is never ambiguous.

Neither approach is ideal. A possible improvement: in addition to making making Discussion pages world-editable, use the ikiwiki/directive/inline directive on each main topic page to include the relevant Discussion subpage below, with a disclaimer about the provenance of that content. Then both developers and users can effectively edit the page, and the reader can easily discern what's what.

Best if this inlining could be automated somehow, rather than requiring someone to add a directive to each page. --schmonz

I don't understand why we are making user editing so hard, with discussion pages there will be little or no user contribution which is wrong because main point of wiki is to give users power to share information not give this power to developers. Let's make part of wiki editable by users to let them contribute their documentation. If user will want to make his own page about e.g. using NetBSD as xen server how he will done it with discussion pages ?

From other POV I looked at FreeBSD wiki and they have developers only wiki which can be edited by developers and some small number of non developers. --haad

Sorry, I wasn't clear enough. Each page "Foo" will call inline to insert its Discussion subpage into itself. The Discussion subpage will continue to exist separately, but its contents will also be included in the Foo page. The Foo page will then have two sections: one that's only editable by developers, and another that's editable by anyone. Developers will use the "Edit" link as normal. For ease of user editing, we'll want to provide an "Edit" link within the user-editable section of the page which leads directly to editing the corresponding Discussion subpage where that content is stored. Either kind of edit will result in an immediate update of the Foo page.

With this approach, once the relevant ikiwiki bug has been fixed, the opendiscussion plugin should suffice to enable users to edit content in a direct way, while also making clear to readers which content comes from developers and which does not.

Things to think about when the time comes:

• automating the inline, disclaimer, and user-edit link (in wikitemplates?)
• whether anonok is okay or we should require e.g. an OpenID
• treating non-developer edits properly in log_accum messages

--schmonz

For non-developers using anonymous CVS: submit a diff to netbsd-docs@.

For non-developers using a web browser: the ikiwiki discussion subpage and/or comments plugin may point toward the solution.

One of the reasons we chose ikiwiki is the ability to edit via CVS directly, as well as via the web. As long as every wiki editor is a developer, controlling access consistently is simple. In order to open up wiki editing to non-developers, we have to think carefully about both the CVS case and the web case.

In the short term, to start getting non-developers involved, I intend to push wikisrc to anoncvs and hook up wiki commits to www-changes@.

In the long term, ikiwiki has a few ready-made web authentication options (a locally managed user database, OpenID, and HTTP auth), and if they don't suffice for some reason, it's easy enough to write an auth plugin. The hard part is deciding the workflow: where is a sensible place for non-developers to make their edits, and what is a sensible way for developers to review and "bless" the changes? Two ikiwiki-native possibilities are listed above.

Ideas welcome! Edit this page and add your comments. --schmonz

One idea (which needs to be considered by board@):

1. Enable Discussion subpages.
2. Mark very clearly on the Discussion page template that content may have been written by anyone at all and has not been vetted by any member of TNF.
3. Enable the anonok plugin and set the anonok_pagespec to allow anonymous editing of Discussion subpages (and of no other pages).

This doesn't actually work, though. Trying to create or edit a Discussion subpage yields the HTTP auth dialog. And this is equivalent to the opendiscussion plugin. Joey says: "it's a bug, not sure how to fix it right now". --schmonz

The resulting workflow:

1. Non-developer finds a page to which to suggest changes.
2. Non-developer edits its Discussion subpage and writes the suggested changes.
3. Developer who follows RecentChanges (or the commit mails) notices the changes.
4. If the changes aren't acceptable, developer edits the Discussion subpage and explains why not.
5. If the changes are acceptable, developer applies them to the page and removes them from the Discussion subpage.

This can be work flow for a TNF contributed pages but as I said above this is not acceptable for as normal wiki workflow. We had almost similar discussion about comments on a blog software for NetBSD. There were developers who thought that there will be too many comments and we do not have man power to read/approve them all. After setting blog we have found that we have barely 1-2 comments in every third article. I don;t thing that there will be too many real editors on our wiki from non-developers and therefore we need to make it easy not hard to do. --haad

And yet, we already had spam on the blog. I'm not much pro distributing spam, and would strongly suggest some kind of auth that at least brakes spam down a bit. That also speaks against using "any verifying OpenID" (ie users may opt to use OpenID but we still need to put their ID into some sort of list of good IDs). --spz

This sounds reasonable. Getting oneself added to a whitelist isn't too much to ask a prospective contributor. The whitelist can be implemented using plugins/lockedit. --schmonz

spz: How much spam we had there ? Because during our initial talks about blog there were huge expectations about number of spammers and comemnters on our blog for now I don't think that we have more then 30 uniq commenters/spammers that is so low number that we should block user non auth editing because of it. -- haad

Not speaking for spz, but the current holdup is a more general interaction with plugins/httpauth combined with any other type of auth (including plugins/anonok). Once it's fixed, it's about the same amount of work for us to whitelist the OpenIDs of actual human contributors as it is for us to allow fully anonymous editing. So the question becomes, what's best for this wiki that admins feel is reasonably manageable and responsible? Even if the risk of opening ourselves for editing by the whole Internet is small -- and we can't know that -- I'm not comfortable putting TNF at that risk unless there's a very compelling argument for it. --schmonz

There's CAPTCHA work in progress. That might be palatable, when done, as an option in addition to OpenID. --schmonz

After a bunch of work by Joey, we're much closer:

• With httpauth, you can (still) edit any page.
• With an OpenID we've whitelisted, you can edit discussion subpages.
• Otherwise, you can't edit via the web.

What's left:

• Extract the OpenID whitelist to a separate file for ease of maintenance.
• In log_accum, properly parse and display OpenID edits.
• In page.tmpl, inline discussion (if it exists) into its parent page.

--schmonz

---

Whew, this is a long discussion. To recap, every wiki page will have two sections:

1. Content editable by developers only, followed by
2. Content editable by anyone who has told us their OpenID.

This way, every wiki page will be editable (in whole or in part) by everyone, while making the content's provenance clear to the casual reader.

I will implement this by abusing any and all of inline, templates, and/or Discussion subpages.

There were problems combining httpauth (how developers log in) and other authentication methods. The ikiwiki author has fixed these problems.

I have working code to check OpenIDs against a whitelist. We need to streamline the task of "registering" an OpenID as much as possible, so non-developers can get involved with the wiki quickly and easily. We will also want to delegate whitelist management to www@.

The wiki copy of log_accum needs to be taught to parse OpenID edits (and set Reply-To: to the committer, not wiki@NetBSD.org). To avoid skew, we should then carefully merge it back to the main log_accum.

Non-developers will want wikisrc in anoncvs.

In the future, if and when ikiwiki has more fully baked anti-spam measures, it would be nice to be able to allow anonymous editing.

--schmonz

done