Project:Village Pump/Archive 2

__NEWSECTIONLINK__

Forum | Current issues

This page is for discussing broad issues of policy, structure and content of MediaWiki.org. Discussion about smaller site-related topics (e.g. problems, specific pages, etc.) should go in Project:Forum. Sorry that this isn't so clear from the page names...

MediaWiki.org is growing (in particular there is a movement to transfer in a lot of content from meta) and there are several areas of policy that need to be formulated in order to avoid confusion and complications in the future. This page should be used to state issues that need to be addressed. The items on this page are in no particular order and some are more important than others, but all will need discussion at some stage. Please add to this list. --HappyDog 03:24, 2 July 2006 (UTC)

Purpose
As far as I can see there are two purposes for this site.


 * 1) To provide information about the MediaWiki software.
 * 2) To provide a home for developers and other people involved in developing the software.

However, this is not clearly defined anywhere. A clearer statement of purpose is, I think, required. This ties in with the language/namespace issues, below. --HappyDog 13:59, 13 August 2006 (UTC)


 * About this site? --Swift 18:36, 24 August 2006 (UTC)


 * That's where this information would go, but at the moment it is not clear enough. For example, should info about extensions be on this site? What about unreleased extensions?  Should developers be using the site as a discussion ground (bearing in mind the other existing avenues of discussion)?  What about things like release notes/changelogs (which are already available elsewhere).  Personally, I think that all of this should be available through mw.org, but I don't know if this is the general view, and it is certainly not what we say on About this site... --HappyDog 12:16, 3 September 2006 (UTC)


 * You're right. My oppinion:
 * Extensions: Yes, also unreleased ones. Extension developers would have access to MW.org to place their documentation or link to it.
 * Developers: Development documentations could be fitting for this site, but discussions aren't a Wiki's strongest suit. Rather have links to mailing lists and archives from relevant Devel pages.
 * Release notes/changelogs: Since they are available elsewhere, we shouldn't duplicate that info (which will only be out of date at least for a little while) but rather just link to that information.
 * Do you want to take the lead and start up a discussion on Project:About (which I think is a better place than About this site? We may want to word things vaguely, though, since respective users are probably best at defining the site scope regarding their corners of it. --Swift 04:44, 18 September 2006 (UTC)

Languages
Currently the official line about language for this site is "Even though there are some pages in other languages, English is the main and reference language on the whole site." 1.

The issue here is between the two different purposes. It makes sense to provide information about the software in multiple languages, but it also makes sense for people working on the development of the software to use a single language (English).

I think it is a given that any instructional content on this site should be provided in as many languages as possible, however we have yet to decide a suitable way of handling this. This ties into the PD help, which should be available in all languages in a way that can easily be imported into an existing wiki.

Currently the convention is to add the language as a suffix to the name (e.g. Help:Contents in French is Help:Contents/fr). However this is not suitable for import, so consideration needs to be given to how this should be achieved. --HappyDog 13:59, 13 August 2006 (UTC)


 * Would it be too much of a seperation to go the way of many WikiMedia projects and add the language code as a prefix to the hostname? Would we need different databases for that?
 * What, exactly do you mean by "import"? --Swift 18:39, 24 August 2006 (UTC)


 * By import, I mean that the public domain help pages are being designed so that they can be easily imported into a new wiki (or included in a fresh wiki install). Each language will have it's own default name for the help namespace, e.g. Aide: (french) or Hilfe: (german) and we need to make sure that pages are imported to the correct place.  Languages should also be independent, so that they can be installed separately or together (i.e. the wiki administrator can choose to install help in just one language, or any combination of two or more available languages).
 * Separate language prefixes is one solution, but not necessarily the best. There will be some content (e.g. developer discussion) that should be located in a single place, however it may make sense for the reference material.  I am open to suggestions... --HappyDog 12:16, 3 September 2006 (UTC)


 * Are there no clashes between help namespaces (such as beteen Spanish and Portugese. Would Flemmish have seperate help pages from the Dutch).
 * What are the problems with the import mechanism? Why wouldn't it be possible to set up a one-to-one mapping between the Help:PAGENAME/cc and the translated help page name, then extract it from the database. Could you explain how one would normally go about importing pages. Sorry, my technical experience is with the software is limited. --Swift 04:58, 18 September 2006 (UTC)


 * Afaik, it is not necessary that we maintain dozens of help namespaces (that would mean much clutter, and is becoming - logically - more and more messy with time).
 * The one point is, there are clashes with the word help in several languages. The other point is that Help: ist the default and always usable naming of the help namespace on every MediaWiki wiki, unregarded which language actually is chosen as the one for the wiki's interface. Therefore it should be possible that we only work on one (english) namespace called help, and use subpages for translations (btw: that means, that we will only accept subpages in this namespace for language reasons). It should also be easily possible to develop an automated mechanism to extract a set of pages in one language from all the one help namespace and its pages like Help:Foo/xy (this is a challenge for 2007), and to change the page names afterwards in a once given way, e.g. Help:Tables/de > Hilfe:Tabellen. Generally, the process of arranging such "downloadable set of help pages" is thought to accompany the software release scheme (currently approx. 4 times a year). -- :Bdk: 07:35, 18 September 2006 (UTC)
 * going back...
 * to the left...
 * of the page...

Hmmm... and now that's got me thinking... So how about the root pages in the help: namespace are all in English, with any non-English versions of a page being stored in a sub-page named for the iso code of that language (so far, this is as you said). We then add a template to the top of the page, e.g.  which does the following things: When we extract the pages, the conversion script would remove this template inclusion, thus removing all the other MW.org navigational elements as well, and rename the page according to the title given at the top. If no title is found the namespace can still be deduced, but the English title will be used. Does that sound plausible? The other main export consideration is the rewriting of internal links, though this is probably a fairly simple regex if (a) we ensure that all on-wiki links are to same-language pages in the help namespace and (b) we know the language (which we do). Are there any other considerations or problems that you can think of? --HappyDog 00:04, 19 September 2006 (UTC)
 * 1) Adds the PD help template.
 * 2) Adds the page to a category for all pages in this language (e.g. Category:Help/de)
 * 3) Adds the language links using the current template
 * 4) Adds a header that says "The correct title of this page should be Hilfe:Tabellen" (possibly completely localised if that is better).


 * I apologize, my brain isn't working enough to understand the conversation so far, but FYI it's possible to have interlanguage links using just one MW and one DB, described somewhere here: m:Help:Guide_for_system_administrators_for_setting_up_interwiki_linking. Thats a confusing page, and I can't find where it describes it, so I've written it on its :m:Help_talk:Guide_for_system_administrators_for_setting_up_interwiki_linking talk page]]. The basic effect is that you add an interwiki link as normal, and it appear as normal in the sidebar as normal, but alternate languages are linked to and stored in the languages namespace, ie Francais: namespace, or the Espanol: namespace. Just food for thought in case its useful --Rick 19:15, 25 September 2006 (UTC)
 * This does not quite work in practice. For example, fr:Aide:Sommaire links to the page 'Aide:Sommaire' in the 'fr' namespace (or 'Francais' namespace as it expands to) instead of the 'Aide' namespace on a French language version of the site, as you would expect.  In essence you are providing a shortcut to typing the namespace name, with the added bonus (if I understand you correctly) of having the language listed in the left navigation.  Unfortunately this is not suitable for our needs here.  Indeed, I am currently of the opinion that a single namespace with language sub-pages is a very workable solution (with a few caveats that I am in the process of ironing out).  Also, we are in a position where we could have separate international versions of this site if we wanted, however the current feeling is that this is a bad idea (at least at the moment). --HappyDog 23:44, 25 September 2006 (UTC)

Please see Automating help page export for further discussion.

Navigation
It is important that the site outline (where stuff goes) be decided and that the navigation box in the left sidebar (in fact the left sidebar as a whole) simply and clearly reflect it. --Rogerhc 06:10, 15 August 2006 (UTC)

Links to other sites in the navigation box of the left sidebar cause confusion. Those could go in a related sites box instead to make it clear that they are not for navigating this site. --Rogerhc 04:41, 15 August 2006 (UTC)


 * Agree. See Mediawiki:Sidebar for some comments. --Swift 19:06, 24 August 2006 (UTC)

Manual front door
The Help namespace's front door is currently Help:Contents. I propose the Manual namespace's front door be kept consistent with that and be Manual:Contents. Predictability and consistency is important in navigational elements. Manual:Technical reference is inconsistent with the good navigational precedent set by Help:Contents. So, may I move Manual:Technical reference to Manual:Contents ? --Rogerhc 05:05, 16 August 2006 (UTC)


 * Contents is a good front door. It might be better to start a new page from scratch, rather than just move Technical reference, since there are more pages in the Manual. --Swift 19:06, 24 August 2006 (UTC)


 * There is a slight problem here - there are several 'manuals' that will ultimately be on the site. The 'technical manual' is the only one currently available, which essentially contains reference information about the software internals.  I always imagined that there would be a 'sysadmin manual' with info for system administrators, and maybe a 'developers manual' for people developing the code/extensions.  Are we planning to combine all these into a single resource, or divide it amongst the various target audiences? --HappyDog 23:49, 3 September 2006 (UTC)


 * I advocate Manual: namespace hold all the various kinds of technical documentation about core MediaWiki
 * Help: namespace hold, as described on Help:Contents, the generic public domain Help pages for site users (and for easy adaptation into other MediaWiki site's)
 * An Extensions: namespace I imagine could hold third-party code documentation of extensions and non-standard-skins
 * Categories are namespace agnostic and can evolve regardless of namespaces. They will evolve better if they start out sensibly and evolve through oversite from folks who know, care and are willing to help it stay simple. How to set up a good sensible (simple) set of categories? I don't know our content well enough to do it myself. Folks who know the content better could present simple Mediawiki.org-site-wide documentation category structure ideas perhaps?
 * --Rogerhc 04:05, 18 September 2006 (UTC)


 * An important benefit of namespaces is that they can be searched independently. I think this should be a large factor in the question whether we should split the Manual namespace up between sysadmins and developers (I agree with Rogerhc that the PD users' manual can be in Help).
 * If we split the namespace up, perhaps it is best to leave the sysadmin manual in Manual, the user's manual in Help and put the developers' manual in Devel or something similar. --Swift 04:18, 18 September 2006 (UTC)
 * Actually, looking at Project:Namespaces I'm starting to think that devel related material could be well suited for the main namespace. --Swift 05:12, 18 September 2006 (UTC)


 * This conversation has drifted slightly, and would probably be better as part of the namespaces discussion, below. The original point here was about whether to move 'technical documentation' to 'manual:contents'. However we may as well continue here... :)
 * The summary given by rogerhc fits with how I envisage the site layout. The use of the main namespace for anything at all seems a bit unintuitive, simply because there is no 'main' usage for the site - there are several separate uses that are at an equal level of importance, so the main namespace almost becomes redundant. I still haven't found a sensible purpose for it within the structure we are building.  Regarding developer manual, apart from the search issues, I think the it (and any other non-PD manuals, which may include a more detailed user manual) should be in the Manual: namespace.  Developer discussion, e.g. draft proposals etc. need to be elsewhere, maybe in the main namespace, maybe in a new namespace (maybe in user space?).  I feel that structurally keeping all manuals together in the Manual: namespace is higher priority than splitting them up for ease of searching (particularly as most users won't modify their search settings to only use the appropriate namespace, so will see no benefit).  Also, if we _do_ have separate manuals in separate namespaces, then 'Manual:' is a very bad name... --HappyDog 12:50, 18 September 2006 (UTC)


 * Yes, this has, indeed drifted somewhat. Feel free to move and/or refactor my comments into a more fitting section.
 * What, exactly, will the developer manual contain? The way I see it, it will just be stuff about the software, documenting the structure and purpose of various scripts and functions. I kind of like the structure outlined in Project:Namespaces where it gives the contents of the Main namespace as:
 * "All general stuff about the software"
 * My understanding for the developer "manual" fits quite snugly into this. Perhaps I'm misunderstanding the contents?
 * As for developer discussion, draft proposals, etc., I would expect them to mainly take place on email lists as is more common for software development. Is anyone here part of the development team? It would be interesting to get the team's oppinion on how they would like to use the site. --Swift 16:57, 18 September 2006 (UTC)


 * In my view the developer manual should be in the Manual namespace. A current example is Manual:MediaWiki hooks.  Re: developer discussion, you are right that most of this will take place on irc/wikitech-l, but I think that MW.org could become (is already becoming?) a useful place for developers to develop features and tools, draft documentation, create test cases, make notes and brainstorm.  These are the items that I am referring to when I say 'developer discussion' (which I admit now is a confusing expression to use in this context). --HappyDog 23:49, 18 September 2006 (UTC)


 * Thanks for the elaboration. Is the Manual:MediaWiki hooks page useful for site admins? If not, why not just place it at MediaWiki hooks? The others you mention also all fit quite nicely in the Main namespace given that it is for pages about the software (while Manual is about setup and tuning and Help about using the software). --Swift 03:32, 19 September 2006 (UTC)


 * going
 * back
 * to
 * the
 * left
 * margin


 * As far as I am concerned, Manual: should be for all reference material. There will be a 'technical reference' which is aimed primarily at developers but which will have a load of info for admins as well, an 'administrators handbook', and probably some other items (e.g. a more detailed users handbook).  The hooks belong in the the technical reference, along with the $wg variables, db schema, object structure etc.  I think you are coming at it from a slightly different angle, and assuming that namespaces are divided up by target user group, but this is not the case and cannot be the case as there will be a fair amount of information that overlaps (config variables being a good example). --HappyDog 11:06, 20 September 2006 (UTC)


 * That was precisely my angle. The main reason being that while interlinking is good for its use, the namespace offers an added feature to the extremely useful seach tool. I'll agree that if there is a substantial overlap in the sense that a page will belong just as well to the devel manual and the admin one (since there is no reason the admin and devel manuals/handbooks can't interlink to informative pages) then yes, they should share a namespace.
 * There will certainly be (quite possibly frequent) cases where site admins will want to see references normally aimed at developers or others interested in the software's internals. Unless there is a great problem with determining what should be in the admin vs. the devel manuals, we should not so readily dismiss grouping them into different namespaces. If split, they can still be searched together and interlinked as before, but if kept in the same namespace, we lose a valuable aid to those unfamiliar to the software or this site.
 * I don't have a strong oppinon of what to do, since because I don't really know what the devel manual will hold. Will it mainly be the technical reference, or is there more? If there isn't much else, how about making it into a "Reference" namespace which will be an additional resource to the admin Manual?
 * Sorry for being hard headed. I think most of my stubborness comes from the fact that I'm just not quite sure what the (non-main namespace) devel part of the website will hold and how you envisage it structured (I'm mainly here for the admin and user part). --Swift 19:30, 20 September 2006 (UTC)

Community portal
MediaWiki.org needs a Community portal link in the left sidebar. It's a wiki with great community potential but to thrive it needs to welcome and orient newcomers effectively. A wiki without an effective community is a sad thing, especially when it has as much genuine user interest as MediaWiki.org has. --Rogerhc 05:45, 16 August 2006 (UTC)


 * Agree! --Swift 19:06, 24 August 2006 (UTC)


 * What is the community? Is it the community of mediawiki users?  The community of developers? The community of people using mediawiki.org?  The problem I have at the moment with a lot of the items up for discussion is that we haven't established how we want to divide the site amongst the various target groups.  --HappyDog 23:49, 3 September 2006 (UTC)


 * All of the above. Project:Forum could be the place to be for "people using mediawiki.org" (which includes everyone). Help:Forum might be a place for software end-users and Manual:Forum for software maintainers. Possibly the devels won't need a forum since they may well prefer mailing lists that are probably better suited for their sort of discussions. If they want, they can have one where they'd like (I think we can trust their good judgement).
 * All could be linked from Community portal. --Swift 05:09, 18 September 2006 (UTC)

Main Page redesign
I have come up with a suggestion for a new main page design. Please let me know what you think. --HappyDog 01:00, 4 September 2006 (UTC)


 * Looks great. A good concept and a vast improvement over the curent main page. --Swift 08:33, 16 September 2006 (UTC)


 * This is now live. --HappyDog 01:43, 29 September 2006 (UTC)

Namespaces
This is pretty much sorted, but the following issues remain:


 * 1) The 'project' namespace is badly named.  For us 'project' means the mediawiki.org website.  For most people visiting the site 'project' means MediaWiki.  I propose renaming this to "Site:". --HappyDog 13:59, 13 August 2006 (UTC)
 * How about "About:" --Rogerhc 04:52, 30 August 2006 (UTC)
 * "About:" is too vague. About what?  About the site, or about the software?  The project namespace should be solely used to administer mediawiki.org.  It will be where we discuss site issues, and where we provide help about the site.  Any other information will not be in this namespace.  That is why I proposed "Site:", as I think it removes the ambiguity.
 * Hm, yes, I agree now with 'Site:' as namespace for stuff about the site itself and I agree it is better than 'Project:' which is too vauge. HappyDog, could you do it - rename the 'Project:' namespace to 'Site:' and update all relevant pagenames and links (with a robot maybe?)? --Rogerhc 00:32, 5 September 2006 (UTC)
 * Shouldn't need to redirect, as Project: will still work (although we may still want to do so for clarity's sake). I would like to get the agreement of a few more people, esp. bdk & robchurch before doing this as it will be a _lot_ more work to change a second time (in the sense that 'Project:' will always work, but links to 'Site:' will be broken if it is changed again). --HappyDog 02:12, 5 September 2006 (UTC)
 * Hm, Project: sounds logical and pretty ok to me (project in the whole wiki world always means the writing of the wiki itself, afaik), other than Site: (sounds more like "sitemap", and is quite unusual for community and organization stuff). But I'm not a native speaker. -- :Bdk: 02:28, 5 September 2006 (UTC)
 * Project is definitely ambiguous. If I came to this site with no prior knowledge, 'Project' would mean the 'MediaWiki project', just like in the sidebar where 'SourceForge project' means 'the MediaWiki project on SourceForge'.  If you think 'Site:' will be confusing then another alternative needs to be found, but I can't think of one. --HappyDog 02:35, 5 September 2006 (UTC)
 * I too find Site sub-optimal (not terribly, but still a little). I wouldn't mind Project that much since first-time site users wouldn't really use that part of the wiki and I think we could easily guide them with link names (as I doubt they will start looking things up by namespace). I have no alternative to the two nor do I feel too strongly about the issue, though. --Swift 04:25, 18 September 2006 (UTC)
 * 1) The main space currently seems to be for 'stuff that doesn't fit elsewhere'.  However this ends up muddling documentation (e.g. 'What is MediaWiki') and development items.  We should probably separate these out. --HappyDog 13:59, 13 August 2006 (UTC)
 * Are we looking at an empty Main namespace? This site is supposed to centralize informaiton on the MediaWiki software. So far we've delegated the manuals and extension to namespaces, so what's left? Lists of MediaWiki implementations? Doesn't sound too exciting. --Swift 04:34, 18 September 2006 (UTC)
 * As I mentioned in a tangent discussion in, might this actually be useful for the developer's part of the site? I think it would fit well to HappyDog's main page proposal; the Users' hub would be mainly in the Help namespace, The System administrators' in Manual and then the Developers' in the Main. The few things listed in the hub box (Roadmap, Submitting a patch and Reference manual all fit fairly well with the Main namespace contents listed in Project:Namespaces (Well the second one is a bit more on the Manual side, but I don't think it'd break anything). --Swift 17:10, 18 September 2006 (UTC)
 * 1) Are there other namespaces that would be useful - e.g. 'extension'? --HappyDog 13:59, 13 August 2006 (UTC)
 * 2) *Extension namespace
 * I've been thinking for a while that an extension namespace is almost essential. I am glad you suggested it. --HappyDog 18:27, 4 September 2006 (UTC) forgot to sign... date is wrong
 * 1) *Others?

Main  default namespace could in my view hold all documentation such as technical documentation about any aspect of MediaWiki and any extensions, skins or development stuff. I see no reason to maintain a Manual: or Extension: namespace. The site is after all about the MediaWiki software. Public domain Help (for the basic generic site user help) could be the only place outside of the main namespace for documentation. Simplicity is more maintainable, less broken. Just a simple idea. Easier, too. More about this at Manual:Flat namespace. --Rogerhc 17:57, 18 September 2006 (UTC)


 * As useful as the flat namespace is, the search feature for specific groups of pages is very useful. The one-level "hierarchy" of prefixing some pages with a namespace does not hinder them from being just as easily interlinked from pages in other namespaces.
 * I think we will have very distinct user groups (users, admins and devels) who will be looking for information specific to them (the same person may be in all of these groups, but only in one at a time). With a search for "styling" user would look for how he styles content, an admin could be searching for stylesheet locations and developer might be trying to locate where the stylesheets are defined in code. Seperating these in namespaces would make the search feature that bit more powerful. --Swift 18:32, 18 September 2006 (UTC)


 * On top of that, I think it is conceptually important to separate the different types of information. Here is the namespace structure as I currently envisage it:
 * Help: - Public domain user help
 * Manual: - Reference material - hard facts about MediaWiki (for all target audiences).
 * Site: (currently Project:) - Information about this website, or discussions about maintaining it.
 * Extension: - Third party code.
 * somewhere - Volatile or 'in progress' information (road map, markup spec development (though this will be moved to Manual when 'complete'), draft proposals, etc.
 * The namespaces help to make clear the following important distinctions:
 * PD vs GFDL (Help: for PD)
 * Official vs 3rd Party (Extension: for 3rd party)
 * MediaWiki vs MediaWiki.org (Site: for MW.org)
 * Information vs Speculation & WIP (Manual: for information)
 * ...which is why I think that these namespaces are important. It seems likely that the 'somewhere' referred to above will be the main namespace, otherwise that will be empty.  However, I find it a bit odd for the "main" namespace to be for "stuff that doesn't fit elsewhere" (which is what I meant by "still haven't found a sensible purpose for it" in the manual front door section, above.) --HappyDog 21:01, 18 September 2006 (UTC)


 * I agree that the the Main namespace shouldn't just be the dustbin for bastard pages. How about my suggestion for development stuff as laid out in Project:Namespaces? This site is mainly about the software so it fits fairly logically that the main namespace is dedicated to its development. --Swift 23:06, 18 September 2006 (UTC)

PD Help Pages
What is the exact purpose of these - how will they be used? I think it is pretty well understood by the people who have been here for a while that this is supposed to be a set of default help pages that can be included in MW distributions. However, (for example) Help:FAQ contains information about installing MediaWiki - this clearly shouldn't be in the user help FAQ. --HappyDog 13:59, 13 August 2006 (UTC)


 * Ultimately, we are going to need to divide the documentation into two clear portions, administration, and end user. They can both exist in the same location, although only the latter would need to be bundled into the distribution files, however that will be done. The current FAQ is rather biased towards the site owner/administrator, whereas it is viable that we could have an end-user oriented FAQ too, e.g. "how do I create new pages" etc. This example also brings up the issue of crossover; we might mention the InputBox extension, or the value of $wgGoToEdit, but those are administrator's issues...oooh, fun fun fun. 86.134.116.228 14:42, 13 August 2006 (UTC)

article tab label "help" in Help namespace is nav trouble
The "help" tab (article tab) at the top of every Help namespace page does not go back to Help:Contents but rather to the specific help article being displayed. This will confuse some people trying to find their way back to Help:Contents. So I put a link "<- back to Help Contents" at the top of the Template:PD Help Page. I am not set on this as the solution but rather as one worthy of looking at in action. And looking at it in action I note it also displays on the Help:Contents page itself which is unfortunate. Let's leave it there for a while so that we can look at it and think about it, before we delete it. This site is an online work in progress and will frankly always be. So I plunge ahead as gracefully as I can. Ideas?

Another solution might be to change the article tab in the Help namespace to "article" instead of "help". I don't know how to do that myself. So I offer the template as a possibly temporary solution till the article tab in the Help namespace can be changed to something less navigationally problematic for folks than "help".

Ideas?

--Rogerhc 06:20, 5 September 2006 (UTC)


 * The tab text can be changed if desired, using a message, but I'm confused as to what the problem is that needs to be solved...? robchurch | talk 12:01, 5 September 2006 (UTC)


 * Also, bear in mind that when people import the PD help pages into their own wiki (as is the ultimate aim) their 'view article' tab will (by default) be labelled 'help', therefore fixing the 'problem' here will not help on all the other wikis where this content will be used. I do agree that 'help' is misleading though. Just like at the top of this page we have 'project page' and not 'project', I think that it should be 'help page' and not 'help'.  This is probably something to change in SVN as well, if people agree. --HappyDog 14:14, 5 September 2006 (UTC)

To help newcomers understand that the Help namespace article tab is an article tab, not a link to the top level of the Help namespace, I renamed the Help namespace article tab label to Help article. The former label was "Help" which was too easily erroneously understood by newcomers unfamiliar already with where everything is to mean a link to top level of site Help. "Help article" is clearer and more navigationally helpful. This change will migrate into CVS if it weathers the test of time here. Thanks for helping. :-) --Rogerhc 19:33, 6 September 2006 (UTC)


 * I disagree with this change, not only because of consistency with nearly all other Wikimedia wikis. Pease see my notes there. Would you also like to change "template" to "template page" and "image" to "image description page"? -- :Bdk:  19:54, 6 September 2006 (UTC)
 * "Template" and "Image" are fine. They do not compete with existing computer navigational idioms the way the "Help" tab does. "Help" is a standard menu heading in GUI programs. Look at the menu bar of your browser for example; there is usually a "Help" menu. It is top level of Help for the program. It is also already used for top level of Help for MediaWiki in MediaWiki's sidebar and so should not be reused to mean anything else. Thank you for considering my newcomer ideas regarding what works well for newcomers. --Rogerhc 07:16, 7 September 2006 (UTC)


 * Please stop making changes when we are in the middle of discussing them! As far as I can see you have not shown any evidence that 'people' get confused by the tab, and other people have expressed their reservations.  Personally, I am leaning towards your side of the argument, but do not agree with your new labelling - 'help page' is better in my opinion, and consistent with other tabs in the site.  This conversation is clearly not over yet so please stop this gung-ho approach to editing core system functionality! I'm pretty sure the be bold policy (even if it exists on this wiki) should not apply to interface elements that affect all users.  --HappyDog 19:57, 6 September 2006 (UTC)
 * I hear you. Mind I would not change anything that would do any damage. This matter needs fixing: "Help page" and "Help article" are both better that "Help" for the Help page/article tab. As you and I have both demonstrated nothing here is cast is stone and no damage is done by making this subtle and helpful change now while inviting further thought on the matter. Naming the label just "Help" in the first place was the result of someone's work in progress, likely someone who knows his way around the softwar intimately and is thus blind to the bad navigational character of the current label. Witness how Rob, who knows this software intimately, does not recognize the failing of the simple "Help" label for a navigational tab that does not go to the top level "Help:Contents". He knows it is the article tab implicitly. Newcomers don't know; the label can tell them. I am all ears now that a veteran member has reverted my change even though he tends to agree with the direction it was in. Please help us find consensus. Thanks! :-) Rogerhc 05:30, 7 September 2006 (UTC)

What is acceptable on user pages
The Project:About page is pretty clear about what is allowed and what is not allowed on the site, but we need to have a policy about what is allowed on User pages, and how we deal with things that are not 'allowed'. This policy may be a 'hands off, anything goes' approach, or a much tighter 'only stuff relevant to the project', but either way we should have a policy. Should we delete, warn about or ignore bad user pages? --HappyDog 13:59, 13 August 2006 (UTC)


 * Define "bad user page" for this purpose. Offensive, advertising or downright unrelated to MediaWiki? Just delete them. 86.134.116.228 14:39, 13 August 2006 (UTC)


 * Obvious junk (spam, vandalism, offensive material) is easy to spot and to delete. But there are many user pages created by users whose sole contribution is to create a user page, which points to their Wikipedia user page.  Is this acceptable?  What about users who give a bit of biography that does not seem relevant to MW, but is otherwise inoffensive?  What about anon user pages, or users who create a page and then blank it?
 * I don't necessarily have strong opinions about these, but I think a set of guidelines is useful. I have given up checking new user pages as I was too often faced with the dillema of not knowing whether a page should be deleted, the user should be advised that the content needs fixing, or the page is acceptable on the site. --23:49, 3 September 2006 (UTC)

Page Hierarchy
What kind of system should we use for managing site structure, particularly in the Manual: namespace? Currently, Manual:MediaWiki hooks uses sub-pages to hold its contents (e.g. Manual:MediaWiki hooks/ArticleSave rather than Manual:ArticleSave). However Manual:Configuration settings uses a flat navigation system (e.g. Manual:$wgServer instead of Manual:Configuration settings/$wgServer.

There are pros and cons of each, but I think we need to decide on a consistent method and use that throughout.

(Note - Help:Configuration settings and related pages will ultimately be moved to the Manual: namespace... once this decision has been made...) --HappyDog 13:59, 13 August 2006 (UTC)
 * ...this has been done, it appears, without this issue being resolved... --HappyDog 23:49, 3 September 2006 (UTC))

See also Manual:Flat namespace

Hook documentation
split off from Page Hierarchy

Not sure how different versions of hooks should be handled. Since subpages were already being used for hooks, I moved the old (MW1.4-1.5) documentation to Manual:MediaWiki hooks/ArticleSave/1.5 and put the current documentation, along with a link, in Manual:MediaWiki hooks/ArticleSave. Not sure if there is a better way to handle this, as ArticleSave, in particular, has changed significantly both in terms of where it is called from (Article in 1.6-1.8, EditPage in 1.4-1.5) and which parameters it takes (certain params for 1.4-1.6, different for 1.7-1.8). Moreover, since people are going to be looking for information for a specific version, I believe it's best to present them with one page that displays all the relevant information, instead of a page that displays all the relevant information as well as non-relevant information. Thoughts? I'll refrain from doing any more of the same until I hear back. Thanks, —dto 04:31, 5 September 2006 (UTC)


 * This will become very unweildy very quickly. Once precedent has been set there will be a new page created for every change, where in most cases a line such as 'the $flags parameter was introduced in v1.7' would suffice.  Additionally, people using hooks are people writing extensions.  They will need to know what versions of MediaWiki their extension will be compatible with.  Seperating the information like this is contrary to this common usage, so I don't think your argument for separating them out holds water.  The main infobox should describe the behaviour in the latest version of MW, with large changes noted in a dedicated section in the body of the page and small changes detailed where relevant in the text. --HappyDog 04:40, 5 September 2006 (UTC)
 * ACK -- :Bdk: 05:42, 5 September 2006 (UTC)


 * OK...I guess I didn't really think it through because I haven't really had to care about past versions. You may delete Manual:MediaWiki hooks/ArticleSave/1.5; sorry for the proof of (bad) concept. I had to do quite some research in updating Manual:MediaWiki hooks/ArticleSave, but I know I won't be willing to dig into REL1_4, REL1_5, REL1_6, REL1_7, and trunk in the future. I sincerely hope that nobody is using 1.4 or 1.5. People who don't have php5 are stuck with 1.6, although support for that will probably? drop when 1.8 is officially released. Most people should be on 1.7. Some are on 1.8. So—what should be documented? —dto 05:16, 5 September 2006 (UTC)


 * According to experience wikis with MediaWiki 1.3 and also 1.4 are already very rare, but there are still several (not less) wikis using MediaWiki 1.5.x. So in general REL1_5 is what the information should go back to at the moment - if possible and if someone knows. (Also good, when someone also knows older stuff.) -- :Bdk: 05:42, 5 September 2006 (UTC)


 * I would say that ideally ALL versions should be documented, starting with 1.1.0! *grin*   The more pragmatic answer is: latest version at time of writing but don't delete out-of-date info if you're updating - refactor it.  The important thing is to clearly state what has been checked, to stop others duplicating effort.  For example, using a Diff tool and comparing the source, I have ensured that all hooks are present on the hooks list, up to 1.6.6, and have said so on that page.  No-one ever needs to go back and look at those old versions again.  Similarly, configuration settings are done up to 1.4.0 (although I haven't documented that - it's still a work in progress...).
 * One important point - don't document stuff that has not had an official release yet. Code in SVN that has not made it into a release version should not be documented until it does, and by released I mean packaged in a zip file and available on SourceForge. --HappyDog 06:06, 5 September 2006 (UTC)


 * Point taken. —dto 21:32, 5 September 2006 (UTC)

MW Screenshots - Image license
Currently screenshots of the MW software which are used in the PD help namespace (and maybe elsewhere) have been marked as public domain (e.g. Image:M-en-sidebar.png). Is this correct? I was under the impression that screen shots used in this way come under 'fair use' rather than PD. If this is the case, are we able to distribute them as part of the PD documentation? I am sure that the WMF would be happy to release these screenshots into the public domain if necessary, but if this is the case we will need a concrete statement that they have done so, rather than an arbitrary PD tag which may not be legally enforcable. Or maybe this is just a fuss over nothing... --HappyDog 13:59, 13 August 2006 (UTC)


 * Wikimedia don't own the blanket copyright on MediaWiki, so they can't actually do that anyway. The copyright of MediaWiki is owned individually/collectively by all the contributors, who licence their contributions under (at least) the GNU General Public Licence.


 * It's probably acceptable if we say the images are GPL, but I'm not sure on that point, and I'm not a lawyer. 86.134.116.228 14:38, 13 August 2006 (UTC)


 * PD Help does not need to contain any images. To avoid unnecessary licensing problems it may be best to simply not include any screenshots in PD Help. --Rogerhc 03:55, 15 August 2006 (UTC)


 * That might be the best option. It also avoids us having to include the images in the distribution bundle, should we ever package up a set of the pages. robchurch | talk 10:33, 17 August 2006 (UTC)


 * True, but the images can add a lot to the pages and I think it would be a shame to lose them. It would be good to know the legal status though before discussing other merits/drawbacks, as that will obviously have a big impact.  --HappyDog 23:49, 3 September 2006 (UTC)

Action
Who has the authority to set the needed policies mentioned on this page? Action is needed. --Rogerhc 06:02, 15 August 2006 (UTC)


 * What do you mean authority. Nobody has the authority to decide any of this on their own - that is the point of opening up the discussion.  Of course, anyone who has the technical ability has the authority to 'just do it' and then deal with the consequences (if there are any) afterwards, but it would be better to get some kind of agreement on the key issues, if that is at all possible. --HappyDog 23:49, 3 September 2006 (UTC)

Extension namespace
So, given that I'm shifting documentation for the extensions I've written to this site, I thought it might be worth us having a namespace dedicated to pages regarding extensions to MediaWiki.

Thoughts? Should we limit it to extensions in Subversion or allow people to provide documentation for other extensions here? Should we define an "extension" as a plug-in file, or broaden it to include hacks and patches to the software? If we do the latter, should those hacks be vetted to ensure they aren't going to damage people's installations? robchurch | talk 10:32, 17 August 2006 (UTC)
 * For simplicity, extension documentation could go in the "Manual:" namespace and be categorized Category:Manual, Category:Extension and Category:Name of the extension. Simplicity is more maintainable than complexity. However, it wont bother me if there is an "Extension:" namespace as long as someone sets forth a coherent site structure and represents it clearly in the left sidebar and on relevant policy pages. --Rogerhc 23:55, 17 August 2006 (UTC)
 * I would disagree with respect to putting it in the Manual namespace, given that extension code isn't part of the core code, and shouldn't be documented there as if it's commonplace. robchurch | talk 02:51, 30 August 2006 (UTC)
 * OK. Then I'd like to see
 * extension documentation go in an "Extension:" namespace and each extension have an Extension:Its name intro page and Extension:Its name/subpages
 * and an Extension:Contents page, or even better a Category:Extension page, to be mediawiki.org's front door to the topic of extensions.
 * and each page about extensions could be categorized Category:Extension and Category:The extension's name which should be a subcategory of Category:Extension.
 * and Extension:Contents or Category:Extension, whichever we use as extension topic front door, be a link in the mediawiki.org's left sidebar so that the structure is transparent and simple for all to navigate.
 * Please comment... Thanks --Rogerhc 03:52, 30 August 2006 (UTC)
 * All of this sounds very good to me. I think it is _vital_ that official MediaWiki documentation is kept separate from any third party code, including extensions and hacks.  Whether we should include hacks on the site is a delicate matter.  If we set precedent with a set of 'accepted' hacks then we open the door for a lot of untested or highly specific hacks, and that may be damaging both to the trustworthiness and the usability of the site.
 * However, extensions should definitely be included, and in the manner detailed above. I would add to this that there should be a standard 'extension' template that sits on the main extension page, containing a core set of details and that this is a requirement for the extension to be included on this site.  This should include author, status (stable/experimental/unmaintained/etc.), latest version/release date, requirements (MW versions), etc.
 * We need to decide whether extensions need to be (a) stable and (b) released before being included in the site, or whether we also allow extensions that are in the first stages of being designed - something that might be useful to aid collaboration and avoid duplication of effort, but which might be less useful for administrators who wish to use the extensions (mind you, a 'stable extensions' category would probably solve that). --HappyDog 23:49, 3 September 2006 (UTC)

Yes, NS Extension: is pretty ok and reasonable. And don't worry about different pages in this namespace. It should be no problem for us to develop some good templates that mark extension documentation of different quality or reliability, and also a category system for questions like "stable/instable/only for MW 1.5.x/test/chancy/outdated". I think we should definitly adopt the infobox system for all that stuff - even if I don't like most of the Wikipedia boxes *g* ... that would allow users to see at first glance, which status an extension has regarding to version/stability/maintenance/requirements/contact/whatever. And a _very_ clear labelling, especially for instable or unchecked extensions, should prevent complaints.

In general and according to scheme of the rest of Project:Namespaces the extension namespace should, as Rob noted above, also include smaller patches or so, not only that what one would normally call a "real" or "full" extension. This would also be one step to make mediawiki.org what it is intended to be: The first address regarding MediaWiki :-) -- :Bdk: 01:51, 5 September 2006 (UTC)

Who should be allowed to edit
(split from bdk's comment under 'Extension Namespace', above) Another question we're coming closer to now, is the one of open editing on this wiki. In my opinion we should either make this wiki at least closed for anons (IPs) to ensure higher trustworthiness of edits and/or to prevent too easy vandalism of e.g. small pieces of extension code, css for skins or such, that people have to copy directly, or we should go another step forward and allow only users with an authenticated email address to edit this wiki. I know, this is a loooooong discussion ... hm, the best solution I can think about at the moment is to let some pages, for example the help namespace, and the Sandbox, completely open for editing, but to restrict the rest ... well, this better goes under an own heading soon ;-) -- :Bdk: 01:51, 5 September 2006 (UTC)


 * OK - is that soon enough... :)
 * I think the first thing is to set down the problem(s) we are trying to solve by restricting who can edit. If it is to stop vandalism, restricting to registered users might be OK.  If we want some editor accountability (e.g. for extension uploads) then we need to have a valid e-mail.  Can you give some more detail about what we are trying to acheive in this area, Bdk?
 * Also, what technological tools do we have to prevent edits?
 * Edit whitelist (does this take wildcards - that would allow only Help: namespace to be editable, for example - although, as far as I am aware, any page here is fully editable by _all_ users, so no fine-grained control).
 * Page protection/semi-protection (has to be turned on for each page that needs protection, can't stop page creation).
 * Group rights (can restrict what anons/non-verified users can do, but it is across the board - no page/namespace-level control).
 * Interesting that you are essentially requesting the ability to restrict access to individual namespaces at the group level. This type of request often turns up, and is refused by the developers on the grounds that it is 'unwiki' and 'not required by WMF', yet here is a perfect use-case! --HappyDog 02:30, 5 September 2006 (UTC)


 * Hmm, yes ... but not much to say in detail yet. I hope for relevant improvements regarding this issue in 2007 (not earlier). And just a sort of a quick note: bug 2073 may be interesting. -- :Bdk: 12:36, 2 October 2006 (UTC)

A Wiki Of Multiple Hubs
The more I think about this site, the more I think that it should be organised around a set of hubs. Ideally, the left navigation would use some javascript to show a menu specific to the area of the site you were looking at, with each hub having a separate box which is collapsed by default if you are in a different section, although that might be asking too much...

I see the hubs as follows:


 * 1) MediaWiki Users - for editors and readers - the people who actually use the software.
 * 2) Wiki Administrators - for people who install/maintain a MW wiki (not to be confused with user who have 'sysop' status).
 * 3) MediaWiki Developers - for people working on the mediawiki codebase, or writing extensions/hacks.
 * 4) Third-Party Extensions - a hub for all third-party code.
 * 5) MediaWiki.org - a hub for people working on this website, to co-ordinate activity and describe policy, etc.

These naturally fall into the existing namespace structure quite well, with the exception of the 'Developers' group, although this could stay in the main namespace (despite perhaps being confusing to visitors).

Anyway - this is kind of an open thought at the moment, and needs some input from a few other brains before going any further. Thoughts? --HappyDog 23:49, 3 September 2006 (UTC)

Off-site link icon
All off-site links, including to Wikipedia.org, should display the off-site link icon. Not doing so causes confusion about which site is which for newcomers. This could be accomplished by writing such links using their full URL in the wiki markup instead of the shortcuts. However, it would be better to style the shortcut CSS declarations to display the off-site link icon. Could someone please do this? (For example, About this site contains links to Wikipedia.org articles without any indication those are off-site.) --Rogerhc 20:04, 6 September 2006 (UTC)
 * Have you ever heard about interwiki links? Please note the different blue and _please_ stop trying to change the whole site according to your whatever understanding. The administrative side of MediaWiki (≠ the use of Wikipedia or other wikis by "normal" users) is not primarily intended for absolute beginners. -- :Bdk: 20:15, 6 September 2006 (UTC)
 * Plus, to be honest, I don't think that most people who come here looking for information really care where that information is, so long as they can find it easily. --HappyDog 20:25, 6 September 2006 (UTC)
 * This Template:meta gives me an idea:
 * why not code mediawiki.org's CSS so that each interwiki linkable wiki's icon automatically displays on interwiki links to it? (The icons might cause unsightly line height increases when used inline though. So maybe not a good idea.) So maybe one simpler and less high interwiki link icon, maybe two chain links or something, closer to the size of the off-site link icon could be used. Do you guys know where such things are discussed regarding MediaWiki CSS suggestions (I don't)? --Rogerhc 05:14, 8 September 2006 (UTC)

Project:Support desk Structure idea
Hi. At the Project talk:Support desk I suggested a way to structure the process of support. Feel free to move it here if this is the appropriate place. --Rick 03:14, 29 September 2006 (UTC)