Hello everyone,

It’s exciting to see so much self-organization, collaboration and brilliant feedback going on to accomplish all we’ve accomplished already.  Thank you all for working so hard, wanting to work with us.  I can’t tell you how inspiring that is to see you all working so hard for this.

I’m noticing that some teams seem to have advantages over the others, like the Zibtek team, which is local to Jim and myself.  For all the other teams, the best we could do is use skype, and fight painfully different time zones, for our one-on-one meetings last week.  But for Zibtek, Jim and I just drove 10 minutes to meet them, face to face, in their headquarters, in our time zone.  That was so nice.  Also, the Iffort team is sponsored by Ashutosh, and the Talentelgia team is sponsored by Varun.  While the CodeDistrict team is the only team without an inside sponsor, or someone from their country.  I think these advantages for some teams are making themselves very clear so far.  To make things fair I’d like us all to try to compensate for this unfair situation and provide the CodeDistrict team a little bit of preferential treatment to compensate.  From what I’ve seen so far, they aren’t going to need much of this.

After all, CodeDistrict was the team that started this entire process.  We were initially planning to do all this, in house, hiring individual engineers, when the CodeDistrict team reached out to offer their services.  Being critically aware of our current lack of abilities to scale up to and manage a large world class team, fast, as we want to do, I realized a company enabling us to have an instant experienced team could really accelerate things.  Thanks to their effort, pointing us in that direction, we pivoted to try to find an entire team to get us up to where we need to be, faster.  That is when we reached out to the rest of you.

I know that in many ways, it is more efficient, if we just select one team as soon as possible, which would eliminate some of the distributed teams issues we are already facing.  That would be the hierarchical solution most people would be tempted to gravitate towards.  But I see a critical long term flaw in that type of tempting hierarchical organization, that being polarization win/lose behavior and a leadership bottleneck, especially once things start to scale up.

Several organizations have expressed interest in Canonizer and we’re excited at the prospect to provide our consensus building services for them.  We can enable large organizations with hundreds of thousands of participants to hear what every last one of their participants want, in an amplified wisdom of the crowd way, all bottom up, without censoring or moderation.  We want to be able to serve organizations like that as soon as possible.  As long as the price of Ether remains above $1000, we have enough money to pay 4 teams more than $50K each per month.   And that is before we are able to start collecting real revenue from organizations that will want our services.  There is plenty of work for all of us to work on, especially till we get the system redesigned for scalability and test driven continuous integration and releases, to say nothing of improving the user interface, marketing, and all the stuff which I tend to ignore.

So, I’d like to push in that direction, with the assumption that we will keep all 4 teams, at least for the foreseeable future.  That means learning how to get our scrum teams efficiently managed, up and running, now.  Both Jacob with Zibtech and Sunny with Iffort, independently raised the issue of attempting to have different scrum masters, especially during the same sprint.  Sunny, with Iffort has agreed that it would be best to have Jacob be the scrum master, at least for the entirety of this first sprint.  For me there are multiple reasons for this, first Jacob was the first to propose this, and secondly, because they are local to Jim and myself.  I also understand Jacob has great experience working with remote teams in different time zones, doing daily scrums with them.  And Jim and I being able to access them face to face, in our time zone, has many advantages.  So, towards that end, I’m going to repost a new schedule for the scrum meetings, with Jacob/ZibTek as the scrum master, at least to get things started, after I make this thread post.

I very much appreciate Jocob for jumping out in front to get things started, and for Sunny, and the rest of you, despite your clear expressed desire to help in this position, to, instead, focus on other things so we can move forward with speed.  This is the kind of leaderless self organization behavior I value most.  It is my belief that the teams that selflessly do the jobs nobody else wants to do, better than anyone else doing their other jobs, are the teams that should receive the greatest pay.  Those that are doing that work, are the ones that should be making the decisions.  We will need to work out how we distribute canonizer recognition (and voting) shares, towards this end, at a later date.

Sunny with Iffort and I were working on the JSON spec, earlier today.  Once we got a crude draft posted, we moved onto adding a link to that in the master consensus design camp.  But Sunny was hesitant to take that leading step, having already been burned in the past for taking the lead, having someone else object to his early effort, seriously deflating everyone’s moral.  This kind of hesitancy, for people stopping to second guess themselves, when attempting to move things forward, wondering if someone else is going to object, this is what I want to overcome.  Everything initially thrown up on any wiki system is just a temporary brainstorm, it can all be fixed and improved by anyone and everyone.  If someone else is brave enough to risk jumping out in front, to get a camp or topic started, let’s all cheer for and support those first brave efforts, and help push them forward at an accelerating rate.  Then find something else that needs to be done, and do it better than anyone else.

If everyone can learn how to self organize, without needing me to even be present, then we will not suffer from the polarizing hierarchical win/lose bottlenecks that cripple all the established hierarchies.  It is my belief that if we can learn how to drive things forward in an everyone working in parallel, accelerating rate like that, rewarding whoever it is that first takes the lead on any particular task, we could become the fist self organizing team to finally start out competing all the polarizing and bottlenecked hierarchies of the world driving us apart.

Why understanding the canonizer tree structure, and how to scale production of those very fast, as close to real time as possible, is all important.

Wikipedia, like all other things, has a single source of canonized truth, making their system quite easy to scale.  However, Canonizer is different, making things more difficult to scale.

Take the Governmental Priorities topic which is basically like a party platform of prioritized planks or camps.  What is “canon” is dependent on who is canonizing the topic.  If you select the conservative “Republican” canonizer algorithm, you get the republican parties bottom up priorities.  But, you can also switch to the liberal “Democratic” canonizer, to find out what is the different priority “canon” for them.  So, we need to find a way to be inclusive, wile still managing to have a shared single source of truth.

The Theories of Consciousness topic is the one that is most developed, and now having scaling problems, because of its size and complexity.  That community uses a “peer ranking” algorithm to determine who the experts are in that community.  So, you need to canonize the peer ranking topic, using that two-level algorithm, just to get the canonized score of one supporter.  There are about 20 camps, and close to 60 supporters of those camps.  Before now, the system could do all that more than Order N squared complexity real time.  But now we need to find a better way to keep as close to real time as possible, without losing single second performance.

When you think about it, every single tree being requested from the service, could be completely unique, as time progresses - can't be cashed.  If one person, with lots of delegated support changes their support in the Mind Expert peer ranking topic.  That could radically change who is the current top ranked expert.  And THAT would radically change the canonized order of the theories of consciousness topic.  And any other topic that uses that canonizer algorithm a lot.  To say nothing about how we want to enable anyone to be able to custom design and select an even more complicated canonizer algorithm, or anyone can pick an “as of date” to canonize things, using that new more complex algorithm, to re canonize things, at any point in the past.

So, in summary, we need to first describe a JSON canonized tree structure, then start designing a way to produce LOTS of those, as fast as possible, while keeping as close to real time as possible.  Everything else is just displaying those trees and managing users, all fairly easy to scale.

Wow, this is getting exciting to watch.  Much more exciting than any sports event, because we are actually solving world problems with this game, and getting meaningful things done.

I’m getting a feeling here, I seem to feel everywhere.  People are noticing and asking, who has the authority to do things?  This is the way everyone seems to act, today, in this hierarchical based society.  To me, THAT is one of the main problems/values we need to change.

I think the DevSquad team suffered from this the most.  They were basically expecting us to give them the authority, then they will get it done, with that authority, using their proprietary system they refused to share with anyone else.  Basically, they said “my way or the highway” and it is clear they took the “highway” and never even created a “DevSquad” camp with their system design.

To me, the people doing the work have the authority.  The people that want to get something done, have the authority.  If some so called “governing body” is saying or voting no to something some minority wants, they should just do like the leaderless internet, or blockchain does with all such top-down behaviors like censoring.  They should just treat it as failure and rout around it, find enough consensus to get things done, anyway.

The Iffort team saw that something wasn’t getting done, so they jumped in and started created a consensus “Core Design Architecture” camp, and got ready to propose their design.  It just so happened, that I, at the same time, was creating the same thing.  When Iffort found this out, they jumped on board the consensus to help, and moved the first design in their camp to the consensus camp, since that was still missing.

The Zibtek team was concerned that this was premature, fearing we don’t yet have enough understanding of the system (as you can see in their reason for objecting) to move on to that level, yet.  So they exercised their right to object to the proposed change, before it went live.  This is great that they are involved enough to watch what is going on, and getting involved, not letting things go off the rails.  However, this bumps into another value I believe could be improved.  If you want to get something done, you have the authority, but you should be sure you aren’t getting in the way of or frustrating what someone else wants.

Hierarchies play a win/lose, survival of the fittest war game, where only the largest wins.  The goal is basically to frustrate or destroy everyone else, till you are the last team standing.  This is another problem I think needs to be solved/changed.  We need to change this to win/win, bottom up based, leaderless methodology, like the Internet and blockchain.  The goal is to find out what everyone wants, then get it all for everyone.  Someone else wanting to get something done, should be valued, at least as much as we wanting to get something different, done.  We should do all in our power not to get in the way of that.

It is true, you can object to a change to your camp, but you can’t stop someone from creating a competing camp.  That is why I think the “create new camp here” button, asking what others want, is the most important button in the system.  If an individual continues to object to progress, they run the risk of the consensus forking from their camp, the consensus moving to that new camp, and leaving that individual alone, who evidently wants something different than what the consensus wants.  So it’s best to do all in one’s power to build consensus, and only take the fork option as a last resort.

I think it is usually best to propose what you’d like to do, in a camp forum, just to see if what you are attempting will get in the way of what anyone else wants.  It always helps if someone else “seconds” that opinion, saying they want the same thing, basically thanking them for doing the work to get it done before anyone else.  And if you have a concern, bring it up at that point, so you can work to make everyone happy before someone goes to the all the work to propose a change to a camp or statement.

So, if someone is concerned that we don’t yet have enough understanding of the system, to jump to the architecture phase, the best way to meet that want, is to jump in and propose an actual JSON description of a canonized topic tree, then start integrating that most important “how do we produce that all important canonized JSON tree?”, into a system design with far more detail.