Update development_process.md

doc/development_process.md

@@ -19,8 +19,8 @@ One of the most important concepts to understand in our project is the **experim
 The intention here is that if you want to *play* CDDA, you would play on stable.  This is a carefully curated snapshot of the game with as few major bugs and balance issues as we can manage.  We don't consider stable *perfect*; sometimes, features have to ship in states we consider unfinished, because of the volunteer nature of the game.  However, we try hard to make sure major features in stable are playable and not a detriment to the enjoyment of the game.  We try to keep stable balanced and fun.
 
 On the other hand, in the experimental branch, we allow things to get broken.  We don't want things to be broken long-term, and we rarely actively try to break them, but we don't fret it if they do.  We often allow trusted contributors to mess something up just to see what happens, or to put in a partially complete project in order to collect data on what's needed for the next phase.  Not everyone likes being a guinea pig!  That's fine!  That's why we try to put out a stable every year or two.  People can also choose to play snapshots of experimental from before certain changes went in.  Because this is a volunteer-driven project, sometimes these breaks can be slow to fix.  For these reasons, we don't really recommend that people play experimental as their main way to enjoy the game.  Of course, many people do, and this is even important to the dev process, but from our perspective, those people are *playtesters*, not *players*.  This distinction causes some confusion, so let's look under the hood and see how we respond to playtest feedback.
-- First, we assess if the playtest feedback is valid.  This is usually the hardest part, and it becomes harder when a change is circulated to people that haven't yet tested the change.  There's a tendency for theory crafting to outweigh playtests, and we've had some pretty severe lost work hours when devs have tried to solve a problem that turned out to not actually be happening in game.
-- Once we're sure the feedback is about something actually happening, we check if it's intended behaviour or not.  If not, we start looking for solutions.  The most common way to find a solution is to think about how the mechanic in question should work in real life: for example, bow balance - a bugbear of design that plagued us for years - was finally solved by developing weak points in monster armour that could be hit with arrows.
+- First, we assess if the playtest feedback is valid.  This is usually the hardest part, and it becomes harder when news of a change is circulated to people that haven't yet tested the change.  There's a tendency for theory crafting to be louder than playtests, and we've had some pretty severe lost work hours when devs have tried to solve a problem that turned out to not actually be happening in game.
+- Once we're sure the feedback is about something actually happening, we check if it's intended behaviour or not.  If not, we start looking for solutions.  If it's an outright bug, we try to fix it.  If it's the unintended consequence of our ridiculously complex game, the most common way to find a solution is to think about how the mechanic in question should work in real life: for example, bow balance - a bugbear of design that plagued us for years - was finally solved by developing weak points in monster armour that could be hit with arrows.
 - If the behaviour is intended, we might consider why people are frustrated by it.  Is player-end feedback a problem?  Is the UI creating tedium?  This is an area where things can languish for a while, but it doesn't mean we don't care, it's just that these problems are hard to fix.  This is also where the experimental/stable thing becomes relevant.  For example, we will often leave a feature in experimental that makes the game unpleasant, because we do want that feature, and we want it working as intended.  On a few occasions, we've patched the behaviour out and then put it back in after stable.  This is to preserve gameplay for the people playing the curated, stable version of the game, while also continuing to work on the features we want to include.
 
 ### Mainline, in-repo mods, third party mods, and forks