Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Some thoughts for Bitshares 1.0  (Read 512 times)

0 Members and 1 Guest are viewing this topic.

Offline rnglab

Some thoughts for Bitshares 1.0
« on: April 28, 2015, 05:42:15 AM »

This brilliant team envisioned concepts and systems almost no one imegined two years ago. They already proved being capable to make it work, in spite of (or along with) a constant influx of disruptive/highly experimental features to add into the same protocol.
We also have this great community with lots of active, committed and enterprising members full of ideas and critics (let's stay with the positive ones, that are amazing).

Having this almost perfect combination of core team and community brings an extra challenge: to strongly agree on the scope for the product, find consensus on its base features and development process. I see critical at this point to find the sweet-spot between feature set and admissible time to release the stable product.

I'd rather spend a whole week (or even a month if needed) deciding which features are key for Bitshares 1.0 so devs and we all know exactly where to focus . Too many ideas lead us to a lack on focus. Don't let a small lack of coordination to debilitate us on this exceptional project.

As far as I've been reading last days, we are talking about: reducing dilution (rethinking the way to fund projects/delegate pay rate and to undo merger or delay vesting), referral system into protocol, Turing complete scripting, merging Bitshares MUSIC blockchain, BitAssets 3.0, Bond market, etc.

I think Bitshares nature is somehow marked to be constantly evolving. Even if we can make most of this features stable in 1.0 in a reasonable time to release the full protocol at once, I'm sure we will keep getting great ideas for new features and improvements that most of us will want to see in the protocol as soon as possible. Also lots of new features at once means a lot of possible points of failure.

My point is we already have an incredibly useful and competitive product, with just a few market design and code issues. I'd suggest just to fix those issues, add the minimal BitAssets 3.0 features needed to have a good market and focus just on that for 1.0 release.

Mean wile we could take devshares one step further, encourage adoption so we can test features involving social experiments and not just code (economic, market, social and marketing related features we have no way to evaluate viability without monetarily incentivated users), so we can keep bringing features to Bitshares  in a gradual and organized basis only after extensive real life testing.
That or any other solution that may bring certainty to adopters.

Remember stability is one of our first sell strengths!

Offline Thom

Re: Some thoughts for Bitshares 1.0
« Reply #1 on: April 29, 2015, 06:14:13 PM »
I was almost done with a detailed reply to this thread yesterday, and a minor interruption and capacitive trackpad forced it into oblivion by the wave of a misplaced finger. Here I am today trying to recreate that post.

The OP has had no response save this one, and it has slipped into the obscurity of page 2 of General Discussion. But it is worth talking about, as it was when I broached the subject in last Friday's mumble. It gained more traction in the mumble afterparty when cryptoprometheus revisited the subject.

Why doesn't BitShares have a way to qualitatively and quantitatively assess what is important to the BitShares community?

I was talking to gentso the other day, reflecting on the recent mumble. He explained how Counterparty's SWARM worked and how something like that could and probably should be implemented in BitShares. There's nothing standing in our way, other than:

  • Willingness on the part of Dan / Stan / Dev staff to solicit external input more formally
  • The community's insistence that we need to be more systematic about assessing proposals and setting priorities and goals for the BitShares ecosystem

Very little if any development effort is required to implement a community polling / voting system based on UIAs RIGHT NOW. If any coding is required it would be to possibly create a special class of UIAs that require lower fees (but not too low as to result in a flood of frivolous polls / proposals) so as not to be a significant barrier to submitting proposals.

Perhaps a two stage approach could be used, where a panel of trusted community members (such as delegates) serve on a panel to review ideas and proposals and if deemed worthy, are issued a UIA for formal review of all shareholders, who vote by buying the UIAs to indicate their support. The panel can set the price of the UIA, for example a low value to encourage participation in a simple poll or higher values to encourage more serious reflection on strategic proposals or "pivot points". The results could be viewed right on BitSharesBlocks via number of outstanding UIAs that exist, for example.

I'm just trowing this out off the cuff as an idea. Our community is an extraordinary  pool of talented entrepreneurs, I'm sure we can come up with refinements of this "BitShares Swarm" concept to be a very useful tool to help BitShares realize its highest aspirations.

The point of this is not to dis-empower Stan / Dan / Dev team by empowering a review panel and shareholders. The point is to provide a better way to collect feedback from the community in a scientific and quantifiable manor rather than through ad-hock means like forum posts and mumble sessions that aren't comprehensive or very accurate. It also serves to give the community a stronger voice and provides another avenue to encouage people to become a part of the BitShares community, a place where their voice has a megaphone.

If we demand that of Adam in assessing the effectiveness of the website to attract new users and impact marketcap, why shouldn't we apply the same principles to the ecosystem as a whole? Isn't this a typical engineering problem? Aren't there a few of that ilk around here? So why isn't this an obvious thing to do, where is the resistance coming from?
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports:,23902.0.html

Offline fuzzy

Re: Some thoughts for Bitshares 1.0
« Reply #2 on: May 01, 2015, 05:50:16 AM »
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline BunkerChain Labs

Re: Some thoughts for Bitshares 1.0
« Reply #3 on: May 01, 2015, 07:01:21 AM »
I agree we should have some way.. the delegates might be the way to go... others that is.

The way delegates work in communities typically is to hold a community meeting and let everyone give their input.. questions.. etc.. then the delegate goes off to represent with all that and does their duty.. this style in our setting though would suggest that we have specific delegates out of the 101 that we have met with to represent.

I would suggest that the foundation pillars that make up every business should have delegates from/in that sector that represent bitshares holders interests in a structured manner. Identify those categories and have delegates that are qualified to represent those.. for example you would not put a dev programmer into the marketing sector to represent and address those elements. Every delegate has to have a qualified background to effectively address and potential vote on these things. Typical organizations would include in no paritcular order of importance:

  • Purchasing
  • Marketing
  • HR Management
  • Finance
  • R&D
  • Production

I would suggest two representatives within each sector to serve.

I don't agree with the idea of a simply polling mechanism to open up to the masses... I don't want engineering issues to be getting voted down by people who are not engineers for example. I don't want marketing issues to be decided on by programmers... etc. This should not operate like a citizenry per say, but essentially as an organization... and the best interested of the organization call on allocating the best qualified to address each element.

As for how to select these delegates.. I know this is going to sound weird to everyone, but I would suggest a Baha'i style election process that's based in equality, freedom, nobility, and unity. This means there is no electioneering, and everyone is qualified to be voted for to become the delegate. Community votes and whom ever is voted for has to fulfill their duty in that roll. Prior to voting the community would reflect on the needs of the positions, and take into consideration the character and qualifications of everyone they know of to effectively fulfill it and cast their vote. The majority voted for then becomes the delegate in this instance to represent the interests of the community relating to input.

Nominations are not part of the process because they remove our freedom.

There is more on the Baha'i election process in this thesis someone did at McGill Universtiy on the subject that I found rather well done: in case you are interested in exploring it more. Or you can just say yes to what I am recommending.. I'm good with that too. :)

In practical execution terms.. this could be accomplished with a simply db of usernames and a form where two selections can be made from the DB in each sector with a submit button at the end. Give a time frame for the voting and have a team of three manage over the data to verify the counts at the end and report on the results. Something like that.

Do it once every quarter or bi-annually perhaps.

Anyways thats all I got to say on that for now... must sleep.
+-+-+-+-+-+-+-+-+-+-+ | World's First Decentralized Tournament Platform Built Entirely on the Blockchain!