All of our builders and guests have a vested interest in seeing the project complete. Not only does this provide a sense of accomplishment and completion, it also allows the map to be passed to our Developers, who will then start the process of using the map to create an RPG game. Currently, it's estimated that our project stands somewhere in the ballpark of 65%-70% complete, with major builds such as Oldtown still looming. One persistent problem we've faced is the aging process of older builds, and the desire by people to redo builds which are considered outdated. It is believed that allowing for redos in general would create a vicious cycle, where we would never finish due to builds constantly becoming outdated, or at the very least would set us back by a great many completion points. Consequently, we've operated under a rule forbidding redos in general.
Thus far, however, the no-redo rule has been applied as somewhat of a precedent law. This has, in the past, lead to a large amount of confusion and debates about how the rule is applied. This post intends to solidify the no-redo rule, and to make it unambiguously applicable.
Please note that none of these rules or stipulations are new; they are merely a formalization of the cumulative discussions and precedent cases we've had previously regarding redos.
1. A "redo", for the purposes and intents of this post, is defined as the action of wiping clean all or most of a build, and re-building it from scratch according to new plans.
2. An "update", for the purposes and intents of this post, is defined as (1) adding on to an existing build without removing the existing portions (for instance, adding surrounding lands which weren't there before), and/or (2) modifying the exteriors or interiors of an existing build without removing the build and starting from scratch.
1. Redos Forbidden: Redoing a build is expressly forbidden, under any circumstances, except for in the case where one of the following clauses holds true. Note that while appeals to quality or appeals to planning can be used as motivation for a redo, they cannot be used as reasons for why a redo should be allowed. Only the following clauses can be used to claim that a redo should be allowed:
a) Server Build Clause: If the build under consideration is a server build, it may be allowed to be redone after extensive discussion. However, server build redos will in general be postponed until all incomplete server builds are either complete or in progress. When server builds are redone, it will only be done if the redo does not have substantial impact on the direction of our completion rate.
b) Inadequate Canon Clause: If the build under consideration objectively lacks important canon, which directly impacts the planning or style of the build, it may be allowed to be redone. For this to be satisfied, the claimant must prove unambiguously that a substantial amount of canon has been missed. The claimant's case will be assisted if it can be shown that this lack of canon was understood to be an issue before they intended to apply for redo.
[UPDATE (12/16/18)]: Redos will be tentatively allowed for builds which get new canon in new publications, but giving mods the right reject these on a case-by-case basis depending on circumstances.
c) Abandoned Build Clause: If a build is incomplete and filed under the projects orphanage as an abandoned build, it may be allowed to be redone. The intuition behind this clause is that it can be difficult to pick up someone else's outdated work, and if we expect people to do this very few people would want to apply to finish abandoned builds. However, moderators reserve the right to veto a redo for an abandoned build if they deem the existing portions to be particularly high quality.
d) Megabuild Clause: If a build is a part of a megabuild (see this guide for a definition), it may be allowed to be redone given justification in the megabuild proposal. The reasoning for this is to allow megaproject leaders to establish stylistic coherence in a broader region rather than having to work around an existing project. This also has a higher probability of leading to a high-quality, finalized region than an isolated redo. This clause is a formalization of previous precedent (e.g., the removal of the projects surrounding Oldtown to allow for a consistent regional style to be established).
2. Updates Allowed with Stipulations: Updating a build is not expressly forbidden, however an update must abide by the following stipulations to be approved:
a) Sufficient Additional Value Clause: The update under consideration adds sufficient value to the existing project. As there is no strict criteria to judge this by, it will be analyzed on a case-by-case basis. Some general principles are that an update is more likely to be allowed if it completes underdeveloped or non-existent surrounding lands. If a build has poor layout or planning to begin with, an update may be less likely to be allowed because interior/exterior updates are unlikely to solve the fundamental source of low-quality, and these efforts would be better allocated to increasing our completion rate through doing incomplete builds.
b) Abiding by Update Clause: An approved update cannot, under any circumstances, turn into a full redo. If a builder attempts to get something approved as an update and then transition into a redo, approval may be revoked.
3. Conditions for Lifting Redo Ban: Only once the following two conditions have been satisfied will we lift the general ban on redos:
i) The world has reached 100% completion rate, judged by a thorough investigation and quality check by the entire team. This may not necessarily include detailed terraforming and non-canon space fillers everywhere, but it does include at the very least all canon builds on the official project list. All WIP terraforms must be finished at this point in time as well.
ii) The 100% complete world has been backed up and exported to the Development team.
The lifting of the redo rule may be coupled by the introduction of a plethora of new blocks which we were previously unable to introduce due to aging concerns. Following this point, the server will operate under an "incremental updates" model: every time a redo is fully completed on the production server, that build is ported over to the development server in place of the existing one. Thus, the development server remains at 100% completion, but quality increases incrementally.
4. Submitting an Appeal: In the case where an individual believes a project is exempt from the no-redo rule, or believes a build qualifies for an update, they will be expected to start a new thread in the appropriate regional sub-forum entitled "[Project] Redo Appeal" or "[Project] Update Appeal" wherein a public discussion surrounding the project and appeal may begin. The moderating team will then by majority vote approve or deny the appeal.
Projects approved under 1(a-c) for redo are open to all builders per standard project rules. While the original builder who appealed the project for redo will be given greater consideration, all builders are as welcome to apply for the redo through the formal application process as much as the original appealing builder.
We hope that the formalization of this rule may prevent future confusion and debate, and allow us to consistently apply the rule in a way which does not bring fairness into question. Above all, we hope that this rule helps us to see the light at the end of the tunnel, and focus our effort to completing the mammoth task of recreating Westeros in Minecraft.