Annotation of wikisrc/wiki/todo/let_non-developers_contribute_content.mdwn, revision 1.35

1.9       schmonz     1: [[tron]] suggests that non-developers should be able to post content
                      2: to a staging area, to be approved (possibly after editing) by
                      3: developers. [[schmonz]] likes this idea a lot.
                      5: > what about to make a sub-page called e.g. User contributed
                      6: > documentation an give non-developers rw access there while editing
                      7: > other parts(TNF contributed) of wiki will require developers account
                      8: > or possible some sort of bless from a developer. --[[haad]]
1.10      schmonz    10: >> From ikiwiki's PoV, this is equivalent to the Discussion-subpage
                     11: >> approach (merely a tweak to a PageSpec). From the human PoV, it's
                     12: >> a tradeoff. If we make a whole hierarchy world-editable, users will
                     13: >> be able to directly edit any page in that hierarchy, but we'll wind
                     14: >> up with two pages on every topic of interest and readers will have
                     15: >> to check both. A discussion subpage isn't the page itself, but the
                     16: >> relation of the two is never ambiguous.
                     17: >>
                     18: >> Neither approach is ideal. A possible improvement: in addition
1.11      schmonz    19: >> to making making Discussion pages world-editable, use the
                     20: >> [[!iki ikiwiki/directive/inline]] directive on each main topic page to
1.10      schmonz    21: >> include the relevant Discussion subpage below, with a disclaimer
                     22: >> about the provenance of that content. Then both developers and users
                     23: >> can effectively edit the page, and the reader can easily discern
                     24: >> what's what.
                     25: >>
                     26: >> Best if this inlining could be automated somehow, rather than
                     27: >> requiring someone to add a directive to each page. --[[schmonz]]
1.17      schmonz    29: >>> I don't understand why we are making user editing so hard, with
1.22      wiz        30: >>> discussion pages there will be little or no user contribution which
1.17      schmonz    31: >>> is wrong because main point of wiki is to give users power to share
1.22      wiz        32: >>> information not give this power to developers. Let's make part of
1.17      schmonz    33: >>> wiki editable by users to let them contribute their documentation.
1.22      wiz        34: >>> If user will want to make his own page about e.g. using NetBSD as
1.17      schmonz    35: >>> xen server how he will done it with discussion pages ?
1.15      wiki       36: >>>
1.17      schmonz    37: >>> From other POV I looked at FreeBSD wiki and they have developers
                     38: >>> only wiki which can be edited by developers and some small number
                     39: >>> of non developers. --[[haad]]
1.15      wiki       40: 
1.18      wiki       41: >>>> Sorry, I wasn't clear enough. Each page "Foo" will call `inline` to
                     42: >>>> insert its Discussion subpage into itself. The Discussion subpage will
                     43: >>>> continue to exist separately, but its contents will also be included
                     44: >>>> in the Foo page. The Foo page will then have two sections: one
                     45: >>>> that's only editable by developers, and another that's editable by
                     46: >>>> anyone. Developers will use the "Edit" link as normal. For ease of
                     47: >>>> user editing, we'll want to provide an "Edit" link within the
                     48: >>>> user-editable section of the page which leads directly to editing
                     49: >>>> the corresponding Discussion subpage where that content is stored.
                     50: >>>> Either kind of edit will result in an immediate update of the Foo
                     51: >>>> page.
                     52: >>>>
1.21      wiki       53: >>>> With this approach, once the relevant
                     54: >>>> [[!iki bugs/anonok_vs._httpauth desc="ikiwiki bug"]] has been fixed,
1.18      wiki       55: >>>> the `opendiscussion` plugin should suffice to enable users to edit
                     56: >>>> content in a direct way, while also making clear to readers which
                     57: >>>> content comes from developers and which does not.
                     58: >>>> 
                     59: >>>> Things to think about when the time comes:
                     60: >>>>
                     61: >>>> * automating the `inline`, disclaimer, and user-edit link (in
                     62: >>>> [[!iki wikitemplates]]?)
                     63: >>>> * whether `anonok` is okay or we should require e.g. an OpenID
                     64: >>>> * treating non-developer edits properly in `log_accum` messages
                     65: >>>>
                     66: >>>> --[[schmonz]]
1.9       schmonz    68: _For non-developers using [[anonymous CVS|wiki/todo/push_wikisrc_to_anoncvs]]_:
                     69: submit a diff to `netbsd-docs@`.
                     71: _For non-developers using a web browser_: the ikiwiki discussion
                     72: subpage and/or [[!iki plugins/comments desc="comments plugin"]] may
                     73: point toward the solution.
1.3       wiki       74: 
                     75: One of the reasons we [[chose ikiwiki|wiki/todo/choose_wiki_software]]
1.9       schmonz    76: is the ability to edit via CVS directly, as well as via the web.
                     77: As long as every wiki editor is a developer, controlling access
                     78: consistently is simple. In order to open up wiki editing to
                     79: non-developers, we have to think carefully about both the CVS case
                     80: and the web case.
1.3       wiki       81: 
                     82: In the short term, to start getting non-developers involved, I intend
                     83: to [[push wikisrc to anoncvs]] and
                     84: [[hook up wiki commits to www-changes@]].
                     86: In the long term, ikiwiki has a few ready-made web authentication
                     87: options (a locally managed user database, OpenID, and HTTP auth), and
                     88: if they don't suffice for some reason, it's easy enough to write an
                     89: auth plugin. The hard part is deciding the workflow: where is a
                     90: sensible place for non-developers to make their edits, and what is a
                     91: sensible way for developers to review and "bless" the changes? Two
                     92: ikiwiki-native possibilities are listed above.
                     94: Ideas welcome! Edit this page and add your comments. --[[schmonz]]
1.4       wiki       95: 
1.5       wiki       96: One idea (which needs to be considered by board@):
1.4       wiki       97: 
                     98: 7. Enable Discussion subpages.
                     99: 7. Mark very clearly on the Discussion page template that content may
                    100: have been written by anyone at all and has not been vetted by any
                    101: member of TNF.
1.6       wiki      102: 7. Enable the `anonok` plugin and set the `anonok_pagespec` to allow
                    103: anonymous editing of Discussion subpages (and of no other pages).
1.4       wiki      104: 
1.12      wiki      105: > This doesn't actually work, though. Trying to create or edit a
1.14      schmonz   106: > Discussion subpage yields the HTTP auth dialog. And this is
                    107: > equivalent to the `opendiscussion` plugin. Joey says:
1.13      schmonz   108: > "it's a bug, not sure how to fix it right now". --[[schmonz]]
1.12      wiki      109: 
1.4       wiki      110: The resulting workflow:
                    112: 7. Non-developer finds a page to which to suggest changes.
1.9       schmonz   113: 7. Non-developer edits its Discussion subpage and writes the suggested
                    114: changes.
                    115: 7. Developer who follows [[RecentChanges]] (or the commit mails)
                    116: notices the changes.
                    117: 7. If the changes aren't acceptable, developer edits the Discussion
                    118: subpage and explains why not.
                    119: 7. If the changes are acceptable, developer applies them to the
                    120: page and removes them from the Discussion subpage.
                    122: > This can be work flow for a TNF contributed pages but as I said
                    123: > above this is not acceptable for as normal wiki workflow. We had
                    124: > almost similar discussion about comments on a blog software for
                    125: > NetBSD. There were developers who thought that there will be too
                    126: > many comments and we do not have man power to read/approve them
                    127: > all. After setting blog we have found that we have barely 1-2
                    128: > comments in every third article. I don;t thing that there will be
                    129: > too many real editors on our wiki from non-developers and therefore
                    130: > we need to make it easy not hard to do. --[[haad]]
1.12      wiki      131: 
1.25      schmonz   132: >> And yet, we already had spam on the blog. I'm not much pro
                    133: >> distributing spam, and would strongly suggest some kind of auth
                    134: >> that at least brakes spam down a bit. That also speaks against using
                    135: >> "any verifying OpenID" (ie users may opt to use OpenID but we still
                    136: >> need to put their ID into some sort of list of good IDs). --[[spz]]
1.20      wiki      137: 
1.25      schmonz   138: >>> This sounds reasonable. Getting oneself added to a whitelist
                    139: >>> isn't too much to ask a prospective contributor. The whitelist can
                    140: >>> be implemented using [[!iki plugins/lockedit]]. --[[schmonz]]
1.23      wiki      141: 
1.25      schmonz   142: >>>> spz: How much spam we had there ? Because during our initial
                    143: >>>> talks about blog there were huge expectations about number of
                    144: >>>> spammers and comemnters on our blog for now I don't think that we
                    145: >>>> have more then 30 uniq commenters/spammers that is so low number
                    146: >>>> that we should block user non auth editing because of it. -- [[haad]]
1.26      schmonz   147: 
                    148: >>>>> Not speaking for spz, but the current holdup is a more general
                    149: >>>>> interaction with [[!iki plugins/httpauth]] combined with any other
                    150: >>>>> type of auth (including [[!iki plugins/anonok]]). Once it's fixed,
                    151: >>>>> it's about the same amount of work for us to whitelist the OpenIDs
                    152: >>>>> of actual human contributors as it is for us to allow fully anonymous
                    153: >>>>> editing. So the question becomes, what's best for this wiki that admins
                    154: >>>>> feel is reasonably manageable and responsible? Even if the risk of
                    155: >>>>> opening ourselves for editing by the whole Internet is small -- and
                    156: >>>>> we can't know that -- I'm not comfortable putting TNF at that risk
                    157: >>>>> unless there's a very compelling argument for it. --[[schmonz]]
1.27      schmonz   158: 
1.29      schmonz   159: >>>>>> There's [CAPTCHA](
                    160: >>>>>> work in progress. That might be palatable, when done, as an option
                    161: >>>>>> in addition to OpenID. --[[schmonz]]
1.28      schmonz   163: After a bunch of work by Joey, we're much closer:
                    165: * With httpauth, you can (still) edit any page.
                    166: * With an OpenID we've whitelisted, you can edit discussion subpages.
                    167: * Otherwise, you can't edit via the web.
                    169: What's left:
                    171: * Extract the OpenID whitelist to a separate file for ease of maintenance.
                    172: * In `log_accum`, properly parse and display OpenID edits.
                    173: * In `page.tmpl`, inline discussion (if it exists) into its parent page.
                    175: --[[schmonz]]
1.30      schmonz   176: 
                    177: -----
1.33      schmonz   179: Whew, this is a long discussion. To recap, every wiki page will
1.30      schmonz   180: have two sections:
                    182: 7. Content editable by developers only, followed by
                    183: 7. Content editable by anyone who has told us their OpenID.
1.34      schmonz   184: 
                    185: This way, every wiki page will be editable (in whole or in part)
                    186: by everyone, while making the content's provenance clear to the
                    187: casual reader.
1.30      schmonz   188: 
                    189: I will implement this by abusing any and all of `inline`, templates,
                    190: and/or Discussion subpages.
                    192: There were problems combining `httpauth` (how developers log in)
                    193: and other authentication methods. The ikiwiki author has fixed these
                    194: problems.
                    196: I have working code to check OpenIDs against a whitelist. We need
                    197: to streamline the task of "registering" an OpenID as much as possible,
                    198: so non-developers can get involved with the wiki quickly and easily.
                    199: We will also want to delegate whitelist management to `www@`.
                    201: The wiki copy of `log_accum` needs to be taught to parse OpenID
1.35    ! schmonz   202: edits (and set `Reply-To:` to the committer, not ``).
        !           203: To avoid skew, we should then carefully merge it back to the main
        !           204: `log_accum`.
1.30      schmonz   205: 
                    206: Non-developers will want [[wikisrc in anoncvs|push_wikisrc_to_anoncvs]].
                    208: In the future, if and when ikiwiki has more fully baked anti-spam
                    209: measures, it would be nice to be able to allow anonymous editing.
1.31      schmonz   210: 
                    211: --[[schmonz]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb