So, you're looking to host your first Doom community project. You want to get a bunch of people together to make maps for a set curated by you. You have an awesome idea you thought up just before going to bed last night and excitedly announce it the next morning - but along the way, something goes wrong. Why hasn't your project seen a single map submitted even after a month?   The reason, more often than not, can be found by looking in the mirror. Yes, you are the reason your community project idea didn't take off - or more accurately, that initial forum post in which you announced your community project is the reason it failed. So what exactly went wrong? Read on and find out!   This post will hopefully serve as a checklist of things to pinpoint the most fatal faults in your community project announcement and refine it so that the likelihood of it catching people's interest will be at least slightly higher. That said, please don't treat this post as a be-all and end-all guide to hosting a CP - just because you closely followed every point here isn't guaranteed to make your CP a mega-hit.   When should I host a community project?   The most important question you can ask yourself prior to hosting a community project is this: Am I mature enough to host a CP? By "mature", I don't mean your physical or mental age, but rather, I mean your mapping skills and overall knowledge of Doom. Now you don't have to be as great a mapper as Jimmy or Bridgeburner in order to host a successful community project, but at the very least, you should know the fundamentals of what makes a map good. Being able to point out flaws in people's maps, whether they be in presentation or gameplay, and provide suggestions as to how to improve them is an essential skill. Unless the goal of your CP is to be a grabbag of more or less random maps with extremely varying degrees of quality, which can also work in some instances (see Tenth Gear and Half Moon).   You should also have some knowledge of your target source port and how things in it work. This will be a great help in the compiling process in case you need to make corrections to people's maps. Maybe someone defined the custom sky for a Boom map in ZMAPINFO instead of using the MBF sky transfer, hence it only works in GZDoom. These sorts of things are very likely to happen, especially if someone is making their first map(s), and being able to detect and fix these issues is an important skill that will help in making the final mapset that much more polished and bug-free.   What should I specify in my OP?   This is by no means a comprehensive list of things you should specify in your OP when it comes to announcing a community project, but generally, it's a good idea to include at least the following information: Target IWAD Target source port (+ target complevel if applicable) and/or map format General rules/guidelines Resource pack and its download link (or policy regarding custom assets) Submission deadline Also, whip up a template for map submissions. Trust me, it'll save you a lot of suffering as time goes on.   General guidelines   Write your OP properly. Believe it or not, presentation matters, even and especially when it comes to announcing a CP. Proper writing and formatting helps immensely towards making it that much more likely to succeed. Capitalize the first letter of every sentence, use proper punctuation, double-check and triple-check your post for grammatical/spelling errors. A well-written OP is half a successful CP. Be the driving force. Hosting a successful community project is much more than announcing it and waiting for map submissions. Nobody wants to work with (read: for) someone who doesn't show any signs of wanting to contribute anything towards their own project. This also ties to the above in that an OP that exudes enthusiasm from the person hosting the project is more inviting than an OP written by someone who clearly doesn't care. Show people that you are able and willing to put in the work necessary to make your CP as great as possible. Be transparent. What this means is that you should be honest with your participants. Don't automatically tell everyone that their map is great - if something needs improving, tell them about it. If you don't like something in a map, tell the mapper what you didn't like about it and why. If you reject an entry, tell the mapper why their entry is being rejected. That said, try not to let your personal preferences cloud your judgement too much. Be as objective as you can. Allow people to learn. A good leader lets people grow - this also applies to you as the leader of a CP. When you run into an issue in a map, don't rush to open up your map editor and fix it for the person that made it. Let them know about the issue and fix it themselves. Guide them through the process if needed. Allow your participants to feel accomplished and feel that sense of personal growth, however small it may ultimately be for them. Keep your participants on the loop. This is especially important when hosting a CP that's likely to stretch over a longer period of time. You don't necessarily have to post about the project's progress every week, however. The most important thing to keep in mind here is to let people know when you expect their submissions to be ready. Post reminders about the deadline when it gets close. Also, don't disappear mysteriously while your CP is still ongoing. Keep your expectations reasonable. This should go without saying, but if your OP is a poorly written mess and you're not showing any signs of being willing to contribute to your own project, you're extremely unlikely to see your CP becoming a full 32-level megawad. You'll be lucky to see a single map submission. Don't complain if no one has submitted a map to your project after a mere week.