Show Posts
1
General Discussion / Towards BitShares v2.1
« on: June 25, 2017, 07:33:18 am »
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.
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.
