Towards BitShares v2.1

[Thom]

I've always felt the BitShares governance model has lacked this essential capability. BitShares suffers from not having a way to easily and inexpensively obtain feedback on proposals and to build consensus on a set of priorities. We talk talk talk but never reach a conclusion on many worthy ideas.

Just look at how much effort has gone into the work @custominer has done for bringing back interest on BitAssets.

It all boils down to planing and getting buy-in from the shareholders to support that plan. It's not easy obtaining consensus in a decentralized organization like BitShares. An on-chain voting / polling method will help to address this, however some thought is needed to create a method that doesn't allow spamy polls to flood the system which would render the polling ineffective due to the "noise".

So my primary question would be, how is it decided who or what poll questions can appear?

Would a moderate fee be enough or too much to limit proposals to poll? If only a finite number of poll slots where available each month (and that would make it easier to design a wallet GUI to present the poll questions to sharehholders), could an auction be used to fill them? I'm just thinking out loud here. The idea deserves some thought to refine it into a useful addition to our limited governance capabilities. Some type of periodic (monthly) set of polls to review, so that people can know on a regular, scheduled basis when to tune in and be prepared to cast their vote in the proposal polls.

Perhaps a method like @fuzzy uses to decide the order of speakers on BeyondBitcoin. - use Steemit to gather support and decide ranking for a set of polls / proposals to be made formally on the BitShares blockchain. That can be used as a method of triage to weed out trivial or "this will just help me" polls. If the steemit article can't reach some type of predefined upvote threshold it isn't worthy of being included in the formal list of poll items.

[rnglab]

We have to take some fundamental development decisions to properly feed back this growth, and to keep the platform ready to evolve and scale as needed.
Besides many (not yet prioritized) priorities, we have at least 4 different approaches to evaluate regarding EOS integration.


It's not easy to design a feature and write a BSIP to create a worker proposal, even worst with no clue about its chances to be accepted.
Then if downvoted those efforts are gone, without even knowing if it was rejected because of the asked budget, the feature itself or its priority.
Chances are devs getting discouraged to gather feedback again to improve the proposal or to create new ones.


If we don't set some mid/long term guidlines and a stable development budget, most Graphene devs will probably find better incentives just working with EOS instead of doing colaborative Graphene work for integration and sinergy, not to talk about self BitShares features.

EOS has already raised deep interest in many of our devs. Personally, I think in the short term we will need a core dev team with the hability to evaluate and socialize in a case by case basis the pros and cons between hardcoding a feature into BitShares or interacting with EOS

What I think we actually need as a priority, as a starting point to achieve further consensus regarding development and what not, is a way to improve on-chain polling.

The first feature that I'd suggest towards BitShares v2.1 is to add the hability (for lifetime members maybe?) to create polling workers from the Graphical Interface, and a dirty hack to show them just as polls in a separate tab.
Non ivasive notifications for new/unread polls may also help to rise engagement and vote participation.


On chain polls won't be decisive, but a good way to know what the majority thinks that needs to be done first, and how much would they let the network to invest on it.
Same for devs with new ideas, they would be able to find out if their proposals raise interest and if the budget would be accepted before creating a BSIP.

 
Hopely, the committee-account will become soon a diverse and active team with incentives ehough to follow development closely, but we really need a way to define immediate priorities before that happens.


I'd like to have a technical discussion about its viability and conveniency.

Prediction markets for decision making could be an option to, but probably harder to implement and to gain adoption in the short term.