I loved, and still love, the original concept of decentralized “manager nodes” that perform network actions, rather than a single blockchain. I would love to see this idea come to fruition.
Every now and then I pop into the forum to see how much closer we get to launch. The main Roadmap only shows Farming left, but it’s clear from the weekly updates that is not the case. I wish the project great success, but I find the lack of a clear roadmap quite eyebrow-raising. I’ve seen some posts about it periodically.
So this is a request, from someone with great interest in the project, to get a proper roadmap we can all follow along with. Any project manager with experience knows that without a centralized roadmap with a proper task list it’s impossible to know the state of a project, if it’s still on track, and what needs to be done to finish it.
For example, you could pin a “live” forum post that is constantly edited with checkboxes:
Overall task A
Subtask A
Subtask B (in progress)
Sub sub task A
Sub sub task B (in progress)
Authority refactoring [example from the last update]
Overall task B
Of course, as issues and inefficiencies arise, tasks can be added and removed. But the whole to-do list is always current for everyone to keep track. Another alternative is a github task board that is kept up-to-date (not github issues, those are too detailed.)
It seems this would alleviate a lot of the doubts many are having, including myself, especially those with a stake in the project. @dirvine et. al. what do you say?
I just read a bunch about how Watson and Crick discovered the importance of DNA. They had the same issue. When breaking ground, then, it’s hard to know what lies ahead and what needs to be done.
The very best project manager in the universe cannot manage innovation, it’s just a fallacy.
We have a github repo that is jammed with what we are doing and the PRs do read well. So the list of the bugs and how they are attacked, even experiments, is all there. It’s very very fluid and very fast-moving.
I am really sorry, but this is all heads down and asses up for us and we know what we need to do and that is fix what appears in front of us. There are pain points with comms right now, some consensus flp related small things, some work on DBC payments for data and so on, but these move fast.
Every single Engineer working on this would love dearly a wee map/plan/scrum chart/burndown chart that would identify what we will face next, but even God cannot give us that if s/he existed
So it’s all work smart and work hard for us folks. We do try to be clear weekly on what we are doing, but a chart of bugs or whatever does not exist. When this works then we will know it, and probably the last bug that lets it work will be unknown to us.
We can write it all down in a list, but only looking back I am afraid.
So here am I again defending this innovation and annoying the hell out of project managers and making marketeers mentally crazy, but this is what I feel we need to do, it’s all we know.
My understanding of future developments (I could easily be wrong though), is “node membership, economy, stable api”.
In more detail:
node membership needs fine tuning
connection management (messages between nodes can be reliably sent and received)
consensus (messages are understood and acted on correctly, mostly in relation to node membership and authority)
without these the network nodes don’t sync up and work together, so it’s critical to get this right because everything else depends on node membership working properly.
Once a stable network can be run and data stored/fetched in a very basic way, the next phase of development can begin (and is already being worked on)
further consensus work, mostly on data persistence and node dysfunction (as opposed to node membership and authority in the previous step, this is about the data, not the nodes). Without this data permanence is not 100% certain.
economy, ie finalizing:
storecost (seems mostly done)
rewards (seems still mostly not done)
dbcs (seems mostly done)
without the economy the network is too vulnerable to spam to be considered useful or permanent
stable API
Apps can be developed
nodes can be run
the network might be considered live at this point
Stable api is the most important part for having a useful network, but can’t happen until the economy and consensus work is complete. The underlying network data types seem to be done, but the full set of available operations and errors is still not complete because payment logic is not finished yet. I feel like a ‘happy path’ app could be developed, but anything that would give an error is not concrete enough yet for app devs to feel comfortable.
Then the really difficult work will begin
automatic node updates
continuous improvements to client control of data, eg content filtering, ownership management, search and discovery, data conflict resolution (ie crdt fork+merge), improving key management and data migration… so much to do here.
performance optimizations such as cache layers
responding to legal and political and social consequences
I don’t think tracking tasks is useful. Probably at this stage it might be useful to have a monthly or quarterly look at what’s been done and what’s anticipated to come next. Not sure though since the work being done is hard to quantify and foresee. I wish the boxes could be ticked but that doesn’t seem to be how it works.
Hi Ephi, great to know you’re still taking an interest. I hope all is well with you. I also hope you get involved again when the time of right.
I have been here all the time since 2014 and seen several attempts to maintain roadmaps all fall away because they don’t add value to the team. I’m sure they each have tasks in mind, but with relatively short horizons so whenever someone tries to use that to go all the way to launch it quickly becomes apparent it wasn’t good enough and not a good use of time.
Many years ago I was lucky enough [cough] to work at a technology company that did contract research and development so the issue is very familiar.
I’m still here and still optimistic despite numerous roadmaps proving of little value in measuring or predicting progress.
Why? Because of the determination and quality of David and his team.
This seems timely and appropriate as Coolio passed recently:
I find it amazing and also worrying that a road map to launch with articulated purpose cannot be created, especially at what we are told is nearing completion of the project.
What’s even more concerning is if @dirvine walks out in front of a bus tomorrow……where exactly would this leave the project?
@WeeBert If David walks out in front of a bus presumably he’d dodge and dive out of the way, as a former boxer. But even if he didn’t, read the above there.
Unlikely, the bus service in Davids part of Ayrshire is so infrequent, he’d need to time his careless walk into the traffic extremely carefully.
Need to keep a close eye out for tractors, though…
Don’t discard your Creak-o-matic Leather Jacket of Invulnerability just yet, David.
Essentially still in good hands. It’s not me but a whole team involved. In the last 3-4 years I have been involved in so much non safe things that the team have had to take over and they have perfectly. I am back in play now but I don’t need to be.This team has it all and little ego which is amazing.
Thanks for your ideas here. We tried agile a while back and found it less helpful to us.
As a small group, it’s much faster for us to hammer what appears in front of us. There has been a big issue in our comms and clearing that up (happening now) we open up a whole new bit of clear water. Right now it’s that push to kill all bugs in any place in our code. That is not plannable in any way, it’s purely jump in and get it done.
When we get this sorted then we need to get the API story correct, but there we won’t plan it. We will instead create simple APIs and get the community and us to build apps. We will keep that very lean too.
I am no fan of Jira, in fact I find it the worst thing for progress unless you are a big corp with layers of managers and reporting, even then I find it to be cumbersome.
We are all different though and that is good, every team is different and that is also good.
DevOps or DataOps approach also has some good key principles to learn from and might also be interesting to collect certain performance data although can also easily be calculated from the github repo. E.g. lines of code released and consequent bugs/patches applied, logical lines of code, test unit comprehensibility, etc. For many regular projects agile seems to do but in your case, at least for now, it’s really getting the bugs down and creating more understanding to tackle those unknown spaces and functionalities.
Still good to keep track of LOC, LLOC, SLOC, perCOM (% of comments per function). Can give more insight to team member where things are still lacking and easier to evalute how it works and what might need to be done.
CI/CD which already is working also great improvement.
A shared Jira high level project (or similar dashboard etc) would provide some visibility for the community and perhaps help with some of the doubts/questions @eblanshey and others have. Something to help bridge the gap between code and delivery, there are lots of good tools available
