Dash Nation Consensus Discussion
- Thread starter TaoOfSatoshi
- Start date
Stop. You act like you're the bigger person around here half the time, then the other half of the time you pull this shit. Noone is trolling. Just because someone disagrees with you, or in this case quite a few people do, doesn't make them trolls. Stop being a child.
Notice how noone calls any one of you trolls even though you guys are doing the same exact shit you keep complaining about.
I will add that "you guys" should mean @yidakee. The majority of people here have been very respectful and constructive.
I think its somewhere between the two opposing views expressed here. I'll explain:
That change has started. Some would want that progress to go faster. But we do still have Evolution happening, the direction has been set and its a lot of work. The dev team, implementing the core technology of this thing we call Dash, is still run in an autocratic fashion, based on the vision of one person. The rest of the thing we call Dash, and there really is a lot of it, is starting to be governed in a decentralized manner using masternode voting.
We're doing decentralized governance, for some parts. Maybe one day we'll be ready for decentralized governance of the core product, but at the moment there is only one person with the vision for the future of that product.
There's no rush here, lets get it right.
- Evan created DASH and assembled a team
- He has led its development to where we are now
- DGBB has been implemented and is revolutionizing "open source projects" - i put it in quotes because what we have here is much than a "project"
- Evolution has been planned, from what I understand this was a collaborative effort by the dev team but led by Evan
That change has started. Some would want that progress to go faster. But we do still have Evolution happening, the direction has been set and its a lot of work. The dev team, implementing the core technology of this thing we call Dash, is still run in an autocratic fashion, based on the vision of one person. The rest of the thing we call Dash, and there really is a lot of it, is starting to be governed in a decentralized manner using masternode voting.
We're doing decentralized governance, for some parts. Maybe one day we'll be ready for decentralized governance of the core product, but at the moment there is only one person with the vision for the future of that product.
There's no rush here, lets get it right.
I completely agree with this. No rush or timeline at all, but it's great we're having this discussion. When the time comes to perform this transition, we will have a wealth of input to forge our new organization from. Thanks for that post.
All I've seen in this thread was was an initial request for clarification, which has been given numerous times by a few people. You guys simply do not accept the answers given, which are nothing new.
You keep trying to spin things around your way, simply not acknowledging the status-quo of how things are being developed. You keep on pushing your agenda and crying for clarification, which has been given times and times over, but simply don't accept and keep asking the same thing over and over again. What would you call this sort of directed and concerted denial?
Guys, read back from post #1 and assess your demeanour. No matter how hard you try you're not going to swing this your way by the simple tactic of repetition until exhaustion. I've been here and at this for 3 years and what is happening here is not new. You're disserving Dash. Debate is good, this has long past that stage.
If you disagree so strongly, you are more than welcome to do something about it. But spreading innuendo and trying to pin it on me or any other team member simply wont work. If you feel so strongly about this put your "money where your mouth is" and prove us all wrong. If you can do better, please show us.
It is not my opinion, or my will, or my say, that dictates who is who and what is what about DGbB. I'm just participating in this grand self-organising project. It is what it is, you guys just don't like it. Well... tough luck. At this point I don't know what more to say except, well ... tough luck
.
You keep trying to spin things around your way, simply not acknowledging the status-quo of how things are being developed. You keep on pushing your agenda and crying for clarification, which has been given times and times over, but simply don't accept and keep asking the same thing over and over again. What would you call this sort of directed and concerted denial?
Guys, read back from post #1 and assess your demeanour. No matter how hard you try you're not going to swing this your way by the simple tactic of repetition until exhaustion. I've been here and at this for 3 years and what is happening here is not new. You're disserving Dash. Debate is good, this has long past that stage.
If you disagree so strongly, you are more than welcome to do something about it. But spreading innuendo and trying to pin it on me or any other team member simply wont work. If you feel so strongly about this put your "money where your mouth is" and prove us all wrong. If you can do better, please show us.
It is not my opinion, or my will, or my say, that dictates who is who and what is what about DGbB. I'm just participating in this grand self-organising project. It is what it is, you guys just don't like it. Well... tough luck. At this point I don't know what more to say except, well ... tough luck
.
Last edited:
I wish you would not keep talking as if forking the code is the only thing that can be done by those of us who disagree. (If this isn't what you are referring to, please correct me.)
And it's not even that I disagree with the accuracy of the governance or power structure you are describing as the model of the current system.
What is the purpose of a masternode vote on project direction such as the block size vote? Is it to gather information only? There is nothing currently built into the protocol that makes a masternode vote such as this enforceable, but if we have a 'benevolent dictator', can we get a statement from project leaders on how they intend to respond to such votes, if at all? Does it make a difference if the proposal is initiated by the core team or from the outside? Is the project team willing to alter their behavior, for example, to delay an attempt to push a protocol version update in mainnet, if there is a masternode initiative with sufficient support? Evan obviously has Dash's best interest at heart and is a very large stakeholder himself, so I do not think that Evan or project leaders would *want* to try to push out an update that is unpopular with other stakeholders. But the reality is, if the core team decided to release an update anyway (or do so without being aware of / without allowing time for masternodes to initiate a proposal and vote), then the masternodes are incentivized to update as soon as possible even if they don't support the protocol change (out of fear that they will be left out of receiving payments), and at the same time miners won't care as long as they can still mine. Maybe we just let everything be and "what will happen will happen", but I don't see that scenario as being good for DASH. I would say that such a scenario is unlikely but I just don't know that. Looking to this discussion to take preventative measures so that everyone knows what to expect from Evan, and the core team, and the community.
In the last couple of days alone, I have accomplished the following for Dash:
Started a discourse with you about a communication improvement in the community, aided in the discussion about the development of retail solutions in FSP, fought trolls on BCT to make it a better place to attract people to the community, helped the Stack Exchange initiative, continued my PR work on Twitter and my website, and accepted approximately 20 people into Dash Nation, continued an honest discussion here about the present and future of Dash. That on top of raising a daughter and paying attention to my wife.
When I'd like to have a conversation about possible improvements to our organization, I don't deserve to be painted with the brush you're painting me with.
Please, re-read my posts. I'm being nothing but diplomatic, never engaged in ad hominem attacks, listened to both sides, and articulated my thinking.
This is a discussion that needs to happen, for now and for the future. Our path can be easier if we achieve consensus among us on how to proceed, with the mindset that we are trying to create digital cash with decentralized governance.
Does it have to happen today? No, but it needs to happen eventually, and we will be that much farther ahead by this thread of input.
YOY HAVE TO ACHIEVE CONSENSUS NOT ONLY AMONG YOU, BUT ALSO AMONG YOU AND THE FUTURE GENERATIONS OF DASH, THE NEW COMERS.
This is the real consensus. You always forget future dash generations, when talking about consensus.
CONSENSUS IS SPACE TIME RELATIVE.
Its is not the disagreeing, it's the blind beating of a dead horse that I am referring too. In particular discussion, answers have been given but not accepted and keep getting beaten and facts are simply not accepted. In this case, yes, forking is the only solution for the discontent.
Yes.
That is exactly what has been happening thus far. You should be more attentive.
No. You can submit anything at anytime.
Didnt fully follow the logic there. Votes on behaviour are not vinculative at all. Only funds. And only Evan is able to merge requests onto github. And once again, currenly Masternode hold the strings to the project's funds, not the development roadmap decisions. That does not mean their opinions are not highly taken into consideration as was the blocksize vote an example. Masternodes can always protest by defunding the core team and funding a new one. You are more than welcome to submit such proposal and lobby for it. No harm at all.
I cannot speak for someone else, I'm sorry
If you actually listen and study Dash, you'll know that Evan has thought of that and has a plan to bring equilibrium of power regarding exactly that, and at the same time solve the 51% attack issue that plagues PoW coins. He has also solved the mining centralisation puzzle. So instead of trying to find problems, I suggest actually digesting what we currently have and see the strong points, and try to make a case for your worries on testnet. If you manage to break it, I guarantee new protocol will be delayed as long as the issues persist.
For the... I forget how many times now... this is how thing currently work.
Thank you. I stand corrected. I completely forgot, but just making a point really - should read -> Core Devs... I remember during the RC forking incidents this was heavily discussed.
By the way, anything else to add? In your opinion am I off base somehow in my answers?
.
Ok then.
Lets have a vote about who should have merge permissions on github. This it tottaly rational, because the role of the tester is tottaly different than the role of the developer, and the role of the person who we trust to commit is again a totally different role. Lets legitimate Evan's position on github, so that he will not be a benevolent (untrusted) dictator anymore, but a trusted person. Because money is trust and trust is money. I think this is the best to be done, to resolve that issue.
And then, lets talk about the issue of the space-time assymetry of Dash, and the crime core team has commit against future dash generations. Lets talk about basic income. Because if you refuse to take into account future dash generations, then future dash generations will refuse to TRUST dash, and in that case dash is going to be yet another geek coin designed to fail, like bitcoin and the others.
Last edited:
Big words from a person who joined just a few weeks ago and barely had time to distinguish Dash from Dashcoin.
Vote on who controls github? Are you out of your mind? That is the entire point of why github exists the fork button you ding-dong!
Space-time assymetry? Seriously? I'd love to hear more on your String Theories regarding cryptos.
Shroedinger and Satoshi walk into an bar, and they didn't.
Heisenberg, Gobel and Evan walk into a bar
Heisenberg looks around the bar and says, “Because there are three of us and because this is a bar, it must be a joke. But the question remains, is it funny or not?”
And Gödel thinks for a moment and says, “Well, because we’re inside the joke, we can’t tell whether it is funny. We’d have to be outside looking at it.”
Evan looks at both of them and says, “Of course it’s funny. You’re just telling it wrong.”
Basic income? ... This is not a Proof of Stake coin. It's a Proof of Service coin. Period.
This thread is getting beyond ridiculous at this point
.
You are of course entitled to your opinion, but I would caution you to not make a generalization about the entire thread based off of the posts of one contributor.
As I have cautioned you to about the blatant agenda behind these constant nagging cyclic attempts to create divise where there is none.
I quite literally mean the entire thread, this last post accusing Dash of being a quantum-physics black hole is just the cherry on top.
We have discussed and discussed and discussed, and all we get is accusations. We have answered questions numerous times, but keep getting splattered with them as if they hadn't at all even been read. Numerous core team members and core devs have come here to set things straight, yet the same gang of 2 or 3 (now 4) keep coming back trying to sway public perception with what now is just complete nonsense.
At the start, this was a valid discussion. It quickly spun the other way. You 3 or 4 people do not represent the majority of anything.
Why don't you put your money where your mouth is and actually propose what you are proposing to actually see if there is any interest by the Masternode network?
But all of this is completely worthless at this point. It is getting absolutely ridiculous, to say the very least.
.
Why do you have this attitude of "us vs. them"? Divise? Accusations? Straw men. Show me a post where I attempt to divide, in fact I've stated the opposite more than once. Where have I accused anyone of anything?
From where I stand as a community builder, it is your posts that are divisive. My goal is to obtain clarification, and try to build a more consensus-based system (decentralized governance), as I see us purporting to be in the media. If this concept only applies to budgets, lets clarify that. I for one would like to see it extended to other areas. That doesn't make me ridiculous...why this constant need to label everything?
Just let the discussion take its course. I'll see everyone tomorrow.
All you are saying/asking/proposing has been addressed and answered multiple times now.
Clarification only occurs when your questions are answered, as they have been multiple times already, and you acknowledge you've received such answers, which you don't. You may not like it, but that's another issue altogether.
It is you opinion what you're saying, and I respect that. You don't have to agree with them, but clarification has been given.
The perception you have about our DAO is not correct I'm sorry to say.
You can build your consensus-based decentralised governance system, absolutely,go for it, but your concepts about it clash with how Dash actually operates.
If you think I am mistaken, and everyone else, please prove us wrong - ask the Masternode OPs, why on earth aren't you doing it?
With this post I rest my case and leave you guys to keep discussing it.
.
This is a really good joke, featuring my favorite characters.
As far as the conversation as it is going, I always think about Dr. Marshall Rosenberg and his non-violent communication. Even if we're all just PPPPPTs - Pretty Poor Protoplasm Poorly Put Together - we all might benefit from his wisdom. (I promise, it's even funny)
Part of the miscommunication here might be that what I am looking for is not so much an explanation of what the protocol is or what it allows. I am on board with you on everything you say about describing what masternode votes are and the concept of dgbb in the protocol. I also understand that the vision for the protocol for governance in the future may extend further than where we are now. All of that is great (and is worth being able to explain clearly and be able to point to some material so that newcomers, and existing community members, can understand this). But in addition to the explanation of how the protocol works, and how our self-organizing teams are formed, I am asking this particular self-organizing team if they are willing to voluntarily put forward a policy. You said that masternode votes on project direction issues are for information-only but that the core team would take the vote into consideration. That's a start, but it sounds a little weak and unclear for a policy. On the other hand, promising to obey the masternode vote would likely be too strong a policy. Can we explore this a little more?
One of us is misjudging the general amount of support for having this discussion. Since you think this is just an extreme vocal minority, I thank you for your patience with putting up with this. If you are tired of the discussion I'm not going to call you out or insult you, but conversely I would ask that you afford us the courtesy to not discourage others from continuing the discussion until we reach more clarity. I think we have already made quite a bit of progress here and encourage everyone to please stay positive -
Of course we need a vote on who controls the official github of dash. And if the person who controls the official github of dash refuses to give the password to the elected one, community will fork. The threat of forking will force the benevolant dictator to surrender. Because if the does not, community will left and the benevant dictator will become a dictator without peasants.
Space-time symmetry in a coin means that old generations have the same chance to coin money than the new generations. Also it means that every newcomer gets a portion of digital cash whenever he arrives to the community, and recieves also an ammout of cash in time periods. Of course this requires the definition of online identities, so that no person have multiple accounts and receive more money than others. This can be solved by using a web of trust or by using any other proof-of-individuality scheme.
Last edited:
Stop referring to this as beating a dead horse. We are coming up with solutions to problems that we see with these new budget system changes.
The forking response is not the only solution(nor is accepting the release to see what is in it, or having faith in Evan). When the initial budget and voting system was first proposed, it received many comments to change it. It actually was changed before it went into the release. I think Evan and the other developers are very good at understanding the community and observing what is the ideal balance. So past history does provide proof that our comments are reviewed and used in each iteration of the budget.
This isn't about having a protocol that won't fail by testing it on testnet. This is about creating the best solution that will not give unbalanced powers to managers without any care about the future or Dash. If we order a sausage pizza, are we focusing on making a pepperoni pizza that is done perfectly and hot? Let's get the pizza choice right first, before we worry about how to cook it.
So what am I talking about the changes that I see are unbalanced:
- Multiple managers approve expense reports AFTER expenses are paid. This puts undue risk on the ones paying expenses, as they never can know for sure if their expenses will be paid. It also puts no priority on expenses....except by arbitrary decisions by the multiple managers.
- Multiple managers/employers managing each employee/contractor. This is really not an effective strategy. Employees don't understand which manager has priority over their duties or which duties are the most important.
- How is a group of managers going to decide if an employee is doing what they should be if they are all giving that employee different tasks. Some might get done on time, some not?
- Managers making funding decisions bypass the best aspect we have now, a collateral based funding mechanism. If 10 managers can make decisions on if a project gets vetoed or approved, then each will effectively have the voting same power as 350 masternodes(350,000 Dash). This is a big change from the system we have now! (I have already pointed out the problems this causes, and will refrain from posting that again.)
We need to be focused on building a decentralized system. Not centralizing the system we have now. I feel that a lot of the discussion was started because Terpin was voted out. Well, I think many are realizing that it was actually the right decision because the company was not performing. The goal shouldn't be to avoid a similar situation - this actually showed the system working.
If we start with the funding.....That comes from the masternode votes. So any funding decisions need to be voted in before work starts or materials are purchased. This is is what gives priority to which projects are worked on. The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on. There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting. We can tweak the system we have now to add some functionality that is missing. Any management roles should probably happen outside of the voting and budget funding protocol.
- Ability to split payments to individuals inside a project. That split can be determined by a principal project owner. This will help a contractor/company pay all employees at once.
- Ability to have a higher vote out threshold for contracts. There still needs to be a way to cancel a contract....it just should not be determined by 1 vote like it is now.
- Offer a way to change the duration(only can be lowered) or amount(only can be lowered) of a proposal without paying a new proposal submitter fee.
@Solarminer ,
I think it is a separate topic but I guess Tao don't to make a little off-top here. I believe you have made some wrong assumptions about the managers (therefore we need to wait for testnet release or specs - there are too many assumptions - including my assumptions):
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
I think it is a separate topic but I guess Tao don't to make a little off-top here. I believe you have made some wrong assumptions about the managers (therefore we need to wait for testnet release or specs - there are too many assumptions - including my assumptions):
- "Multiple managers/employers managing each employee/contractor" - I have never seen this idea written and never heard about it. From where it comes from?
- "How is a group of managers going to decide if an employee..." - my understanding is that project managers are going to control projects (not employees) - this is a big difference. Why? Here is my understanding of the process:
- Sponsor (MN network) votes on the proposals submitted by vendors.
- Sponsor hires PMs to control approved projects (hiring PM = voting on his proposal too) - so from the sponsor perspective PM and vendor are "employees"
- Vendor works on the project delivery and cooperates with PM by providing status updates and sharing results
- PM controls project status (money, deliverable, schedule, time, quality) and reports it to the sponsor (MN network)
- Based on the report from PM, sponsor makes a decision about project continuation or cancellation (voting)
- Part with expense approvals is not clear to me at the moment so I do not write anything about it
- "Ability to split payments to individuals inside a project" - I believe that this should not be concern of MN network or PM. Vendor is a separate entity it is not our concern how the budget is split internally on the vendor side.
- "Offer a way to change the..." I think that there should be a change management process indeed (and not only to lower but also to extend project parameters). Each change could be voted separately but not necessarily as a new proposal
I disagree with this "The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on." - in my opinion this coordination is even more needed during the project duration - to provide independent, consistent and professional information about the project status (as an input for voting).
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
Last edited:
We dont have to wait for the release of any specs. This is a fundamental error. We have to discuss and vote about specs before their release, and the core team must come here, and discuss and vote also.
We do not make assumptions. Propositions is what we are making. We do not accept the core team to arrive suddently carrying the ten commandments, and command us. If there is some of you having the mentality of the slave who waits to be commanded, please try to understand that this is not all people's mentality.
So the procedure of specs production should be tottaly reversed.
Small decisions should be put into polls, and these polls should depend eachother.
For example:
Should we go to France? Yes/No/Other
|________result No/Other----> end
|________result Yes---> Should we go by plane? Yes/No/Other
|________result Yes---> Should we stay in a Hotel? Yes/No/Other
|________result Yes---> Should we go by plane? Yes/No/Other
|________result Yes---> Should we stay in a Hotel? Yes/No/Other
|________result Yes-----> In a double room? Yes/No/Other
From that tree of polls, the specs will be extracted automatically, according to the votes of the people.
Last edited:
Great! See how discussing things first can change people's ideas? This conversation about Sentinel would have been better had before work began, IMHO, as it is a major change.@Solarminer ,
I think it is a separate topic but I guess Tao don't to make a little off-top here. I believe you have made some wrong assumptions about the managers (therefore we need to wait for testnet release or specs - there are too many assumptions - including my assumptions):
I principle I agree with what you wrote here:
- "Multiple managers/employers managing each employee/contractor" - I have never seen this idea written and never heard about it. From where it comes from?
- "How is a group of managers going to decide if an employee..." - my understanding is that project managers are going to control projects (not employees) - this is a big difference. Why? Here is my understanding of the process:
- Sponsor (MN network) votes on the proposals submitted by vendors.
- Sponsor hires PMs to control approved projects (hiring PM = voting on his proposal too) - so from the sponsor perspective PM and vendor are "employees"
- Vendor works on the project delivery and cooperates with PM by providing status updates and sharing results
- PM controls project status (money, deliverable, schedule, time, quality) and reports it to the sponsor (MN network)
- Based on the report from PM, sponsor makes a decision about project continuation or cancellation (voting)
- Part with expense approvals is not clear to me at the moment so I do not write anything about it
- "Ability to split payments to individuals inside a project" - I believe that this should not be concern of MN network or PM. Vendor is a separate entity it is not our concern how the budget is split internally on the vendor side.
- "Offer a way to change the..." I think that there should be a change management process indeed (and not only to lower but also to extend project parameters). Each change could be voted separately but not necessarily as a new proposal
I disagree with this "The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on." - in my opinion this coordination is even more needed during the project duration - to provide independent, consistent and professional information about the project status (as an input for voting).
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
Back to the main topic:
I'm speaking for myself, but I've listened to your input. I now believe we need a core team (but still disagree on the implementation), I see what the roles and responsibilities of professional contributors are, and that the community is free to take initiative to contribute in their own way.
I still see vagueness in the role of Masternodes, however. Are they strictly for budgeting, or can they be used for technical input, as the precedent of the much-publicized blocksize vote established?
Cherry picking technical votes is not the answer. Can the Masternodes vote on technical issues or not?
Thanks for your patience with this discussion.
Now we are getting somewhere. I really appreciate this response. This is the dialog I am looking for.
The multiple managers are not assumptions. I actually derived them from the github posts. Let's go through the parts.
https://github.com/evan82/sentinel/blob/master/docs/rules.md
- Employees must work for an Employer (Probably a primary and secondary)
- Employers can fire employees, but there must be consensus among the project manangers
Ok so with your summary, a project is bundled with a project manager. The project manager still has control over funds in some way. If the funds are still coming from the blockchain, this is better. If the project manager is actually storing the funds this is really bad (then they would be taxed and subject to theft). I still have some issues with a project manager being able to stop funds. Maybe there is a way to allow an overthrow decision with a masternode vote to keep the product manager honest. This is really the part that needs to be clearly defined.
Actually, there was a change to the "expenses are paid by consensus" line. Looks like someone is listening. LOL. Anyway, this is phrased better, but I still don't understand how priority of paying expenses is set. Maybe it is only allowed under a specific project which is preallocated from the budget. So if the project can use 1000 dash, expenses up to that can be paid. If more is needed, the project needs to wait for another funding cycle or a new proposal with a vote. Feeling better about this part now.
Well, I am not saying splitting payments is the right way to do it....just a thought. I am thinking that if numbers get bigger distributing the funds in smaller chunks will have less risk. But you are right a supplier getting funds is under their control, we don't need to address that.
Well that is interesting. Implementing a change proposal option instead of a new proposal. Maybe this needs a lower voting threshold if certain things stay the same. No fee to change or something.
Yeah, there may be some value for coordination during a project - especially if it has a multiple month budget.I disagree with this "The only management structure that can be built on that is to prepare and coordinate proposals that masternodes can vote on." - in my opinion this coordination is even more needed during the project duration - to provide independent, consistent and professional information about the project status (as an input for voting).
I have to say I am really surprised to see this: "There can also be advisory roles to give information about projects before they get voted on and offer advice to project submitters before submitting.". Few weeks ago, when I proposed the same role (but called it "consultant" and it was more focused on serving MN owners) you were the biggest opponent of this idea. Good to see your opinion evolving
Ah, yes. See I don't always think everything is a bad idea.
You can read my posts on bitcointalk, I was in favor of a consultant and advisor service to inform masternodes. I was not in favor of voting for a consultant team that voted on behalf of masternodes.
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.
Andy
@AndyDark Well said. Here is an article from a lawyer who reviewed the Slock.it DAO governance model. Their model is similar to what we have now and he picks it apart pretty well. I think Evan is on the right track. http://www.cameronhuff.com/blog/slock-it-dao-paper/index.html