MediaWiki

Project:Village Pump/Archive 1

< Project:Village Pump

2006

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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. {{Title|de|Tabellen}} which does the following things:

  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).

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)[reply]

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#language_links_in_one_wiki 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)[reply]
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)[reply]
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)[reply]

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)[reply]

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

Manual front door

Also contains a lot of discussion about where reference material should be located

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)[reply]

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)[reply]
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)[reply]
  1. I advocate Manual: namespace hold all the various kinds of technical documentation about core MediaWiki
  2. 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)
  3. 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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

Agree! --Swift 19:06, 24 August 2006 (UTC)[reply]
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)[reply]
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)[reply]

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)[reply]

Looks great. A good concept and a vast improvement over the curent main page. --Swift 08:33, 16 September 2006 (UTC)[reply]
This is now live. --HappyDog 01:43, 29 September 2006 (UTC)[reply]

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)[reply]
    How about "About:" --Rogerhc 04:52, 30 August 2006 (UTC)[reply]
    "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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
    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)[reply]
  2. 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)[reply]
    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)[reply]
    As I mentioned in a tangent discussion in #Manual front door, 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)[reply]
  3. Are there other namespaces that would be useful - e.g. 'extension'? --HappyDog 13:59, 13 August 2006 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]

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 {{help}} 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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
"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)[reply]
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)[reply]
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)[reply]

Hook documentation

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:Hooks/ArticleSave/1.5 and put the current documentation, along with a link, in Manual: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)[reply]

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)[reply]
ACK --:Bdk: 05:42, 5 September 2006 (UTC)[reply]
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:Hooks/ArticleSave/1.5; sorry for the proof of (bad) concept. I had to do quite some research in updating Manual: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)[reply]
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)[reply]
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)[reply]
Point taken. —dto 21:32, 5 September 2006 (UTC)[reply]

Action

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

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)[reply]

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)[reply]

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)[reply]

Site 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)[reply]

About this site? --Swift 18:36, 24 August 2006 (UTC)[reply]
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)[reply]
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)[reply]

What is acceptable on user pages

Moved to Project talk:Deletion

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: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)[reply]

...this has been done, it appears, without this issue being resolved... --HappyDog 23:49, 3 September 2006 (UTC))[reply]

See also Project:Flat namespace

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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
It seems nuts to even discuss this as a license issue. What? So the developers of mediawiki are going object to a screenshot of mediawiki appearing... in mediawiki's help documentation??? While we are worrying about that, maybe we should search the internet and write a legal complaint to anybody who is publishing a mediawiki screenshot on their blog! (That's sarcasm... don't actually do it)
A more interesting discussion is... Do we even want screenshots in the PD help? MediaWiki's import/export feature provides a very simple way of distributing text content out to other wikis, but distributing the images, is more technically tricky.
But screenshot images are a nice helpful thing to have in a help document. A middle-way might be to make sure non of our text assumes the existence of the images. So we should avoid saying anything like "as shown in the following image". That way we can distribute a simple export/import bundle without images, or something more complicated with images (for which we have no mechanism at present I believe)
-- Harry Wood 17:59, 5 November 2007 (UTC)[reply]
The site license states that any uploaded images are GFDL, which allows re-use by other sites and for other purposes. As it is possible for these images, if released as PD/GFDL. to be used for purposes that go against the goals/beliefs/whatever of the WMF/developers/whoever, it does matter what license they come under. (I'm not saying they shouldn't be free images, by the way, just that until the situation is clarified we should not be labelling them as such). The current situations is that 'no-one really knows', so all screenshots should be tagged with template:MW-screenshot to note that the copyright status is unclear. Whatever the actual license turns out to be, I have no doubt that we will be allowed to use the images on this site - it is more a matter of appropriate tagging, which this template goes part-way towards resolving (although it is not yet used uniformly...).
Regarding their use on the PD help pages, I think your amendments to Project:PD help sum up the current situation pretty well - leave what's there, but don't add more - and that until we have some kind of automated method of pushing out a complete PD help 'bundle' then this is probably the way things should go on. --HappyDog 01:26, 6 November 2007 (UTC)[reply]
Why should the interface be copyrighted by the Wikimedia Foundation? The developers wrote it. Most of us are not hired by the foundation, and I don't think those who are hired transfered their copyrights to the foundation. If the software code is GPL, the interface is probably GPL too; anyway, I see no reason that the interface will be copyrighted by the foundation. – rotemliss – Talk 15:37, 6 November 2007 (UTC)[reply]
I agree, but although this was discussed at some length on the mailing list (I wouldn't advise reading it all!) there was no real definitive resolution of the issue, hence my hesitation. In particular, even if the images are GPL (which is fairly likely, although there might be problems with certain elements, e.g. logos) we don't know whether they are distributable as part of the PD help (i.e. whether they can be PD licensed). --HappyDog 00:26, 7 November 2007 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
OK. Then I'd like to see
Please comment... Thanks --Rogerhc 03:52, 30 August 2006 (UTC)[reply]
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)[reply]

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)[reply]

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)[reply]

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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
This Template:meta gives me an idea:MetaWiki:somepage
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)[reply]

Localisation outside the Help: namespace

We seem to have agreed that non-English in the public domain help pages are stored in appropriately named sub-pages. However, the following points still need to be resolved for other namespaces:

  • Should we allow/support other languages at all, outside of the PD help?
  • Should we use the same sub-page method for handling them?

Our official policy is currently that English is the main reference language, and that only certain key pages (main page, intro, etc.) will be in other languages, however there seem to be a lot of willing and able contributors in other languages, so I see no reason to have this restriction. However we have a problem with using sub-pages for language codes - we already use sub-pages for other purposes, and this will only be expanded upon when we have an extension: namespace. From discussion, it is likely that each extension will have a main page 'Extension:MyExtension' with sub-pages such as 'Extension:MyExtension/code', 'Extension:MyExtension/Syntax', etc. for any extra information that doesn't fit on this main page. This structured method will cause problems if we also include language variants within the scheme. Thoughts? --HappyDog 19:32, 14 October 2006 (UTC)[reply]

In particular, the Sites using MediaWiki set of pages is using language sub-pages to indicate the language that the target wiki is written in, not the language the page is written in, e.g. Sites using MediaWiki/fr. --HappyDog 01:05, 16 October 2006 (UTC)[reply]


Location of content

For prior discussion see #Manual front door.

There was a fair bit of discussion about where various technical/reference/developer information should be located, but no real answer. My current feeling is that we should just let it evolve, and come back to this as and when we need to, but if anyone has any strong opinions, here is the place to discuss them. I strongly feel that there should be no bulk moving of content without discussing it first though - if in doubt, ask! --HappyDog 19:32, 14 October 2006 (UTC)[reply]

Skins

Could I request that a manual entry for writing skins be given a high priority? It seems to be one of the poorest documented parts of Mediawiki and yet conversely one of the most important for end users. --Kingboyk 12:27, 18 November 2006 (UTC)[reply]

Do you mean actual skins, or CSS modifications to skins? If you are referring to the former then I would disagree as we have MySkin which is a skin with all of the necessary functions, but without built in CSS and other skins would not be beneficial as most changes can be made using CSS. If someone wants to make specific modifications, like adding adverts, it is not very difficult. Lcarsdata (Talk) 18:33, 21 November 2006 (UTC)[reply]

Documentation on creating custom skins should be provided. If Kingboyk would like to help write it, then the help would be most welcome. robchurch | talk 04:44, 22 November 2006 (UTC)[reply]

Yes, that what I meant Rob. I would of course be delighted to help but at the moment I don't know the topic myself. I'm just getting back into Mediawiki and will be contributing to the wiki anything I learn which isn't documented, but it will be slow going (I've forgotten just about everything). In the meantime, is there any reference anywhere about writing skins? --Kingboyk 11:36, 25 November 2006 (UTC)[reply]
Hey guys. I've been digging around the MediaWiki templating system for a little while now and even though I still have to find my way in the layers after layers of subclasses to make sense of it all (php and programming newbie), I'm sure that with a little help from a developer willing to give me a few pointers, I could be of assistance here. Think you would have a little time to help me with that Rob? Stéphane Thibault 13:56, 10 March 2007 (UTC)   Talk[reply]

I think MediaWiki is excellent, but its poor design and cluttered structure (although not unusual for Wikis) discourages many users from chosing MediaWiki despite its superior functionality. This is very often considered something of minor importance, but don't underestimate it! For some reasons Wikis tries to "include everything on every page", which breaks a lot of usabulity rules. Making it easier to create skins, and making a good looking, high-usability default skin would be a great start! Thanks. //Sire

What is wrong with the current default skin (Monobook)? Titoxd(?!?) 19:05, 14 May 2007 (UTC)[reply]
What makes good design is ofcourse subjective and I mean no offence, but ask any designer, typographer or usability expert and they can probably suggest a lot of improvements on Monoskin. What strikes me first is the cluttered design (too many options!) and the oldschool look. Take a look at other large os community sites for example http://drupal.org and http://phpbb.com and they give a much more modern and professional impression. Here are some open source skins I find appealing (although the graphics need to be removed): http://www.oswd.org/designs/search/designer/id/6205/ //Sire

Moving extensions

  • All extensions have now been moved from the main namespace into the new Extension: namespace.
  • All links to these pages have been updated to point to the new locations.
  • All redirects in the Talk: namespace have been deleted.
  • Redirects in the main namespace will be left for two weeks (until 12th December) after which time they will be deleted. Please update any remote websites that link to these pages before then.
  • Work has begun on migrating extensions from meta. See meta:Meta:MetaProject to transfer content to MediaWiki.org for details.
  • Please do not add pages for extensions that already have a page on meta, they will be migrated soon (with full edit history) and if the page has already been created here then the process is more complicated and error-prone.

If you have any comments or questions about the above then please raise them here. --HappyDog 17:54, 28 November 2006 (UTC)[reply]

Database layout moved here

m:Help:Database layout has been moved here to Database layout. The page and its subpages were current as of r18603 in SVN. Titoxd(?!?) 05:59, 28 December 2006 (UTC)[reply]

Fantastic job! Glad someone has finally tackled that one - it was a biggie! ...however... these pages should all be in the Manual namespace! Before moving them, can I suggest the following structure:
Manual:Database layout → Manual:Schema
Each table to an appropriate sub-page, e.g. archive table → Manual:Schema/archive
I would like to do this soon so we can delete the redirects (I will update mw.org). Leave it too long and we'll be stuck with them! I will do the move in a week or two unless there are any objections (or sooner if there is a general agreement and I can find the time) Thoughts? --HappyDog 02:43, 8 January 2007 (UTC)[reply]
Well, I was thinking about moving the pages to the manual namespace once I updated the schema fully and documented it properly, like I did with the Hitcounter table. That said, it doesn't really matter on which namespace they're on (although I would prefer Manual:Hitcounter table instead of Manual:Schema/Hitcounter, as all the pages have {{database layout}} on top of them, and moving them to subpages would require more template voodoo), as I can work on them in both places. One question, though: which redirects are you thinking about deleting? You would need to update Meta's soft redirects as well, as they would point to dead links... Titoxd(?!?) 07:24, 8 January 2007 (UTC)[reply]
The use of sub-pages would be consistent with other sections of the manual (e.g. the parser hooks) and would give us automatic navigation back to the main schema page without the need for the ugly template at the top of the page. The redirects I was referring to are the ones that will be left behind by the move. I was planning to update the links on meta (I said I will update mw.org, above, but I meant meta) and hopefully there will be no other external links, so long as we do it pretty soon. I don't see that any 'template voodoo' would be required. Can you elaborate? --HappyDog 12:19, 8 January 2007 (UTC)[reply]
Mostly, the {{[[Template:|process header]]}} call that is being used right now on {{Template:database layout}} would need to be modified to read subpages. Although that wouldn't be necessary if the template is bypassed... Titoxd(?!?) 00:18, 9 January 2007 (UTC)[reply]
To be honest, I don't see the point of that template. With the sub-pages the link back to the renamed 'database layout' page will always be present, and because the tables change between versions, previous/next doesn't really make sense (if you intended to use it that way). Linking back to the 'technical manual' is probably not all that useful, but if it is then a standard 'technical manual' template would be better, that adds it to a category and provides some standard navigation. I personally don't think is needed, however. Even if we used the same template though, I don't see that sub-pages would cause any problems. --HappyDog 00:52, 9 January 2007 (UTC)[reply]
Mostly, because it's the one used at Meta, Wikipedia and Wikisource, off the top of my head. The link to the technical manual is temporary, until I move m:MediaWiki architecture here. Ok, move them to subpages, but I think it would be nicer (for backwards compatibilty and historical reasons) to make Hitcounter table be Manual:Database layout/Hitcounter table, instead of creating Manual:Schema and its ilk. That said, I don't see the problem in leaving the redirects around, they don't hurt. Titoxd(?!?) 03:40, 18 January 2007 (UTC)[reply]
Given that "Schema" and "Database layout" mean the same thing it doesn't really matter which we use. I chose schema because it's shorter, but if you think Database layout is clearer then I don't mind using that. Or how about "DB layout"?
Pointless redirects bug me - maybe I'm a bit OCD. If the only place that links to them is meta (which it should be, so far) then I don't mind doing the update before deleting the redirects. If you genuinely think people will type these titles in when searching then there is some usefulness in keeping them, but otherwise the only point is to stop dangling links, which shouldn't be a problem yet. --HappyDog 04:29, 18 January 2007 (UTC)[reply]
Well, at least on enwiki, many users are told to check the "revision table". Therefore, when they check here, the first thing they would type on the search box is "revision table". Personally, I'm more of a "redirects are cheap" kind of user, so I don't usually like to delete redirects unless there's a good reason to do so.
As for the name of the page, "Database layout" and "DB layout" seem equal to me. Personally, I don't like many abbreviations in titles, so we can point a redirect from one to the other. Titoxd(?!?) 04:48, 18 January 2007 (UTC)[reply]

2007

Hidden MediaWiki: Pages?

I'm the sysadmin on a intranet wiki at work and I'm trying to configure a few things on our wiki. Is there a listing somewhere of the special "MediaWiki:____" pages that set control the settings and layout of the wiki?

Soloban 13:36, 22 January 2007 (UTC)[reply]

Special:Allmessages, but without explanation.--Patrick 15:11, 22 January 2007 (UTC)[reply]

References to Bugzilla

When looking for a place to post a request/suggestion I searched both MediaWiki and Wikimedia wikis for probably an hour to no avail; then a friend on a different wiki helped me out. Shouldn't Bugzilla be more advertised, like within the help page here on the MediaWiki wiki? Not very userfriendly for new people at the moment. --Notmyhandle 03:49, 16 February 2007 (UTC)[reply]

On which Help page? There is Bugs... -- Duesentrieb ⇌ 21:48, 17 February 2007 (UTC)[reply]

Hi, not sure where to post this (as bugzilla has no talk pages) but the main page of that site should use the svg version of the bug logo instead of the png one. Thanks 129.215.149.97

No it shouldn't; SVG isn't compatible with all browsers, so this would be at best gratuitously annoying. --brion 15:29, 3 May 2007 (UTC)[reply]

Project Organization

Being new to the project, I have had difficulty finding general development information including the following:

  • Are there any documentation requirements for contributed code?
  • Who makes decisions regarding adding contributions to a release?
  • Is there any kind of review process for contributed code?
  • What is the role of the Foundation related to development goals?

Basically, I want to be effective in my contributions and not duplicate work. It seems that is a need for people simply to coordinate efforts, but for all I know this may already exist. Are there leaders in the community who claim some responsibility for maintaining information about development? --Sunergos 19:07, 22 April 2007 (UTC)[reply]

I'll try to answer, to the best of my knowledge:

  • Are there any documentation requirements for contributed code?
    • There are no requirements, though in-code documentation is highly encouraged; Doxygen compatible comments on functions and classes are also very much encouraged.
    • When changing existing functionality, you should update any documentation about it here on mediawiki.org, noting in what version/revision the change was introduced. When you introduces major new functionality, you should write on overview here on this wiki.
  • Who makes decisions regarding adding contributions to a release?
  • Is there any kind of review process for contributed code?
    • Wikipedia is running on SVN trunk, the live code is synchronized ("scaped") with development code every few days (sometimes it takes longer, especially when a change to the database schema is pending, or a release is about to happen).
    • "scaping" is usually done by User:Brion VIBBER or User:Tim Starling or another core developer, after a quick review of the changes applied since the last synchronization. Major problems are generally reported quickly by the community and fixed by developers - prepare to take the resulting heat :)
  • What is the role of the Foundation related to development goals?
    • MediaWiki's prime mission is to run Wikipedia and other Wikimedia projects. By this token, the Wikimedia Foundation and the community of the projects run by her defines the development goals. People who would likt to re-target MediaWiki development to some other goal are welcome to "fork off".
    • The Wikimedia Foundation employs two people to look after MediaWiki: Brion and Tim (both have been helping with writing and managing MediaWiki for years before the Foundation decided to pay them full time).
The best way to coordinate development and avoid redundant work is to talk to people that know the projects. Good places would be the mediawiki-l mailing list and the #mediawiki IRC channel. For larger issues, it's probably a good idea to create a page on this wiki and to point for it for further discussion / contribution. Like in a Wiki, the "leaders" in the project are the ones people listen to because they are knowledgeable. These are often, but not always, the most active contributors - so, a look at the svn log may give you a good idea who to ask when in doubt. When you have questions about a specific part of the code, look who contributed to it.
HTH -- Duesentrieb ⇌ 20:24, 22 April 2007 (UTC)[reply]

MediaWiki is a project with a defined scope, and this scope fits in rather well with the goals of the Wikimedia Foundation's software needs. In most cases, changes to the product which veer too far from this project scope will not be accepted, but not all changes have got to have potential use for the Foundation.

The Foundation itself contributes little to development other than the two salaried developers Brion Vibber and Tim Starling, whose responsibilities tend to also include systems administration and other tasks.

Code committed to the repository trunk is expected to compile and is not expected to contain any major errors - things have to work without throwing exceptions most of the time, and without puking up fatal errors - as Wikimedia uses the trunk version of MediaWiki to run its sites, and this is synchronised regularly.

If you break the code, you will usually be expected to put it right, but no-one is going to hold a grudge for a mistake made in good faith. Broken changes will be reverted, often with an explanation posted on the technical mailing list. robchurch | talk 14:04, 21 June 2007 (UTC)[reply]

Installation guides

How accurate are the pages at m:Help:OS specific help? These definitely should be here, but do we need to basically rewrite them to scratch? Or would be fine by just importing them? Titoxd(?!?) 05:01, 3 May 2007 (UTC)[reply]

There are no licensing issues, as they would be part of the manual, which is GFDL too. I can't vouch for their accuracy though. I guess the question is whether we import them as they are and let people fix them up as they spot errors/outdated info, or whether we try and get someone knowledgeable to look them over before importing. In the former case we have possibly incorrect/misleading(/dangerous?) info here (although that information is already on meta, so perhaps there's no difference). In the second we may be waiting for years before they get transferred, particularly for some of the more obscure OS's. I guess my suggestion would be to import them and add a 'needs verification' warning to the top of each page (via a template). --HappyDog 09:05, 3 May 2007 (UTC)[reply]
Yeah, I was talking about the content issues. We can always transwiki things in the Meta Help: namespace to another namespace here. I'll do that, and get around to making a "verify" tag. Titoxd(?!?) 03:09, 4 May 2007 (UTC)[reply]
50 pages imported? That must have taken ages! Well done, and thanks for your fantastic work. --HappyDog 11:36, 4 May 2007 (UTC)[reply]

Project:Support desk

Well, there have been a few relatively-old threads about reforming how we answer support questions here. Several suggestions have been raised, but because the discussion is old, it is better if we restart it fresh.

The support desk is currently not very organized. A lot of questions remain unanswered, and there is a general trend towards repetition of questions because questions are archived chronologically, not thematically. Then, we run into one of the disadvantages of the wiki model, which is not suited very well for tech support. I was looking at the Gaming Wikia, and their SiteScout extension, and maybe it would be something we would like? Also, there is DPLforum, as a different alternative. Then, there must be other options, including leaving things as-is. So, what should we do? Titoxd(?!?) 04:46, 17 May 2007 (UTC)[reply]

Hi Titoxd, thanks a lot. I'm glad you raise this issue (we have discussed it a couple of times, mainly on IRC, but without being able to come forth yet).
Regarding DPL/DPL2|/DPLforum I asked Brion already in April and his answer was pretty clear: "dpl2 -> no. dplforum -> no. dpl -> maybe". Personally I like DPLforum and how it works very much (sort of "wiki-wayish" *g*) – it would be great to have it here, but ... well, another idea would be to set up a normal phpBB forum or such under mediawiki.org/forum (or forum.mediawiki.org). Yes, I know, this sounds not very likely at the moment as the devs want to keep the main discussion concentrated to the already existing places (mailing list and IRC), and I really understand that. But I still think that it is best for the MediaWiki community to have – in addition – one centralized and "official" forum, especially because
  1. there's a fairly obvious need for a proper forum (for all those who dislike IRC and public mailing lists, or who are confused by the rather unsorted masses of wiki threads),
  2. the MW community is growing fast and it is definitely able to maintain a forum without the devs having to reply to each question personally (there are already some privately hosted MW forums around, of course),
  3. a forum solution would make it much easier to provide and establish better support for non-English users.
So if DPLforum stays being a "no-go", instead of trying to improve the current wiki discussion system here (cf. Wikipedia's Help desk: it looks well sorted, but would it really work well for our needs? for example, the archiving is a huge problem to find old threads, it also needs much maintenance), I would prefer a "real forum" solution. This will need some time to get the idea through, of course. Any comments? --:Bdk: 20:27, 17 May 2007 (UTC)[reply]
A wiki is a terribly bad choice for technical support. It is great for collaborative documents and other non-interactive uses, but it really doesn't work when confronted with situations where the reader wants to ask questions. Wiki provides content, forums provide discussion. You can use a wiki for discussion and a forum for content if you like, but then perhaps you are a fool. :-)
In short, a dedicated forum would be infinitely better than the current Support Desk page.
I guess the real question is, at what level do we want to provide technical support? Currently, it appears the answer is that nobody (unsurprisingly) wants to spend time on it. However, if someone asks a question in the right place AND in the right way, AND they manage to catch a developer's eye AND the developer happen to be in the right mood, then they might respond (if you're lucky...).
I guess the issue is too many indians and not enough chiefs... if there were enough people dedicated to answering this sort of question then it wouldn't be a problem.
A bit of history: I created Project:Support desk about a year ago, because the wiki was being littered with random queries and I thought it would be better to focus these on a single page rather than have them scattered throughout the site. At that time I got the feeling that this kind of page was unwelcome, however it was begrudgingly accepted as the lesser of two evils (the alternative being just as many questions, but all over the place). In fact, the page still reflects this with the comment at the top: "Questions on this page are unlikely to be answered very quickly, and may not get answered at all."
Personally, I don't check this page (even for vandalism) so I don't know whether this attitude has changed, but I think we need to be damn sure that we can support any such forum before we make it 'the official forum', and that if we can't a pointer to communication might be better...
--HappyDog 02:44, 18 May 2007 (UTC)[reply]
Well, #mediawiki points here as the first place to check for answers, so this is an official forum, of sorts, and I don't think we want to add more pressure to the existing channels. However, we need to figure out the way to a) get more people to answer questions, b) to better organize questions, and c) to make questions easier to ask. Currently, what happens is that about five questions are asked, someone sees them and answers three of them, but two of them remain unanswered. Then, another five are asked, a developer comes, and has to answer all seven. That's not really an ideal cycle. I've answered questions a lot of times in the Wikipedia Help Desk, but we have about fifty users regularly answering questions, and if I don't know something, someone else will, or will point to where to look. I simply don't have that kind of knowledge of MediaWiki to do that (yet ;)) but we just need more people here. Titoxd(?!?) 02:54, 18 May 2007 (UTC)[reply]
There is a difference between being the first place to check for answers and being a place to ask questions. I guess the general developer attitude is that people should be able to find the answer to their question via a few good search terms (here or on Google) and that if they can't make that effort then why should we help them? Of course, this argument fails when you actually look at the information we have here and the way it is presented. This means that any call to provide better user support falls into two categories: (1) Making our core documentation better, so that potential questions are already answered and are easy to find, and (2) answering the questions that arise from not finding/reading/understanding the appropriate docs. Solving (1) reduces the no. of (2), but it will never reduce it to zero. However most people here (in my estimation) would probably rather work at (1). --HappyDog 03:27, 18 May 2007 (UTC)[reply]
Think I have done all the above mentioned suggestions guys? -PatPeter,  MediaWiki Support Team 22:05, 1 March 2008 (UTC)[reply]

New template for MW screenshots

I have just created Template:MW-screenshot to help categorise the many MW screenshots we use on this site. It takes two arguments - one indicates the type of non-interface content (for licensing purposes) and the other indicates the skin used in the screenshot.

Hopefully this should sort out the licensing mess that these images are currently undergoing. Some are licensed to WMF, others are assumed to be under either GFDL or GPL, as that is the software license. Others assumed that as it is a screenshot it is 'owned' by the uploader, so is granted whatever license they choose (normally PD, sometimes CC-by-sa). Others have no license at all. This new template allows all screenshots to be tagged in the same way, and ultimately to be licensed correctly (once the correct license has been worked out...)

One issue I noticed as I started tagging screenshots - there are sometimes more than the expected 2 licenses to consider. Currently the template allows for two licenses: the interface and the non-interface content. However when an extension is involved, there is more than one interface to consider... possibly more than 2 on rare occasions. Also the situation could be even more confusing: Consider a WMF website being used to demonstrate an extension - we get MW interface, the extension interface, the site logo, and the GFDL content!

Anyway - this is all a bit beyond me right now. What I want is a single template that marks MW screenshots, but allows the appropriate 'other' licenses to be specified also. Maybe what I have already created is sufficient, but maybe not. What do other people think about this? --HappyDog 02:44, 19 July 2007 (UTC)[reply]

Category:MediaWiki Development

I think this category should be renamed to Category:Development, since this whole site is about MediaWiki. We don't have Category:MediaWiki extensions - it is Category:Extensions. Likewise, I think Category:MediaWiki API could also be renamed to Category:API. Thoughts on this? --Sayuri 16:04, 21 July 2007 (UTC)[reply]

It's not really about the fact that the site is about MediaWiki, but whether the category name is unambiguous. If, for example, there were several 'development' sub-categories (e.g. MediaWiki development, Extension development, Skin development, etc.) then you need to disambiguate, and the longer name is useful. If not then the shorter name is probably clearer. My broad rule is this: Is it clear to a new user who is navigating the category tree? In this case, I think 'API' is, whereas arguments could be made in either direction for 'Development', I think. --HappyDog 18:56, 22 July 2007 (UTC)[reply]

How to handle dangerous extensions?

Original conversation moved from User talk:Robchurch#Extension:Livelets

I think that's pretty damn rude to just delete an extension without even discussing it with me. I don't even see how it can have such vulnerabilities when all its doing is making a request for a page using the same session as the main page. --Nad 01:39, 24 July 2007 (UTC)[reply]

I've done a lot of work on that extension, and it's in active use on all our wiki's, are you going to nuke any others? I've been using this wiki as the place for instructions and discussion of all my extensions, but this incident makes me feel like moving them all off onto organicdesign where admins can't just nuke them as they choose. At least give me the content of it so I can move it onto my wiki. — Preceding unsigned comment added by Nad (talk • contribs)

What were all the pages? Aaron 01:56, 24 July 2007 (UTC)[reply]
Extension:Livelets and it's talk page --Nad 03:08, 24 July 2007 (UTC)[reply]

Undeleted, because I can't be bothered to argue. robchurch | talk 10:02, 24 July 2007 (UTC)[reply]

Currently we have no criteria for inclusion/exclusion of MediaWiki extensions on this site. Until we do, all extensions should be welcome. Dangerous/incomplete/buggy extensions should be clearly marked as such, but should not, in my opinion, be deleted. It might be worth opening up the question of what types of third party code we allow here. E.g. for example, should we allow code hacks? There are quite a few on meta that will end up here if we don't make policy first! As someone who feels strongly about this, perhaps you should get the ball rolling... :-) --HappyDog 16:22, 24 July 2007 (UTC)[reply]
I would have happily moved it back onto my own site if asked, I just found it really bad form to just have it nuked without even a word. I don't even understand why it's a security problem, other extensions including wikipedia itself uses ajax. The SWF part is intended to be optional, and isn't even developed yet. I think its a very useful extension to be able to transclude templates using ajax and I use it in many wiki's. --Nad 00:09, 25 July 2007 (UTC)[reply]

I deleted various extensions which were marked as vulnerable, checking a few. I am of the opinion that we should not knowingly allow broken and/or dangerous code to remain publicly accessible from this web site, since it often constitutes some sort of misapplied endorsement. However, I'm not in the mood to get into a fight about it. robchurch | talk 16:34, 24 July 2007 (UTC)[reply]

Why isn't there a separate 'community extension' namespace to handle this? Put the appropriate disclaimers etc. I believe that the policing task of going through each extension one-by-one would be a tantamount one. Jean-Lou Dupont 17:41, 24 July 2007 (UTC)[reply]

There is - the Extension: namespace. It does not have disclaimers because (as far as I know) we can't have namespace-specific header text. However, it might be something we could (should?) incorporate into Template:Extension. --HappyDog 00:01, 25 July 2007 (UTC)[reply]
Yes of course but I thought I had seen some extensions in there maintained by the WikiMedia crew; so, this fact prompted my suggestion i.e. separate what is maintained for the official MediaWiki from what the community at large contributes. Jean-Lou Dupont 00:37, 25 July 2007 (UTC)[reply]

End of copied discussion

The above raises some good points, and it is clear that there is some desire to either block or clearly label any extensions that might be dangerous. Given that there is no way to do either of these items automatically, the assumption should perhaps be that all code posted to the site is dangerous until proven safe.

Of course, we might be able to offer some guarantee of safety, e.g. if they are in the mediawiki SVN repository, are we able to vouch for them? If so then we should definitely use this to either mark them as 'safer' or mark others as 'less safe'.

But who do we offer SVN commit access to? If it is not wide-open to extension developers then it seems a little unfair if we made that a requirement for inclusion on the site. It would also cause problems with a large number of the existing extensions being marked as 'unsafe' even though they are well tested, or very simple, and offer no real threat at all.

The main points of discussion:

  • What is allowed on the site. Do we post any restrictions to the content of the extension namespace? E.g. Is a code hack that implements some otherwise impossible function acceptable? What about a code-hack that works but which could be better accomplished as a proper extension?
  • If we place any restrictions on what types of extension code are allowed, then how do we enforce them? There are not many people who have both the time and knowledge to install and test every extension. And even if it is tested, how do we know that they didn't miss anything?
  • If we place no restrictions (or our restrictions are not fully enforceable) how do we protect ourselves from any liability? We can add a bit disclaimer to Template:extension easily enough, but it is possible for pages to be added without the template, and in the interim period between someone fixing this, there is no disclaimer. Or we add it to _every_ page (even if not an extension page). I don't think we can set different messages per-namespace at the moment.

Anyway, this needs a fair bit more thought and I'm a bit tired right now (as you might be able to tell...) - these are just some brain dumps to see what suggestions people have. --HappyDog 00:37, 25 July 2007 (UTC)[reply]

Database table page standardisation

Currently the different pages detailing tables in the database (e.g. archive table) all use a different layouts. Therefore I am proposing we standardise the basic features of these pages. While pages should certaily 'be themselves' it would be nice for basic information on each table. To help stimulate ideas I have started a planning page, and it is hoped that once ideas are setlled on this could be implemented. MinuteElectron 19:21, 13 November 2007 (UTC)[reply]

Retrieved from "https://www.mediawiki.org/w/index.php?title=Project:Village_Pump/Archive_1&oldid=5449967"