A block of code that is tested and proven working (you will have seen many of these parts in testnets/alpha releases etc). So like a wheel for a car, but then we put the wheels on the car. So the wheel gets designed, built, tested locally etc. then it forms part of the car. So the car build will show the project piece for putting the wheel on the car.
It shows the tasks and their dependencies, as we move on then we add estimates in person hours per task. These get rolled up etc. into subproject. Then we have to add the resources (who will work on what when) and that gives us full visibility.
Otherwise we show nothing but the complete plan and if we want it 100% accurate then we only show it when we finish the project. So open development, open management means you see it all developing. Folk are free to not look at such detail if they wish, but some do wish the detail. For us it is simple enough as this is the internal management of resources and tasks to launch, so we are only showing you what we are doing in great detail. I think that is a brave, honest and open approach, surely this is what you would expect?
I agree, and I also empathise with everyone who finds it confusing. I think it is probably clearer to folks inside Maidsafe because of implicit/assumed knowledge, not just familiarity with planning and development.
I had a similar reaction looking through it. It seemed like there were more things still to be started/worked on than I was expecting, and it was hard to understand the scope and scale of items listed. It was also confusing to have the different views of the same thing. I understand the aim here is different views for different people, but I think it is hard for people to know which is best for us, so it adds complexity to have many views, and then different views explained etc.
I can imagine the limitations of finding ways to present this without writing a bespoke tool (that further distracts and delays, so not desirable IMO) is hard and I think it is a great attempt.
I just don’t want people who look at this and are confused to think it is just them. There’s a lot of complexity underneath this, very familiar to the team, but for even close observers not clear or visible. I think it must be very hard for anyone not following closely and without technical project management experience to make sense of this. There is still the simpler, higher level web version to come. Maybe it would have been better to start with that and then present detail once people had the outline?
UPDATE: I hope there will be value in this as it evolves with time, and we see progress and elements completed. I’m looking forward to the higher level view. I think in the past those were good (simple groupings of tasks with checkboxes) so I’m hoping for that, and that they’ll be maintained over time. I think updating tends to drop off people’s todo lists, it is a big commitment (which is why the regular dev updates have been so brilliant), but hopefully those updating will find it much easier now these roadmap views are available.
It sure is. It just is difficult to interpret, at least in terms of time. And I know very well that you don’t know either, but I just cannot help making may own guesses and hopes. I try my best, believe me, but it is just very hard not to. And I have been let down by own hopes so many times now, that I’d really would like to have better guesses. I was under the impression that this roadmap would include some set dates or timeframes and so I expected that. Though I don’t know where I got that impression and if it was reasonable to expect that at all.
Here we see decentralized trust (or hope) in action. Every individual makes their own guesses without any centerpoint.
EDIT: It’s like that I have a poor connection to God and I would really like to have a good priest to help to channel it to me. It may not be reasonable to expect that, but I cannot help but feel lost without it.
This is not only brave, honest, and open, it’s going above and beyond! It should also put to rest the idea that this project is a scam. It may not reveal time, but it absolutely reveals scope. It reveals the immesne complexity, of what is being created right before our eyes. It reveals that there is no other crypto project that comes remotely close to the depth and integrity of the SAFE network! Great job!
I don’t know men. I think I read somewhere here that specific tasks which are already planned for implementation or are being implemented have some estimates in terms of person days on them? Assuming that this is true it would be pretty simple eg to estimate a timeline.
Go to Backend Board look for Flemming. Find out that 2 tasks are pending before release. 1. Node Ageing 2. Secure Message Relay (3. BLS Section Key?)
Go to Task Level Board and realise that 1. is already in planing for implementation (wait before planning is over) and 2. leaves design stage and implementation planning.
Go to the specific tasks for implementation (on their respective boards) and count the estimates. Depending on the team throughput you can divide by X.
Et voila, you have a pretty timey estimate when backend is ready for release, no?
I find the numbers in the upper left hand corner of the sub-boards to be confusing/irrelevant. For example in the task-level board, there are two sub-boards with the number one. The numbers of these sub-boards aren’t necessarily in order either. Perhaps this is some default github project board thing and can’t be changed, but thought I’d point it out.
Will the weekly updates now be focused more towards the roadmap?
such as ’ Secure Message Relay’
This stuff happened.
Blockers
Link to outstanding GitHub tasks
Areas such as network upgrades / restarts while we have heard relatively recently about R&D in these areas, are they moving onto the backlog, or are they still a background work item due to complexity and size?
The dev updates will be the project plan and where it is now, including what is being worked on and by whom. The plan i using github so links to tasks, pull requests and issues are what made us choose this path.
We still do things in house, but it all comes out into the open. So when you see RFC internal discussions then we are doing our best to clean up designs before the community get to them. I think it saves time but should never be maidsafe verses community where maidsafe defend RFC. When in the community there is no MaidSafe Engineer, everyone is a community member. We need to be very careful here as even this week we did get a surprise where a community member felt a bit sidelined and this is critical to prevent.
In any case, it is as open as I think we can be and anywhere you or others see where we can improve or we miss things, the we want to know. Of course we want this automatic as possible to ensure it is updated as the team progress work etc. I can only see this being more open through time, even if that means simpler to understand.
This is great and all but my question is how up to date will this stay? I mean after a couple months of updates will it still be up to date or will it be out of sync like the primer was?
Good point. I knew Maid had a strategy issue and I think you’ve hit the nail on the head.
Get hacked, transfer client money from… say the charity arm of Maid, into the dev company, and then do an ICO but change a letter, like ECO or IEO. Guaranteed $1bn influx. Marketeers Go!
Hey @TylerAbeoJordan - you are right, they are a default feature of github boards which can’t be changed. Its an indicator to show how many ‘cards’ are in each column, and not a sequencing order. Sorry for the confusion
