Project:Current issues

From MediaWiki.org

Jump to: navigation, search
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)

See Project:Current issues/Archive for some archived discussions.

Contents

[edit] Decided Issues

Some issues have either (a) been decided or (b) not been objected to in previous archived discussion, so therefore I am proposing the following actions. If there are no objections to these by the 31st October 2006 then I will go ahead and implement them or add them as policy, as appropriate (though bear with me if they don't all happen on 1st Nov!). Any decisions reached on this page that are not listed below have already been implemented/acted upon (or required no change) --HappyDog 19:32, 14 October 2006 (UTC)

A request has been logged at bugzilla:7778

[edit] Namespaces

(see Project:Current issues/Archive#Namespaces)

  • 'Project:' namespace will be renamed 'Site:'
    • Initial request refused by Brion - discussion ongoing.
  • A new 'Extension:' namespace will be created. DONE --HappyDog 09:40, 27 November 2006 (UTC)

[edit] Languages

(see Project:Current issues/Archive#Languages)

  • Policy: All pages with no suffix should be in English.
  • Policy: All other languages go in an appropriately named sub-page of the main article. E.g. the French version of Help:Contents goes in Help:Contents/fr.
  • This is compatible with the import/export of Help data (see Automating help page export)
  • The above has only properly been decided for the Help: namespace. Discussion about other namespaces is ongoing, below.

This has all been written up at Project:Language policy. --HappyDog 01:19, 3 December 2006 (UTC)

[edit] Other

These have not been discussed, but are hopefully non-contentious. They need developer input, so I want to request them at the same time as the namespace changes, above, which is why I am rasing them here. --HappyDog 19:32, 14 October 2006 (UTC)

  • Enable the import functionality for administrators (this will be required when to import data from meta).
    According to Werdna at #wikimedia-tech both have been enabled. Lcarsdata (Talk) 12:27, 28 October 2006 (UTC)
    According to Special:Import: "No transwiki import sources have been defined and direct history uploads are disabled.", so perhaps the feature is enabled, but no sources are defined? --HappyDog 13:28, 30 October 2006 (UTC)
    DONE --HappyDog 03:44, 16 November 2006 (UTC)
  • Change the default search options ($wgNamespacesToBeSearchedDefault) to search in Main, Help: Manual: and Extension. (see Project:Forum#Searching the site. DONE --HappyDog 09:40, 27 November 2006 (UTC)

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

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)

[edit] What is acceptable on user pages

Moved to Project talk:Deletion

[edit] 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

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

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

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

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

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

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)

[edit] Location of content

For prior discussion see Project:Current issues/Archive#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)

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

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)

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)

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

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

[edit] 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.
    • All redirects from the main namespace into the template namespace have now been deleted. Please let me know if I missed any. --HappyDog 17:34, 12 December 2006 (UTC)
  • 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)

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

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


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

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

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

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

[edit] Bugzilla logo

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)

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

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)

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)

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

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)
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)
50 pages imported? That must have taken ages! Well done, and thanks for your fantastic work. --HappyDog 11:36, 4 May 2007 (UTC)

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

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)
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)
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)
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)
Think I have done all the above mentioned suggestions guys? -PatPeter, MediaWiki Support Team 22:05, 1 March 2008 (UTC)

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

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

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)

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

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. —The preceding unsigned comment was added by Nad (talk • contribs) . Please sign your posts with ~~~~!

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

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

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

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)

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)

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

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)

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

Retrieved from "http://www.mediawiki.org/wiki/Project:Current_issues"
Personal tools