Talk:Wikimedia Help

 Support. cool. Saeed.Veradi 18:32, 27 February 2009 (UTC)

a seprate wiki

I suggest localisation be done using separate wikis rather than "using either namespaces or a div class". You use Wikia as an example, but Wikia also has separate wikis for this (hilfe.wikia.com for German and aide.wikia.com for French for example). It makes it easier for people to get involved without the complications that wikis like Commons have and unlike commons, there is not as much advantage to having everyone on a single wiki. Angela 01:54, 24 December 2008 (UTC)

I strongly support this idea. I'm since 2006 trying to create a working set of docs on pt.wikisource with no success. Moving all documentation to a centralized per-language wiki may help non-Wikipedia projects a lot. A namespace for each project may be a good addition too. See this example:

• pt.help.wikimedia.org is the central place for docs in Portuguese language;
• pt.help.wikimedia.org/wiki/Help:Footnotes is a page explaining how to use the <ref> tag;
• pt.help.wikimedia.org/wiki/Wikipedia:Footnotes have tips-and-tricks on how to use the <ref> tag at Portuguese Wikipedia plus some specific instructions related to the {{cite web}} family of templates;
• pt.help.wikimedia.org/wiki/Wikisource:Footnotes have instructions on how to annotate a work, including how to explain typos from the author/printed edition and how to explain some obscure section to the general public;

555 02:42, 24 December 2008 (UTC)

Didn't know about the separate wikis, Angela - thanks! I think sub-sub domains like 555 said would be best, instead of having the word "help" in multiple languages. Not so sure how much the developers would like seperate domains for every language that Wikimedia hosts. If they don't, then it would be great. --Thunderhead 04:47, 24 December 2008 (UTC)

Why a separate wiki?

I think a movement towards centralisation help pages right here would be more effective and more proper than the starting of a whole new wiki. What else is meta for, after all? I like this idea, but I'd prefer to see it as a cross-wiki effort focusing on the moving and translating of help pages to Meta. —Anonymous Dissident^Talk 03:00, 24 December 2008 (UTC)

Well, you could make the same point for quality.wikimedia.org couldn't you? That wiki was set up so that users, no matter what language, would have a go-to-point to learn more about Wikimedia. If we were able to link specific wikis to one place where they could get help without having to hunt it down, it would expand our userbase, and make more people comfortable with using Wikimedia. --Thunderhead 03:25, 24 December 2008 (UTC)

It was? I thought that wiki was just a ploy by the Foundation to get more donations by pretending that donating somehow affected the quality of the projects' content -- Gurch 19:52, 26 December 2008 (UTC)

Problem with this...

...is that most help content is project-specific. How to ask for deletion of a page on the English Wikipedia is quite different from how to do it on the German Wikipedia which is quite different from how to do it on Commons and so forth -- Gurch 20:11, 25 December 2008 (UTC)

Indeed, it's quite user-unfriendly when you have to go to one page to learn that page moves are done with the move tab, and another page to learn that you should read WP:NAME before changing names. Separating software-related and community-related help information will result in lots of duplications and crossreferences and a rather artificial structure. Having a centralized software-related help might be useful for smaller wikis which don't want the overhead of maintaining the same help instructions on every wiki of that language, but using the help namespace of the local wikipedia works well there, and larger wikis will want a single help space that's easier to use. --Tgr 00:16, 26 December 2008 (UTC)

On the other hand, if someone thinks it's a good idea to have a separate, site-agnostic help, why not use the MediaWiki wiki? It exits for exactly this reason, and improving it will be much help for smaller, non-Wikimedia wikis at least... --Tgr 00:20, 26 December 2008 (UTC)

I like the solution of the English Wikipedia: a copy of the centralized help pages (may be could it be transcluded?) with a section added for help specific to the project, i.e. en:Help:Special page with a section added by template or ca:Ajuda:Pàgina especial with a subpage transcluded. It is a way to add project specific notes or internal links to other pages. --Vriullop 10:31, 26 December 2008 (UTC)

I believe, a project agnostic help should exist, and is to provide a firm basis for project specifics. Many things do not differ between projects. Translators need to be able to make help and descriptions available for "out of the box" MediaWiki, and its Extensions. This needs a reference help system (-: in english, probably :-) so as to allow checks for completeness, and easy, or automated checks for alterations of the reference system requiring translation updates.

It needs to automatically integrate extensions, inluding their help pages, if extensions are installed, and must automatically adjust to, or incorporate, standard values set by installations.

e.g. if every user can delete pages because the wiki operator allows it, then a sentence "Being an ordinary user, you must ask an {{int:group-member-sysop}} to delete the page for you. See … how to do that" needs to be automatically omitted via some parser function magic, or similar.

There need to be marked spots where to plug in community specifics in all foreseeable instances, such as the ellipses ("…") in the sample sentence above.

If we do not pay attention to very basic guidelines like these ones, I believe, we'll be without a chance to provide proper help in most languages. --Purodha Blissenbach 02:45, 1 January 2009 (UTC)

I would strongly oppose such a regimented system as this. The flipside of saying "we need to provide places for people to slot in content" is that "people can only slot in content where we say". Are these help pages going to be like our Special: pages, customisable only through system messages? That hardly encourages the 'anyone can edit' philosophy.

We need to make a very clear distinction here: there is a world of difference between 'technical' help ("You can move pages by clicking the move button") and 'procedural help ("You should moves pages under these conditions"). The two are not the same and shouldn't be considered to be so. One is constant across all MediaWiki installations, and variances like what the 'move' tab is actually called can be trivially accounted for. The other varies widely between wikis, and the restrictions may be one sentence, or ten screens. Thinking that either alternative can equally well slot into an ellipsis in the help text is counterproductive.

Technical help does not vary between projects, so one text can cover all wikis. We already have a repository for such text at http://www.mediawiki.org/wiki/Help: and our real focus should be "how do we get that content back to our wikis?". The process whereby a bot copied content from meta to en.wiki worked, but is long since defunct: the help pages haven't been bot updated for literally years. We need a method of access this content dynamically, so that it updates itself with new changes to the source. We need, in short, either interwiki transclusions from, or interwiki redirects to, mediawiki.org.

The other block of help content is 'procedural' help. I honestly think that attempting to unify this is asking for a world of pain. Projects are responsible for creating their own policies, projects must take on the parallel responsibility of explaining those policies.

All in all, I think that we already have the structures in place to best organise help content on wikimedia, just that we're not using them to their full effectiveness. Happy‑melon 16:48, 8 January 2009 (UTC)

Likely, Betawiki is a good place for making tranlations of help pages. It has much of the required structures already in place, and it is dedicated to translations anyways. --Purodha Blissenbach 02:50, 1 January 2009 (UTC)

More help issues

I should start out here by noting that I lead a semi-successful VfD to quite a bit of the Help content on Wikibooks and may have in part participated in the current situation regarding Help pages. Some of the participants of the the meta help pages have also be almost irrationally protective of their project, to the point that VfDs for similar kinds of material have also been started on Wikibooks just because some of the content may be considered within the scope of the Help pages on Meta.

I should note that for things like the b:MediaWiki Administrator's Handbook, those VfD attempts were thwarted and genuine project independence was maintained.

There are two kinds of "help information" that needs to be generated:

1. Information about how to edit content using MediaWiki syntax to make the content that you want to put onto a wiki page. This sort of "help" information is very generic and is not specific to any specific project. Some of the more complicated parts like template tools and configuration tasks are of particular relevance and the "help" pages are the only way to even find out about them.
2. More specific information falling within the scope of individual projects. Some projects like Wikinews or Wikibooks have some more general "guidelines" in terms of how content is strongly suggested to be organized. Some of this fits within the scope of a "style guide", although things like how to create a PDF version of a Wikibook can prove to be legitimate "help pages", but don't necessarily fit within the scope of something that needs to be available for all projects.

Previous attempts to keep help pages in sync with each other by setting up 'bots that copied all of the help pages from meta to all of the sister projects ultimately proved unworkable. Indeed, that is what my VfD was mostly about, as I saw it to be a pointless exercise and ultimately destructive when good-faith edits were being over-written mindlessly on the sister projects.

For myself, much of what is in the "help pages" on meta really ought to be a Wikibook, and clearly fits within the scope of the Wikibooks project. For historical reasons (and some people with incredibly huge egos), this information was kept on Meta. I certainly wasn't going to try and rock the boat on this point, but it seems unfortunate that such antagonism about this issue has happened. The content is now scattered across several projects in various forms and clearly shows the hands of a great many people with very different editorial and content organizational philosophies.

As to the need for a completely new wiki dedicated for just help pages, here are some reasons that I see are strong arguments in its favor:

• Project neutrality - Content can be added to the "help" pages without having to worry about standards or guidelines on any specific project, and the content relating specific to a single project (like Wikipeidia) can be removed. Meta, BTW, shows an incredible Wikipedia bias but I'll leave that issue alone for now.
• Non-Wikimedia projects - Just as project neutrality is important, it is even more important for non-Wikimedia projects. Having a single relatively small database for the "help pages" could make it easier to simply copy all of the "help pages" over in one quick database grab and help seed some information for a new MediaWiki installation. There certainly are several reasons why some 3rd party site developers may not want to get bogged down into Meta politics or have to deal with or depend on the Wikimedia Foundation, yet still use the MediaWiki software and have documentation on how their users can edit these wikis.

Here are some reasons to avoid creating a new wiki:

• Administration - Project administration for a new wiki is a major problem. This includes getting a strong and successful team of project administrators who are willing to protect content from vandalism and in general take care of the heavy lifting in terms of linking and connecting pages, or doing other clean-up work that happens in the process of wiki-style editing. Preferably, a strong team of about 10-15 experienced users is the ideal in terms of being able to keep a wiki sustained without placing undue burdens on any single administrator and being able to cope with attrition from admins dropping out from time to time and incorporating in new blood without changing editorial policies too drastically. I'm not talking 10-15 active users, but 10-15 very experienced users who also are willing to take on administrative tasks and have proven reliable qualities to watch after each other as well. Most of the English-speaking and the stronger non-English sister wiki projects all fit this definition of a core admin team and about double (or more) regular active users. With the exception of some of the core languages (English, Spanish, Chinese, Russian, and a few others) I don't see how this "help wiki" can possibly get this sort of core team together even from a wildly optimistic projection of the number of participants for this sort of content.
• Isolation - By being off on its own, an independent wiki often suffers from isolation of members of its community. Again, this shows my own biases here, but each time I've seen a group of users "fork" or go off onto their own as a completely separate wiki community, there is a transition time where the project turns into a "one-man band" of a single or very small group of individuals who are building content and keeping the wiki alive. Wikiversity was a major exception to this, but that community was already quite well developed on Wikibooks before the community split. I'll also note here that once Wikiversity split off from Wikibooks, the overall activity rate on Wikibooks fell as well.... much more so than just the content typically noted as being a part of the Wikiversity parts of Wikibooks but also for the more traditional "textbook" areas as well. A similar sort of drop in activity also occurred when the gaming guides were removed from Wikibooks. There is a certain amount of synergy that happens when several users are working together on the same wiki database even if they are working on wildly different kinds of content, as you are more likely to at least "click" on a link and check out what is going on or get involved in community discussions to help resolve what might be common problems. BTW, the above drop-offs of activity on Wikibooks can be seen on Alexa graphs and elsewhere from raw statistical analysis, even though technically Wikibooks did recover and grow to become larger than it was before either community split happened.

This is not an easy issue here to resolve, and there is no "right answer" in terms of if an independent "help page" wiki needs to be created or not. The above points are just stuff that comes right at the top of my head from years of experience in working with wiki projects, so I hope that this experience can help with this decision making process. The "problems" with splitting off to a separate project certainly need to be addressed in a successful proposal, and a "if we build it, they will come" attitude simply isn't a logical or rational justification. --Roberth 18:12, 2 January 2009 (UTC)

Let me reiterate, such a wiki has existed for quite a while, it's called MediaWiki wiki. It is the central source of technical information for all MediaWiki users, administrators and developers, it is completely project neutral, has a fairly large community (20k pages, nearly 500 active users, 50 sysops), and it has a project going on to create public domain (very important!) project-neutral help documentation that can be automatically installed with MediaWiki at some point. They could always use some help.

If we are speaking about the help pages on WMF projects, however, I still say larger prjects should have their own project-specific help pages, even at the cost of duplicating much of the project-neutral technical information. Cutting the project-specific and the project-neutral part of every help topic into two separate pages is just too user-unfriendly. --Tgr 13:16, 11 January 2009 (UTC)

That is why I advocate having those two kinds of information together - in one namespace, and where appropriate, in single pages. Not all project independent stuff is needed everywhere. Say, if redirects are forbidden, or page moves are resticted to admins, the redirect help should not be shown at all, and the generic page-move help needs to be available and linked at a diffferent place than on wikis where everyone has a right to move. These differences, however, can be dealt with using templates and conditionals which simply use wiki setup variables - both inside pages, and by any static update mechanism.

So as to avoid good faith users to make enhancements to local help pages that get overwritten when master pages are altered, such edit attempts need to be automatically redirected to the master pages, wherever they are kept. Of course, users deserve an explanation why that happens.

On the other hand, project help pages of non-global nature, of course need to be editable locally.

Either transwiki update mechanism, bot copying, or interwiki transclusion, needs to be fed the kind of a page: editable globally/locally, transcluded yes/no, maybe more. The same info needs to be available to editing users of course.

If we do not implement this using two different help namespaces, which I think, we shouldn't, we would have to have some structure pre-established on the master wiki.

We also need to keep in mind that, at least on the project agnostic part of help - which nevertheless 'reacts' to project/wiki installation details - we will be having to make many (all) languages available everywhere in a majority of wikis, and appropriately evaluate any ?uselang=zxx from command lines. --Purodha Blissenbach 18:49, 12 January 2009 (UTC)

Islolationism shouldn't really be a problem. All of the current Wikimedia sites have help pages, and unlike creating a new wiki for new content, this would be a way to bring editors from different wikis and different languages together. The same argument could be applied to the administration part. --Thunderhead 18:13, 29 January 2009 (UTC)