[Foundation-l] content ownership in different projects

Samuel Klein meta.sj at gmail.com
Sat Jun 18 22:58:35 UTC 2011


There are some technology changes that could make this much easier.

1) make it easy to see *your last version* of an article when you visit it.
2) provide a link to 'diffs since your last edit'
2.1) provide a way to comment directly on that diff, without having to
laboriously cut and paste
3) make it easy to snapshot a version of a page and put it in [your
userspace] for future work.  For instance, there could be a one-click
"move this revision to the same name in my userspace" button which
would let you work on a set of ideas over time even if you had
disagreements with others editing the article in a different
direction.  Once you were done, of course, you would still have to
work out if or how to marge those changes back into the original
4) have an entire tag-set and cleanup section for "articles for
merging" to address merge problems.
4.1) under the present process, the # of people who try to reach
consensus on merge conflicts a) are few in number; there is nothing
like an AfD cycle to bring in new eyes all the time; and b) work with
tiny changes, so a 3-person team can simply shut down all incremental
changes from someone whose changes they don't understand.  Naturally
frustrating.


> Nothing in particular. Dozens of times every day i edit articles in
> which i see mistakes. Usually nobody complains, but sometimes the
> people who wrote most of the article get very upset about the fact
> that i touched it at all and send me messages saying this. I used to
> reply and politely explain that that, by definition, is the way wikis
> work and to cite WP:OWN or its Hebrew counterpart. Sometimes it helps,
> but sometimes it makes the person even more upset.
>
> In such cases, as an Israeli saying goes, i am right, but i am not
> clever.

There's a tech/policy change that could make this easier:

Allow revisions to be named. We already allow multiple versions in a
fundamental way - past revisions are kept forever.  But we make it
particularly hard to access them.  By allowing revisions to have names
or tags, we could make the sort of concern Amir mentions above help
improve the project in a positive way, adding additional useful
information for readers.

For instance, ARTICLE?u=amir could show the last revision edited by
Amir, ARTICLE?t=good could show the last revision expressly marked as
'good' or better quality, ARTICLE?t=eb1911 could be the last revision
tagged as 'from the 1911 Britannica' before it started to be
significantly modified.  Flagged revs could become a feature that
chooses a tagset (beyond the most chronologically recent rev) used to
decide what most visitors are shown when they visit a page.  Users
with accounts could choose their own default tagset.

The hard problem would remain deciding what the 99% of visitors who
aren't logged in see when they visit a page -- the sort of decision
that the flaggedrev feature determines, combined with editorial work
of updating the article.

Apostolis writes:
> If wikipedia allowed articles to be forked and defined a trust metric that
> showed which article is more trustworthy, that would solve both previous
> problems and would also have contradictory ideas together, thus allowing
> people to have their own opinion about those different opinions and
> wikipedia wouldnt need to hide the strugle behind curtains.
>
> http://en.wikipedia.org/wiki/Wikipedia:Wikipedia_in_research#Web_Researching_Methods:_From_Google_to_Wikipedia
>
> Of course, this trust metric would have to be personalized, ie give
> different values depending on who the user trusts.

That's a slightly more radical proposal, but the basic idea of not
hiding the struggle of assumptions and opinions from readers is
important.  Just as we try to recognize significant views within an
article as neutral, we should recognize differing trust networks and
opinions of reliability.  This shoudl both make certain editorial work
less burdensome, and provide more information [rather than forcing
certain kinds of competing information to fight it out until one side
is exhausted or defeated.]

SJ




More information about the wikimedia-l mailing list