Hi Thistleknot -Let me just say first, I only had a brief chance so far to look at the spreadsheet! I should be able to look more closely by Saturday.At my initial look, I could see some of these factors are in my planned rewrite of the Jobs screen. For example, I'd like to include speed and quality factors for each labor (mainly just for display, however). As you've probably noticed, the current weighting only uses one factor...it has the (perhaps more than) mildly misleading title of "Job Priority". But priority isn't all it covers. The tutorial section about it is probably nebulous at best, and is in dire need of a rewrite. I'd been putting it off a little--there are several things I'd like to address about this screen all at once. And I haven't totally fleshed out all of them.First, I'd like to draw these two labor factors, quality and speed, initially from the information available at the wiki (like my other labor data). Initially I imagine that each of those factors for each labor will start with a value of, say, "true" if better stats affect that factor, or "false" if they don't.For example, a job like Brewing, which does not generate products with quality, would initially have a speed factor of "true", and a quality factor of "false". A dwarf can speed up Brewing by having better Brewing stats, but (s)he can't ever produce better quality booze with better Brewing stats. This will probably just be shown in a tooltip, or maybe with some nifty glowing or not-glowing icons, depending whether I feel artistic.Here comes a long example of where I think (if I understand correctly) our ideas seem to differ, though. I can see that we might want to change how important it is that Brewing gets done quickly, in our fort. Perhaps we might want to pull a "speed importance" slider down to, for example, 60% or something, based on the fort's needs. Any "quality importance" slider for Brewing would be disabled, of course, unless we go into the labor settings and change the quality factor for Brewing to "true" (maybe we're using a mod that allows quality booze). We're on the same track, I think, so far...However, as far as I know, the same stats still affect both quality and speed equally, for the same labor. So for a labor like Masonry, which has improved quality and improved speed output for better dwarf stats--I must ask whether weighing the quality and speed we desire separately, accomplishes anything more helpful to the end user than not. That was one of the questions I originally asked myself, before I released the Jobs screen the way you can see it now--with its one nebulous "Job Priority".I thought about users having to invent multiple arbitrary weights for each labor, and having to keep all these arbitrary values up to date as the fortress grew. (I even tried it out--it was the original design!) I decided, right or wrong, that this was probably going to confuse and/or annoy users, more than just having the one arbitrary weight per labor. I believed that I was already asking for a great deal of creativity/guesswork, with just the values that we see there now. There is also the consideration of how it works, mathematically, if there are separate weights for quality and speed. When it worked that way, the program just averaged them and used the result as the weight in the end. After all, it's all the same stats involved, and improvements to those stats cause equal linear improvements to both speed and quality performance in-game (as far as anyone knows, anyway).I'd like to be convinced it's incorrect to use just one arbitrary weight which is composed of both arbitrary quality and arbitrary speed factors, and anything else arbitrary we can think of besides priority (priority, I think, is a separate matter). But I am not convinced, as yetAlternatively, if I were sure it would be helpful for some users to work with "advanced" arbitrary weights, I'd be fairly happy to provide an optional, alternate view for that screen.So anyway, the result of my design decisions there, makes up one part of the "Job Priority" being used now. The other chunk is, of course, that the "Job Priority" can be arbitrarily increased to give the optimizer a better sense of priority. This is another planned change to the Jobs screen that I noticed you've hit onWhen I rewrite the Jobs screen, I visualize the user being able to drag and reorder labors, pulling them around so that the most important ones are at the top of a priority list. (Labors with equal priority would occupy the same virtual "slot".) Any labors the user wants the optimizer to ignore, would sit out of the way in some bin on the other half of the screen, ready to be plucked out if and when they're wanted. (In the current version, 1.3, and everything before it, there is no way to make the optimizer totally ignore a labor. That will be addressed.) I want to make the whole process more visually (and logically) clear and easy to use and understand, than it is now.TLDR:: I need convincing.: Yes, I'm separating it, eventually, but I intend that this is only in a more user-friendly way than things are now.: I should be able to have a more thorough look by Saturday (I apologize if I missed anything, which I probably did--I just wanted to reply back in a more timely way). This is unless my Android project milestone runs over, in which case I'll have a look during next week!