the timeline is not clear, the disjoint part or secure message relay is already done according to the team but still is as to be completed according to the timeline…
I personally do not really feel the need to have specific timescales, and I think they can do more harm than good. IMO it’ll be done when it’s done, and I trust the team to deliver something great. Though, apparently, there’s loads of people that do want these timescales, for a million different reasons. Either with the projects best interests at heart, or their own. You can’t really tell most of the time anyway.
To stir the pot a little more, and to maybe find some middle ground, how about this:
Add months to the timeline on the website to indicate how much work is expected to go into each step/milestone (if 4 months is expected, make it 8, just to be sure). When something is done, and it works, remove the months and add ‘DONE’.
It doesn’t matter how many months it really took to complete a milestone, but when it’s done, you can strike x months off of the timeline.
I don’t know if it’s really necessary and viable though. I know it’s pretty much impossible to label a milestone ‘x months’. Ah well, my two cents…
That may not be clear. We do the code and the code is done, but …
The code being done is part 1, it needs tested and for large things like these then we consider them done when we have working testnets or alpha releases. So code done and local testing done, but not proven in the wild, means for us, that part of the timeline is not yet proven to be complete.
OK, but anyways that means in theory the most of the work is already done right, many could have thought it still need to be solved and coded. Its not like months of work brainstorming and coding like it was with PARSEC.
Very unlikely anyway. However still not complete so not able to be marked done in a timeline. Otherwise, we will have a very complex timeline that people will complain about, many won’t understand and also hard to update if anything changes.
Thanks for your response, if you feel confortable answering: What is the next major coding “milestone” after the PARSEC/Alpha 3 is complete? Seems like there is no for Alpha4, then would it be Safecoin or is there anything before that still need to be coded?
alpha4, data, vaults, beta with test safecoin are big issues, upgrades, restarts mass node loss are all to be answered as well.
sorry for mocking, and kind of trolling but sometimes I also feel like this:
PLEASE TELL ME WHEN LAMBORGINI. I MISSED BOTH BTC BUBBLES AND SOLD XPR TO EARLY. MAIDSAFE IS MY LAST HOPE.
I CHECK PRICE EVERY HOUR, PLEASE DO SOME MARKETING SO PEOPLE BUY!11
I was working on a mobile application once. At one time I was sure it will be ready to launch next day, then something went wrong and it took two more months. And it was a silly mobile App.
have a nice and productive day everybody:)
@dirvine wasn’t safecoin previously considered easy once the network fundamentals are in place. I guess which implementation to pick is a difficult choice, but the implementation of a ‘test safecoin’ for playing with and experimentation isn’t difficult?
We have already seen vaults before, so not sure what’s big about that one either.
I’m under the impression all of the above should fall into place in relatively which succession, unless you hit a random black swan along the way.
These I accept as the major areas of work that transform the alpha network into beta.
@bochaco already has a test wallet with test coins. They may be pretty far from what safecoin delivers, but it is there if you want to play.
Why there are big issues?
Because everything has to just work. As close to flawless as humanly possible. The majority of the time will be spent tweaking things to be fail safe. At least at that point there will be lots of tests and as a result much to play with. Should keep us all busy until launch. Rarely a dull moment. Unlike now where inactivity on our part relating to the network keeps us moaning.
As @Stark says and that betas are a big step up from alphas in that betas are meant to be testing the whole system and testsafecoin is a biggie. It may not be difficult to implement but it is important and affects how people use the network. Farmers will join/leave based on many factors but for some/most safecoin issuance rates will be the main reason. How much people pay in safecoin to store data will affect the rates of new data being stores.
So once beta comes