Project talk:Flat namespace

Discuss Project:Flat namespace

---

Agree

User:Rogerhc wrote this page single handedly (so far at least), but I agree with it. I think people with experience of coming up with wiki structures will eventually gravitate towards these ideas, while others will try to force a heirarchical structure into wiki page names. If you use subpages or even namespaces, on the face of it this can seem like it is working well, but you have lost a crucial level of simplicity. In a very subtle way you have shot yourself in the foot. -- Harry Wood 17:39, 12 February 2008 (UTC)

About mediawiki.org ?

I think this page was intended to be related to structuring MediaWiki.org itself, and proposing a change perhaps. But it could work as general advice I think (then it should move to the 'Main' namespace??).

Regarding mediawiki.org I think it was a bit of a mistake to create a namespace 'Manual' on this site. The difference between what goes in Manual and what goes in Main is not clear enough, and the most helpful (but messy) thing to do in many cases will be to create redirect from one to the other. Would've been better to build the manual in the main namespace ...but it's too late to fix it now really.

-- Harry Wood 17:39, 12 February 2008 (UTC)

No. It was not a mistake. If it is not clear enough to newcomers then that is something we need to address, but to people who have been here for a while it is, I think, quite clear. I acknowledge that part of the confusion is that no-one has yet made a concerted effort to move rogue pages, e.g. Project:Support desk, Help:User rights etc. --HappyDog 13:30, 18 February 2008 (UTC)

I have now moved Help:User rights which was one of the big ones, and we also have Project:Namespaces, which makes it clear what's supposed to be happening here on mediawiki.org . Kind of ironic that this page is in the wrong namespace though hey? :-) -- Harry Wood 08:57, 23 May 2008 (UTC)

Yes and No

Hierarchy is another word for organization; it's also another word for complexity. There are costs and benefits.

A jet airliner is considerably more complex than a bicycle. It takes longer to learn how to operate one and operation is more demanding of the operator. There are more systems to fail and more failure modes per system. Repair is relatively difficult and expensive. The infrastructure required to support is significantly greater.

However, the plane is generally more capable than the bike. It goes farther, faster, across more varied terrain. It carries more passengers and cargo. Few would suggest that all planes be replaced by bikes.

Key to the success of the jetliner is technical discipline. Like "art", this is difficult to define but easy to know. It is not simply technical expertise; it is the exercise of that technique in a disciplined fashion. Engineers, technicians, operators, users, and even those persons who contribute to the system tangentially -- such as rental car clerks -- all conform their work to the technical demands of the system. An overriding commitment to a certain level of reliability and usability permeates all related work. Standards and conventions are explicit, current, and distributed to those who must conform to them.

To an extent, wikis often seem to me like airlines run by poor, illiterate, non-Westerners. Sufficient elite have the technical background to make them run but the total workforce is not up to speed. So, the wikis, like the planes, crash and suffer from maddening delays and unexpected inconveniences and inconsistencies.

The solution to the banana republic airline is more training and, even more importantly, diffusion of the technical ethic. It's difficult -- more difficult than may be at first entertained. It's easy to educate a small elite; the larger group of workers and users presents exponentially greater challenges. Yet still, we do not suggest that they abandon planes in favor of bikes.

To overcome this challenge in a wiki may be even more difficult. The bar to participation is deliberately low, even in an enterprise installation. Because the dollar value of the investment is not obvious, leaders may not be as willing to commit the significant resources required to bring a wiki up to professional standards. In some public installations, leaders lack effective leverage -- rewards and sanctions to encourage participants to conform. These wikis are out of control.

The ability to create a http://www.essaylib.com/persuasive-speech.php persuasive speech is crucial to any individual who strives for success in any field of life and business. This ability is important everywhere, not just through your education.

Still, I say, we should forge ahead with wikis, rather than stall their development at some simple idiot level. We must consider the importance of navigation, structure, templates, and categories. These unsexy tasks cannot be allowed to fall behind content growth. Only by paying the costs of complexity can we enjoy the benefits without our steel falling from the sky. →Xiong 07:17, 21 May 2008 (UTC)

A wiki's value lies in the information, and how easy it is to find that information (as with any other website) but there is also great value in making it easy to build upon the information. Wikis are built with the hope that newcomers will arrive and chip in. It's not like an airliner in that respect.

A really successful wiki is one in which lively community of people contribute, and build something great, which keeps getting bigger and better.

"Only by paying the costs of complexity can we enjoy the benefits"... if you're building an airliner. But if you're building a wiki, maybe complexity is the enemy. Maybe rather than thinking of it as "stalling development at some simple idiot level", we should think of it as "fuelling development at a simple level". After all it's the information which we really want to develop, and that can happen even with the simplest of page names.

-- Harry Wood 11:32, 21 May 2008 (UTC)

Policy?

This seems more like an essay than a policy. Do we have a setup for those here? --Varnent 09:18, 8 January 2012 (UTC)