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)
Attachment:
signature.asc
Description: OpenPGP digital signature
