Project:Village Pump/Archive 2

__NEWSECTIONLINK__Forum | Current issues

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

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

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

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 7778

Namespaces
(see Project:Current issues/Archive)
 * '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)

Languages
(see Project:Current issues/Archive) This has all been written up at Project:Language policy. --HappyDog 01:19, 3 December 2006 (UTC)
 * 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.

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. DONE --HappyDog 09:40, 27 November 2006 (UTC)

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)

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

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)

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

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

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

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

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


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


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

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

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: 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)
 * Should we allow/support other languages at all, outside of the PD help?
 * Should we use the same sub-page method for handling them?


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

Location of content
For prior discussion see Project:Current issues/Archive.

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)

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) [[Image:Nuvola_apps_edu_languages.png|15px]] Talk

Moving extensions
If you have any comments or questions about the above then please raise them here. --HappyDog 17:54, 28 November 2006 (UTC)
 * 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.

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 &rarr; Manual:Schema
 * Each table to an appropriate sub-page, e.g. archive table &rarr; 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 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 call that is being used right now on  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)

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)

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)

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

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?
 * The release manager, i.e. User:Brion VIBBER with the help of other core developers, like User:Tim Starling.
 * 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)