Apologize for wandering off.
Technically, the masternodes can vote in/out developers that would be pushing a technical issue. So really the better way to set all of this up is to have each task tied to a budget. Then the budgets can vote in or out each issue/fix/solution and given highest priority. But the driver to work on any single item isn't always getting paid.
So if someone submitted a budget for 2000 dash to increase the blocksize to 16MB. Then got 80% support of the masternodes. You could say 2000 dash is getting spent on the blocksize change. Enforcing who works on it or how fast it gets done would be another issue. And technically, the network has already spent 5 dash to implement a 2MB blocksize.
"So really the better way to set all of this up is to have each task tied to a budget"
In my experience the solution you are proposing would be a terrible way to manage a software development project and typically leads to chaos in terms of trying to build a quality product and take it to market.
To give you an analogy, let's imagine Sony is building the PlayStation 5 and has a new system where the shareholders can vote on individual tasks and hire professionals to do that...
What is the CPU, GPU, sub system architecture? What is the OS? How many USB ports will it have? What is the backwards compatibility? What is the thermal solution? Where should it be manufactured? How should it be marketed?
Right now Sony's shareholders appoint a single team to achieve that which is internally organized and allocated basically a single budget. They work together internally and develop the product and take it to market and report to the shareholders at stages. This is essentially the same for every successful company on the planet.
But by opening up each part of that design / production lifecycle to different groups without a single lead you just end up with a mess, that's over budget and overtime and fails pretty much all the requirements in my experience.
Because by removing the brain of that project team and replacing it with the shareholders to manage, you are removing the professionalism, experience and knowledge required to do it effectively and replacing it with a disparate group each with their own interests / agendas and probably lack of experience, otherwise they would be doing the work and not be the shareholders in the first place.
What you end up with is a meltdown where shareholders would be constantly fighting to micromanage each part of the development and without any leaders who can view the whole lifecycle from the top down and make the correct/difficult decisions to balance all the various elements that need to be considered and resources that need to be directed (including human resources) to deliver a cohesive and quality product.
It's just a basic fact of engineering great products that you need leaders with the vision and experience in how to do that leading the show whether that's an iPhone, Ferrari, Operating system or space shuttle. How that is decentralized in Dash is that rather than a benevolent dictator at the top, we split areas of the project into teams each with their own benevolent leaders, and those leaders can be replaced - the core team is an example, Evan is leading it with the permission and funding of the network. If the network disapproved, it could cut off his funding and has $40k or whatever per month to hire a new team for that specific role, i.e. development of the core project. That is about as decentralized as any organization that wants to succeed should go as far as my experience goes.
So micromanagement of project is something that Dash needs to actually prevent to survive, same as in any company with shareholders (and i have invested in 1 medium-sized venture that failed largely because the shareholders gained too much power and were then able to use their voting rights to micro manage the technical development and it ultimately cost the shareholders a lot of money and with what you are proposing I can see a similar thing happening actually).
What tends to happen in that situation too is that developers basically end up downing their tools and saying 'this is ridiculous' with having the direction changed and disconnected ideas from different people who think they know what their doing but don't have the professional experience. One can imagine the same scenario in many types of project where creators are tasked to do something and the stakeholders don't let them 'get on with it' but instead jump in and try to change everything mid flow - it just ends up with a mess.
Another major thing that goes wrong with this model is you have a massive increase in inefficiency caused by the increase in reporting and communication required for developers forced to have to present everything they were doing at different levels and have this 'approved' by a mass of stakeholders constantly throughout the lifecycle, who are all fighting each other to get things done how they wanted.
Therefore the best way to develop a software product and take it to market is to appoint an experienced team that works well together and fund them to do that and get stakeholders to approve and fund that at a high level with control/reporting limited to intervals where deliverable / goals are pre-agreed and metrics are used to monitor that and asses that.
Hope I explained it well enough. I'd be interest to hear if anyone with professional experience in product development or team management would disagree with this and why.