Are you planning to upload some content to Quadropolis - Great! Read on!
The Cube Wiki article Distributing Maps contains the original text of this guide;
This deals with the specifics of Quadropolis postings.
It tries to prepare you for providing well rounded off content to the community and avoid any unwanted tags, maybe even get you a starred content one. ;-)

I just want to share some knowledge and give some tips on mapping. This is for novice mappers as well as for people that are already familiar with Cube editing. For learning the basics of how to edit maps, refer to the readme.html.
Some opinions on certain topics might be influenced by my personal taste and views. I don´t claim this were the ways to do it, but it´s the way I do it and what I find important.

Since I have never made a singleplayer map (I like multiplayer better) I can only talk about making multiplayer maps here.
I will divide this into sections, which are

1. Layout/Performance
2. Gameplay
3. Design (detail, mapmodels, light and stuff)

1. Layout/Performance

Starting a new map, it is always good to have some basic concept or idea in mind.

At first...
As there doesn't seems to be any guide or what so ever of how or why to star a certain content, maybe it's about time to do so.
I'll focus on maps just because those are the most starred content on Quadropolis.

Questions before starring content
You can have certain reasons to star a certain content, but you should always keep this in mind first (in the very same order):
- Is the map really that good on every single point (as in theme, texturing, detailing, lighting, (and clipping, flow and gameplay as well if it's a gameplay-based map)?
- Is it truly better as the average content on Quadropolis?
- Is it containing a certain originality which it separates itself from other maps again (while still being balanced in other points!)?
- Is it really what we would like to see as example for other mappers?
- Is it receiving enough attention already compared to similar nodes (as in votes and comments)?

Why starring content?
The main reasons for starring content are:
- Showing off a certain standard within the Quadropolis community (as being an example which should be focussed on for other mappers).
- Showing off to newcomers how maps within Sauerbraten could look like.
- Acting quickly on a certain event which is past in a very small amount of time (as for certain polls. Starring content will put them on front top page).

As certain discussions in the past (for example, this certain node) led to this conclusion:
A good map is a balanced map and a balanced map can be an included or starred map
As moderators or administrators have no (or should not) control about which map should actually be included within Sauerbraten, I won't spend time on whenever a map should be included or not. That's up to our developers to judge. Yet we can control whether a map should be starred or not. That's why I advice to rather star a map which is balanced than having only certain specific points done well.

Certain tips before starring
Before starring maps, be sure a certain amount of people already have voted but also putted constructive comments on it. So not just comments which contain The map just looks good [period], as that's the worse comment you can receive. Why? Because it's an opinion of someone which isn't based on anything.
Also recommending it to be starred it better as starring it right away. Even a discussion on an IRC channel could be very useful.

Sidenotes
If you still have no idea about the standards of inclusion, here it is.

If you still have trouble understanding the task of being a moderator, this may be useful.

From: http://qreeves.blogspot.com.au/2012/06/understanding-open-source.html

As the developer of the Open Source first-person-shooter project, Red Eclipse, I have come across many different types of personalities; some are good, some are bad. Quite often, I will have someone looking to contribute to the project who is so convinced that their point of view is so important that it only ever ends badly. Unfortunately, you can’t control this kind of thing, but in the past I have attempted to guide these people along the right path, albeit unsuccessfully most of the time.

I believe there is a misconception surrounding the phrase “Open Source”, that many people bang against and wonder why they’re met with such hostility. When a person decides to release their creations with an Open Source license, their desire is most often always to share it with the public in many ways, including allowing everyone to use and/or modify it for free.

You’ve probably heard the expression, “Free as in beer, not free as in speech”, but maybe don’t quite understand the implications of that. The creator of Open Source content is looking to give you something for free, and quite often allows you to take it and do whatever you want with it; the most beneficial part of which is the ability to study, modify, and play with it. This creator already has their own ideas, their own opinions, and their own way of doing things.

Every so often, you have an individual come along who has their own ideas and opinions, and they are so fixed on the concept that their way is the right way, they end up having a complete disregard for the creator, and the community behind that creation, if one exists. These people will enter a community, demand that everyone conforms to their vision, and when they discover the creator and/or community are resistant to it, blames everyone else for the fact that they failed. This often ends with the person declaring something along the lines of: “I should have known better, you don’t appreciate me, I’ll go elsewhere and get my way there.”

The problem is, these people don’t ever try to integrate with a project naturally, they appear to expect instant results as soon as they come along, and assume they know everything they need to know. This is mostly untrue. Throwing a tantrum and refusing to share your toys is the best way to ensure that everyone will instantly dislike you. To them, they were doing just fine before you came along trying to shake the tree and making demands of them, and they will continue to do just fine without you.

Open Source is a democracy of one. Someone, somewhere up the chain, came up with the idea and executed it. They built it, and they own it. Just because they have given something to you free of charge, does not entitle you to start telling them how to do their “job”. You’re not paying them, in fact, they’re giving up their free time to follow an idea that they are passionate about, and it is just a side effect of generosity that they released it for everyone to enjoy. Too many people think that Open Source bestows a right of ownership on them, but if you ever read one of these licenses carefully, all a creator is giving you is the right to use, distribute, and/or modify it.

So, if you’re looking to contribute to an Open Source project, now or sometime in the future, try to remember this: You are a guest in someone else’s home, please respect them and the work they have done. Try to understand their vision and their rules, get to know the way they operate, find out if they’re even interested in your ideas. If you approach them with a good understanding of their work, you’re more likely to get the result you are after, or maybe even find some other way you can fit in.

I found this most helpful, and haven't seen him explain it this well before and didn't want it to get lost in the comments of node/3184 'Why's there fewer starred submissions these days?', so I politely quote it here.

---

eihrul | 2011-10-15 01:40
The problem is that the mapping community is shooting itself in the foot. Quadropolis built mappers from the ground up, but now tries to operate at a level of sophistication that does not allow mappers to get feedback and grow. As has been said, new mappers are shoved away when they want community and feedback. Its standards are too high and simultaneously the wrong standards. I have a rough set of standards which I apply to maps for inclusion, which are really a balance of many aspects. If you only focus on one of the aspects, to the neglect of another one, the map is unlikely to get included. If you do a passable attempt at all of them, the map is likely to get included, even if it is not amazing. The bar is not amazing, the bar is balance. They are:

1) Performance. If the map is 400K verts because you spammed lots of little details everywhere, it is probably not getting included. 200K is more or less a sane top-end for big Hallo-sized maps. Spamming lots of water planes is almost always a no-no, especially in combination with spamming lots of geometry, since they multipled eachother. Try to stick to at most 1 water-plane in view at any one time.

2) Texturing. Texturing matters not just for appearance, but so the player can actually see where the hell they are going. I'm not trying to single anyone out, but if I am handed a map with very complex flow, and all hallways look the same because it's one solid gray mass or a such a noisy mass of random textures that I can't remember a pattern to them as I am running by, then the flow of the map has become more theoretical than actual. And, well, neither looks nice either. I may as well be running through a dark and twisty maze only to be eaten by a grue. :)

3) Lighting. The comments for texturing above apply to lighting, though with some slight difference. Too much noisy lighting with lots of different technicolor lights or almost-moire-pattern shadows from competing lights can make it hard to see and it just looks ugly. Even a simple sunlight with some skylight with some occasional accent lighting can be good enough for a lot of maps. Most people just try too hard here.

3) Geometry. I am actually rather forgiving of blocky detail, and people tend to overfocus on geometric detail to a fault. Spamming lots of noisy detail really tends to make maps look worse in general, and actually detracts from nice texturing and lighting, especially the texturing. You need to work with the cubes, not against them. Large details tend to work better than small ones, especially because at the pace people run around in Sauer your small detailing will mostly be ignored as people run by like cheetahs. Let the textures do the small detail.

4) Particles. Don't spam them. Sometimes particle spam can work in the right context, but usually it just looks a bit lame. It's not a deal breaker, but never the less, lame.

5) Mapmodels. Same caveats as spamming lots of small geometry detail.

6) Flow. Cramped tunnel systems or cramped hallways are bad. Too much verticality is bad. Too many teleports is bad. Too many jumppads are bad. Too open is bad (especially in CTF and capture), less so for FFA. Too many twists and turns is bad. The most popular FFA layout in Sauer seems to remain a hole with a ledge around it (complex). I think people overthink this one a lot as well.

7) Items. I think common sense mostly reins here, and that it is rare for people to really screw this up badly. Make sure items are available at appropriate frequencies according to their benefits. It is perfectly okay to omit the quad and health boosts and yellow armour in a map if you don't like their effect on gameplay for your map too, but generally all other items should be present. Quads/health boost/yellow armour very rare. Green armour kinda rare. Rockets/chaingun should be used judiciously. Shotgun/rifle/grenades a bit more available than rockets/chaingun. Health to taste. Pistol cartridges should only be placed only to insult/spite the player, but are not terribly useful.

8) Clipping. Usually I end up going in and fixing this myself on almost all included maps, but people never clip their maps adequately, so that the poor baby kittens escape and fall off the map and die. Save the kittens.

9) File size. The Sauerbraten download size is already big. Many people still have shit connections, and even if they don't, a huge download makes it less likely for impulse downloaders to try out the game because it will still take a long time to download. I don't care if you think otherwise. The download is not increasing 20MB for an FFA map, and even 5MB will make me skeptical. For 5MB, your map must be pure unadulterated awesome-sauce, like, better than almost every other map in the game. Smaller file size maps that are less a hindrance on the total package size are more likely to be included.

---

Circle Template for Circles with even(blue) and odd(red) diameters:

One Way Cubes

So - we saw handy do these in his mini_arena
and then explaining their creation in a tutorial included in factory..
also SheeEttin gave a very quick how-to in his comment to the mini_arena-node.

I've decided to put this up as a real guide too though - credits do have to go to those two for the research though! Well done boys - that's the true spirit of this community!!

Entrants should follow the following guidelines for entries into the competition:

Today, I have release Version 1.0 of my Sauerbraten editing cheat sheet. You can download it from my site, or here on Quadropolis.

The cheat sheet's aim is to give both new and experienced developers a desktop help that they can have on hand when editing levels. Version 1.0 only covers basic editing, with future versions to include heightmap, entity and other config settings that users find handy.

Anyone is welcome to download, and contribute or make suggestions to the project, which forms part of a series of tutorials on Sauerbraten I am planning.

I: Thou shall not infringe on copyrights.

II: Thou shall not make gimmick maps.

III: Thou shall not post a map that took less than 12 hours to complete on Quadropolis.

IV: Thou shall not use the clip/noclip materials in thine first three maps.

V: Thou shalt not capitalize file names.

VI: Honor thy Aardappel and Eihrul

VII: Thou shall not create spawn points facing a wall. This includes both monsters and playerstarts.

VIII: Thou shall not use the smallest grid size to create an entire map.

IX: Thou shalt not touch the lighterror variable. Ever. I will break the face of anyone who does.

X: Thou shalt not be a douche bag on public servers.