[arch-general] What is the current wiki-poliicy for re-writing contributions?

[Dario Giovannetti]

I'll try to integrate what Feng and Maxwell already explained about the
official ArchWiki policies regarding these matters.

> What is the current policy for having wiki-contributions re-written?

The content added to the wiki is published under the GFDL [1], and any
registered user can edit it as they wish. It's up to the other interested users
to keep watching the content and protect it from counterproductive edits, see
also [2]. There are no users paid for watching wiki pages, therefore no third
party, not even admins, can be held responsible for how articles are changed.
If an article is changed in a way that somebody thinks is deteriorating, it's
only up to them to take action, possibly opening a discussion in the article's
talk page (not in the forums or this mailing list, or just whining on IRC).

[1] http://www.gnu.org/copyleft/fdl.html
[2]
https://wiki.archlinux.org/index.php/ArchWiki:Contributing#The_most_important_task

> Under the current system, the pages are slowly becoming less-useful rather
> than more useful as more and more information is chopped out of pages or
> replaced by links to 3rd-party pages that may (or may not) be there tomorrow.

This is not true at all. No information is replaced with broken links, which is
what the cited passage means. If information is replaced with a link, it's
thought that the same thing is explained better at the link target, which must
be a valid (internal or external) page. If useful information is removed
without pointing to a new location where to read it, it's a counterproductive
edit (see above) and must be reverted or at least discussed. If you can cite
specific examples, we can discuss them, otherwise this is only bikeshedding.

As already explained by the other wiki staff, on the wiki it's strongly
discouraged to duplicate content between - or within - articles, of course with
exceptions only made where reasonably needed. Yes, this forces people to follow
links instead of being able to read everything in a single page: while this
seems a disadvantage at a glance, it's actually a big usability improvement,
since having multiple pages talking about the details of the same topic will
force users to compare all of them with each other to understand which one has
the most accurate and up to date content, since inevitably some of them will be
left unmaintained even in the medium term.

In this thread we see a few people complaining about this policy, but this is
not statistically relevant, as it's very unlikely that all the users who
instead see this as an efficient policy will start a thread to say how happy
they are with the way the wiki is organized, i.e. the policy is not going to
change on the basis of a ML thread, just to release an official statement with
my wiki admin hat on :)

> Perhaps there could be a tutorial section for aetting up the basics, and a
> reference section. Or seperate pages, such as Program/Tutorial for setting
> up and Program as reference.

If "tutorials" means systematically writing tl;dr sections for users who want
copy-paste-ready code to get stuff to work in 5 minutes without understanding
what they're doing and why, with all the future maintenance troubles that this
will cause, then maybe those users should consider using other distributions
that have (semi-)automatic configuration of the software and can support that
kind of tutorials. Arch is too customizable to be able to support tutorials
like that in general, since the various usage scenarios are usually too
numerous, and users would end up writing tutorials for each of their personal
scenarios, thus leading to more and more duplicated content with the same
problems outlined above. The generic system installation is the most notable
example where we don't accept tl;dr walkthroughs.

Again, of course specific cases can be discussed, as we do have some articles
that are used to show how the information from multiple pages can be combined
together to reach a particular result.

> Some time ago I stumbled on selective transclusions in the wikipedia
> help.[1] It seems to be an extension, that allows display of a partial
> article inside another article.[2] Maybe that would help to collect the
> necessary information in the "Beginner's Guide"

The idea of using transclusions has been considered a few times in the past,
but always discarded because it would make the maintenance of the "source"
articles much more complicated, since the articles that transclude them should
also be kept into account when doing changes. Also, I don't see the advantage
that this would have over simple links pointing to the relevant article sections.

> This probably won't be feasible for now but may become necessary with
> further archwiki user-percieved degradation. A main open wiki and an
> archlinux basics closed wiki. For anything to get into the archlinux
> basics wiki it will have to be verified as working and whichever user
> verifies it as working gets credit for verification in the article along
> with the author and the verifier cannot be the author. Articles in the
> archlinux basics wiki could refer to articles in the archlinux main wiki
> but by themselves will be sufficiently informative to get packages
> functioning on a basic level. The arch basics wiki is closed to prevent
> what happened to the archlinux main wiki; edits can happen and those edits
> would not happen on original articles in archlinux basics until they had
> gone through verification and the edited version of the articles would
> live in incoming space until either verification or rejection had happened
> due to verification failure.
> I do realize any such change will take volunteer hours to do and for now
> the community probably hasn't got those available. I hope the pain level
> does not rise to a level sufficient to make such changes necessary too.

The "pain" level rising from such an implementation would surely be much more
unbearable than that felt by some users when following links to read the
content they need ;)

Dario (Kynikos)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/arch-general/attachments/20160325/107a6a96/attachment.asc>