File:  [NetBSD Developer Wiki] / wikisrc / wiki / todo / let_non-developers_contribute_content.mdwn
Revision 1.22: download - view: text, annotated - select for diffs
Sat Jan 2 13:30:49 2010 UTC (8 years, 9 months ago) by wiz
Branches: MAIN
CVS tags: HEAD
Avoid suing NetBSD.

    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 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]]
  134: >>> This sounds reasonable. Getting oneself added to a whitelist isn't too much to ask a prospective contributor. The whitelist can be implemented using [[!iki plugins/lockedit]]. --[[schmonz]]

CVSweb for NetBSD wikisrc <> software: FreeBSD-CVSweb