NEM Community Fund (aka NEMtopia)

Ideas
#61


We could "force" voting by making people pay a tax for not voting when they are eligible (people with nonzero importance and at elast 10,000 NEM are eligible).


Not sure if that would do more harm than good.

It's a difficult problem, which exists in every free and democratic society.


It would give a real monetary value for participating in voting that would benefit voters and punish non-voters through indirect inflation. People who harvest the blocks with these special assets may not be as thrilled as with real NEM, but I do not think there will be so many votes as to make a practical difference in the economy :) Also, because the tokens are fungible for transaction fees, they have a functional value and could be easily converted into real NEM (or used to pay transaction fees even).
#62

I think this idea is soooooo important.  It is not just that this can be done with NEM funds, but for all money everywhere.  Sooooo much overhead is spent on governments ability to collect fund, monitor funds, distribute funds, and then audit funds.  It is so taxing on the system.  On top of that, each point creates chance for abuse. 

With the block chain we can have an open, transparent, and honest form of collecting money and then redistributing it, in a way that basically costs 0% overhead and is far less prone to abuse.  It is really direct governance of the people, by the people, for the people. 

It is not perfect, but it is a huge bound in the right direction.

#63

These guys are doing some very interesting work along the lines of this thread. 

https://eris.projectdouglas.org/

#64

To reactivate this discussion I created a chart.

I think its a lot easier to understand it from a chart than by reading all the great (and not so great) ideas in this thread.

I didn't implement all the ideas of this thread, so it is just a start. But we should really try to move forward on this topic because I think its very important.

[url=http://postimg.org/image/8ctpvjj4t/]

#65

To reactivate this discussion I created a chart.

I think its a lot easier to understand it from a chart than by reading all the great (and not so great) ideas in this thread.

I didn't implement all the ideas of this thread, so it is just a start. But we should really try to move forward on this topic because I think its very important.

[url=http://postimg.org/image/8ctpvjj4t/][img width=100 height=180]http://s30.postimg.org/8ctpvjj4t/flowchart_voting_NEM_v2_01.jpg[/img]


Nice that you put in the time to come up with this.

If the core team provides a modified proposal and the community rejects it the original proposal is immediately accepted ?
If the core team puts in a veto why does the community vote again ? And if they vote to accept the proposal again it seems there is no way to stop the funding anymore.
In the current version the veto seems completely worthless as the community has to agree with the veto ?
#66

I wanted to avoid two general problems:
1) Incompetence is a risk at communty votes
2) Corruption is a risk at small group decisions

(Of course I don't subject anyone to corruption, this is a general thought.)

So if the core team puts in a veto because of corruption there should be a way for the community to avoid this.
If the core team provides good/legit reasons for their veto a second community vote will probably lead to a reject (of the proposal). If not we should think about if the veto is really the way to go. In that case the core team gets the chance to at least modify the proposal (because probably they have certain issues with one or more details but the porposal as such is not bad) and offer this change to a 3rd community vote.

I think that if the core team explained why a proposal should be rejected and the community is not convinced… There is a high chance for corruption. Of course not necessarily, but how should we recognize that?

Edit: But yes, maybe the veto is too weak in my example. I just don't know how to do it better…

#67

I wanted to avoid two general problems:
1) Incompetence is a risk at communty votes
2) Corruption is a risk at small group decisions

(Of course I don't subject anyone to corruption, this is a general thought.)

So if the core team puts in a veto because of corruption there should be a way for the community to avoid this.
If the core team provides good/legit reasons for their veto a second community vote will probably lead to a reject (of the proposal). If not we should think about if the veto is really the way to go. In that case the core team gets the chance to at least modify the proposal (because probably they have certain issues with one or more details but the porposal as such is not bad) and offer this change to a 3rd community vote.

I think that if the core team explained why a proposal should be rejected and the community is not convinced... There is a high chance for corruption. Of course not necessarily, but how should we recognize that?

Edit: But yes, maybe the veto is too weak in my example. I just don't know how to do it better...


There has to be a way for the core team to shut down an idea if it's not in the best interest of NEM even if it sounds oh so great. People will just use some buzz words and everyone will jump on it. If NEM fails the core team will be blamed so the core team should have the final decision.
#68


I wanted to avoid two general problems:
1) Incompetence is a risk at communty votes
2) Corruption is a risk at small group decisions

(Of course I don't subject anyone to corruption, this is a general thought.)

So if the core team puts in a veto because of corruption there should be a way for the community to avoid this.
If the core team provides good/legit reasons for their veto a second community vote will probably lead to a reject (of the proposal). If not we should think about if the veto is really the way to go. In that case the core team gets the chance to at least modify the proposal (because probably they have certain issues with one or more details but the porposal as such is not bad) and offer this change to a 3rd community vote.

I think that if the core team explained why a proposal should be rejected and the community is not convinced... There is a high chance for corruption. Of course not necessarily, but how should we recognize that?

Edit: But yes, maybe the veto is too weak in my example. I just don't know how to do it better...


There has to be a way for the core team to shut down an idea if it's not in the best interest of NEM even if it sounds oh so great. People will just use some buzz words and everyone will jump on it. If NEM fails the core team will be blamed so the core team should have the final decision.


+1

i could put up a proposal saying il give all holders of nem "shares" of a company im setting up but that i want to do it legally so im looking for stakes from the team instead of an IPO.. everyone will vote yes because they would be getting something for nothing and it could turn out to be a big ponzi scheme.. community would blindly vote yes because greed runs rampant through crypto. if the team cannot have a way to veto something how can we prevent all the funds being sent to projects that mainly/only benefit those who vote yes ie. if i vote yes i get x$.. if i vote no i get 0$.. theres no need to speculate how that would go down..

#69

I totally understand your complains. I just didn't find another way to avoid corruption of the core team. And usually a corruption of a big group is less likely than a corruption of a small group.

#70

I totally understand your complains. I just didn't find another way to avoid corruption of the core team. And usually a corruption of a big group is less likely than a corruption of a small group.


Imho it is infintely more like for the community (you gotta understand that this is everyone that has a stake so also people that don't care or are pissed by now) to make a thoughtless decision than for the coreteam to be corrupt.
#71


I totally understand your complains. I just didn't find another way to avoid corruption of the core team. And usually a corruption of a big group is less likely than a corruption of a small group.


Imho it is infintely more like for the community (you gotta understand that this is everyone that has a stake so also people that don't care or are pissed by now) to make a thoughtless decision than for the coreteam to be corrupt.


core devs are probably guna be the biggest holders by a long shot so it would make perfect sense to think they have more incentive to do what is best for nem.

plus, even if half the core team were to ever become corrupt, that still wouldnt be enough to divert the flow of value from what is good for nem to something that is bad. having the funds under multisig control really does make things easier.
#72

Maybe you are right. Since this is about community funds only, it is probably senseless anyway. Because the core devs have the development fund, which is even bigger.

Ok so we forget about corruption protection in this process.

#73

Here's a suggestion I quickly drew up. There is a loop in this one to give the core team the chance to modify ideas until both core team and community are in an aggreement or the idea is ultimately rejected.

#74

Here's a suggestion I quickly drew up. There is a loop in this one to give the core team the chance to modify ideas until both core team and community are in an aggreement or the idea is ultimately rejected.


Looks reasonable.
#75

Here's a suggestion I quickly drew up. There is a loop in this one to give the core team the chance to modify ideas until both core team and community are in an aggreement or the idea is ultimately rejected.


Looks good to go.
#76


Here's a suggestion I quickly drew up. There is a loop in this one to give the core team the chance to modify ideas until both core team and community are in an aggreement or the idea is ultimately rejected.


Looks good to go.


+1
#77

Yes, that is good.
Does it help if I do that last suggestion of pat in my drawing style?

#78

Here's a suggestion I quickly drew up. There is a loop in this one to give the core team the chance to modify ideas until both core team and community are in an aggreement or the idea is ultimately rejected.

Yes, this is very logical.
#79


Here's a suggestion I quickly drew up. There is a loop in this one to give the core team the chance to modify ideas until both core team and community are in an aggreement or the idea is ultimately rejected.


Looks good to go.

Yeah looks good to me too.
#80

Here's a suggestion I quickly drew up. There is a loop in this one to give the core team the chance to modify ideas until both core team and community are in an aggreement or the idea is ultimately rejected.


Good point. A lot of people tend to agree.