Topic on Project:Village Pump

Restructure (or: Document how it was and execute it)

Krinkle (talkcontribs)

Over the last months I've experienced getting more cluttered, different kinds of content being mixed. As a result I find that things are harder to find and more separated than they should be. Also causes more confusion and potential duplication.

I attempted to get a good overview of what is currently on this wiki which I'd like to use as a starting point to see if there's anything that shouldn't be on this wiki, or things that should be more separated away.

Check out User:Krinkle/Content structure, and links from there.

For example, there is MoodBar (WMF Project page, with /status, /Design etc.) and Extension:MoodBar (Documentation for end-users). However this distinction does not exist for ResourceLoader, which I think is a problem. I'd like the WMF project related stuff to be separated from the documentation about the feature.

Also documentation in general is getting worse and more decentralized at a rapid speed. Are we going for auto-generated documentation ? Or not. If so, do we want this to go into wiki pages and be editable on the wiki, or perhaps as an extension through Special:Documentation ?

The documentation thing is kind of a separate project though, more on that at Requests for comment/Documentation overhaul

Varnent (talkcontribs)

I would support a discussion on this and would be willing to help with any concept development or eventual implementation. It's clear this is a topic which needs to be addressed on some level - this seems like a reasonable way/place to start.  :)

HappyDog (talkcontribs)

Given the subject, it's ironic that your policy proposal has been placed in the user namespace, rather than the project namespace!  :-)

I agree that there are big problems at the moment. Thanks for categorising the current state-of-affairs. It's a good starting point for discussion. I want to check that you've seen Project:Namespaces, which gives an overview of how things were originally set up. I think that the current namespace structure pretty much holds, and the problem is that we are seeing drift caused by a couple of factors:

  1. There is a lot more drafting and discussion about work-in-progress happening here.
  2. Stuff relating to WMF deployment/servers/meetings/etc. and features that are predominantly for WMF purposes used to be documented at Meta, but are now being documented here.
  3. New stuff is added to and changed in the software all the time (hooks/settings/features/etc.), but the documentation on this site is not often updated (or if it is, it is not done thoroughly or well).
  4. When I first structured the site, a number of years ago now, the focus was nearly exclusively on documenting the existing software, so it was pretty clear where things should go. However, it is not so easy to compartmentalise things now - it is harder to know whether something is considered 'developer discussion' or 'documentation' - so people don't know where to put things. The majority of new material now seems to be planning for future software. Planning (under the current structure, at least) is something that belongs in the main namespace, but is all-too-often placed in the User or Manual namespace. However, once the feature is implemented there are parts that should be moved into the Manual (documentation) namespace, and parts that should stay where they were. It is not always clear when or how these should be moved, and in general it doesn't happen.
  5. There are very few people who are actively maintaining the site, and those that do either don't have the knowledge, or feel that they don't have the authority to move or refactor things, particularly when content is coming from sources that are pretty god-like in the developer community (but who may know nothing about how MW should be structured, and care even less). So even if it is clearer where things should go, the bit-rot is still likely to set in unless there are more hands to the pumps. A clearer policy would help with this.

Just my initial thoughts - thanks for opening up the discussion.

Reply to "Restructure (or: Document how it was and execute it)"