File:  [NetBSD Developer Wiki] / wikisrc / wiki / todo / let_non-developers_contribute_content.mdwn
Revision 1.34: download - view: text, annotated - select for diffs
Thu Apr 1 13:51:47 2010 UTC (8 years, 5 months ago) by schmonz
Branches: MAIN
CVS tags: HEAD
2 != 4

    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]]
   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
   19: >> to making making Discussion pages world-editable, use the
   20: >> [[!iki ikiwiki/directive/inline]] directive on each main topic page to
   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]]
   29: >>> I don't understand why we are making user editing so hard, with
   30: >>> discussion pages there will be little or no user contribution which
   31: >>> is wrong because main point of wiki is to give users power to share
   32: >>> information not give this power to developers. Let's make part of
   33: >>> wiki editable by users to let them contribute their documentation.
   34: >>> If user will want to make his own page about e.g. using NetBSD as
   35: >>> xen server how he will done it with discussion pages ?
   36: >>>
   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]]
   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: >>>>
   53: >>>> With this approach, once the relevant
   54: >>>> [[!iki bugs/anonok_vs._httpauth desc="ikiwiki bug"]] has been fixed,
   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]]
   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.
   75: One of the reasons we [[chose ikiwiki|wiki/todo/choose_wiki_software]]
   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.
   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]]
   96: One idea (which needs to be considered by board@):
   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.
  102: 7. Enable the `anonok` plugin and set the `anonok_pagespec` to allow
  103: anonymous editing of Discussion subpages (and of no other pages).
  105: > This doesn't actually work, though. Trying to create or edit a
  106: > Discussion subpage yields the HTTP auth dialog. And this is
  107: > equivalent to the `opendiscussion` plugin. Joey says:
  108: > "it's a bug, not sure how to fix it right now". --[[schmonz]]
  110: The resulting workflow:
  112: 7. Non-developer finds a page to which to suggest changes.
  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]]
  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]]
  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]]
  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]]
  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]]
  159: >>>>>> There's [CAPTCHA](
  160: >>>>>> work in progress. That might be palatable, when done, as an option
  161: >>>>>> in addition to OpenID. --[[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]]
  177: -----
  179: Whew, this is a long discussion. To recap, every wiki page will
  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.
  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.
  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
  202: edits. To avoid skew, we should then carefully merge it back to the
  203: main `log_accum`.
  205: Non-developers will want [[wikisrc in anoncvs|push_wikisrc_to_anoncvs]].
  207: In the future, if and when ikiwiki has more fully baked anti-spam
  208: measures, it would be nice to be able to allow anonymous editing.
  210: --[[schmonz]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb