Topic: [ANN][XEL] Elastic Project - The Decentralized Supercomputer - page 133. (Read 450523 times)
Elastic is catching my eyes, very impressive job you have done. I wait for the official launch, for the supercomputer on blockchain revolution.
I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
GO ahead, please make a roadmap. Devs are busy coding.
I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
GO ahead, please make a roadmap. Devs are busy coding.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
1. Scrum / agile has worked in geographically dispersed dev groups in the past (my experiences) - but there has to be 100% buy in and a good amount of daily communication. - Both of which are probably not going to happen at this late stage of development.
2. We all want to be informed and such. But it wouldnt be worth spending an hour or two to produce a roadmap when there is "not much left" to begin with.
If you want to suggest ways to assist with the project, research use cases, help prioritize the PR campaign or development ideas; you need to bring the discussion to slack and discuss! Clivemy and myself (boardwalk), jibble, coralreefer, bgjjj, and others are in there discussing the PR stuff almost daily. The more the merrier right?
Also, We have publicly available PR and development backlogs created -- Coralreefer (miner software dev.) has given a good amount of detail on what he sees as his next tasks for miner development. These boards are updated as developments take place. Use them as your first source for info.
PR tracking: https://trello.com/b/2efzgZZT/pr-tasks
Development Backlog: https://trello.com/b/fPdyn5Vp/development-backlog
EK is at the point were his time is better spent coding. Trying to write release notes / project updates before he figures the code out is a nearly impossible task. You cant switch to agile / scrum mid way through a development cycle and expect a better outcome. Patience is a virtue.
"EK is at the point were his time is better spent coding." completely agree.
I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
SCRUM FTW
I may be interpreting your comment wrong. Scrum is a term borrowed from Rugby with similar meaning. It is simply the daily standup meeting and those involved form the scrum. Scrum and Agile go together. Sometimes those terms are used interchangeably. Agile is the idea of short iterations and sprints. It creates the ability to adapt with agility.
It's very easy to get lost in the idea of continually adding features. I think the devs should commit among themselves, not really on here, that this should be the last really big feature update before release. Of course, this is barring an absolutely necessary feature. The SN feature is somewhat optional but I agree with EK's statement that it should be implemented now because it will cause too much pain to implement with an app that is already in production/maintenance phase.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
1. Scrum / agile has worked in geographically dispersed dev groups in the past (my experiences) - but there has to be 100% buy in and a good amount of daily communication. - Both of which are probably not going to happen at this late stage of development.
2. We all want to be informed and such. But it wouldnt be worth spending an hour or two to produce a roadmap when there is "not much left" to begin with.
If you want to suggest ways to assist with the project, research use cases, help prioritize the PR campaign or development ideas; you need to bring the discussion to slack and discuss! Clivemy and myself (boardwalk), jibble, coralreefer, bgjjj, and others are in there discussing the PR stuff almost daily. The more the merrier right?
Also, We have publicly available PR and development backlogs created -- Coralreefer (miner software dev.) has given a good amount of detail on what he sees as his next tasks for miner development. These boards are updated as developments take place. Use them as your first source for info.
PR tracking: https://trello.com/b/2efzgZZT/pr-tasks
Development Backlog: https://trello.com/b/fPdyn5Vp/development-backlog
EK is at the point were his time is better spent coding. Trying to write release notes / project updates before he figures the code out is a nearly impossible task. You cant switch to agile / scrum mid way through a development cycle and expect a better outcome. Patience is a virtue.
I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
SCRUM FTW
I see the community support for SN. As long as the devs who will be implementing the solution are onboard, then I'm onboard.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
Could we share a roadmap? It does not necessarily need dates, yet.
I suggest running an agile type project management style. Perhaps make a larger roadmap, but only give dates for specific goals that can be completed within 2-3 weeks. Choose your sprint cycles 2 or 3 weeks. So only commit to any work for the 2-3 weeks and don't worry about dating the roadmap beyond that.
Hi EK, Should we ( rest of us here) work on the advertisement, website, signature,.... or should we wait till SN is completely implemented? Thank you !
I think the approach with SN is better too
Go for SN
Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.
I completely agree...and I would prefer if we took this approach as well. However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.
Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.
I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.
So would it be possible for the community to get to vote on whether we wait for a complete version to be released (with SNs, Guardnodes, etc.) or release a 'proof of concept' now?
It would be nice to have a complete list of all the pros and cons involved with releasing now or waiting for a more completed version.
For example:
PROS
A two stage solution would mean that we have a 'proof of concept' model we could release now
We'd have a roadmap (stage 1, stage 2, etc.)
We could begin a PR campaign around that
Attract more developers to help with Stage 2
CONS
More development time required to release a more completed version that has SNs, Guardnodes, etc.
Allows for a more developed model to be released
Less time consuming for the developers in the long run if a completed version is released, rather than releasing in stages
(sorry, I can't think of a 4th reason, but you get the idea).
It looks like an interesting project, I will watch carefully maybe something unexpected appears.
Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.
I completely agree...and I would prefer if we took this approach as well. However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.
Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.
I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.
Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.
I completely agree...and I would prefer if we took this approach as well. However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.
Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.
I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.
I'll support upgrading the miner for whichever way we go (which I assume using SNs). I'm just worn out and tired of reading page after page of posts about how any minute the code would be ready...it really takes the fun out of working on this.
Makes it hard for me to just read this thread never mind for you guys putting work into this. All these noobs whining and coming across as so demanding and ungrateful despite the seemingly insincere pats on the back associated with each whine and complaint.
Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.
I completely agree...and I would prefer if we took this approach as well. However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.
Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.
I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.
If you feel comfortable with going straight to SNs i think go for it. Just wanted to bring up this option in case rudimentary network would be an easy thing to do.
Take all the time needed to get a good Solution.
Two stage solution would make sense. First rudimentary network, then SN-network. Gives lots of room for testing and process of thought.
I completely agree...and I would prefer if we took this approach as well. However, last I heard from EK, he still wanted to move forward with the SN approach for the initial release.
Well, for weeks now we have moved towards the SN approach. I mean, sure, we can stick to the rudimentary network for the start. But imho this will be more complex than going the last remaining meters towards the SN approach. Why? Because then we have to put a lot of work in getting the Java ElasticPL interpreter and the xel miner's C based interpreter in sync.
I do not want to decide anything, I am just saying that getting the SN ready is the quicker solution.
If you feel comfortable with going straight to SNs i think go for it. Just wanted to bring up this option in case rudimentary network would be an easy thing to do.
I forgot to buy the ICO, when it will be released on exchange?
*sigh*
I forgot to buy the ICO, when it will be released on exchange?
*sigh*
I forgot to buy the ICO, when it will be released on exchange?
Jump to: