sevenrustlust
Member
Offline
Activity: 112
Merit: 10
|
|
March 06, 2017, 09:44:46 PM |
|
I forgot to buy the ICO, when it will be released on exchange?
*sigh* Don't make me cry more
|
|
|
|
ImI
Legendary
Offline
Activity: 1946
Merit: 1019
|
|
March 06, 2017, 10:10:05 PM |
|
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.
|
|
|
|
teletobi
|
|
March 06, 2017, 10:34:11 PM |
|
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.
|
|
|
|
wpalczynski
Legendary
Offline
Activity: 1456
Merit: 1000
|
|
March 06, 2017, 11:32:19 PM |
|
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.
|
|
|
|
Bgjjj2016
Sr. Member
Offline
Activity: 448
Merit: 250
Ben2016
|
|
March 07, 2017, 03:11:29 AM |
|
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. EK, thanks for responding. As little knowledge as I have, I can say with confidence ( I'm sure for others as well) that you have made the right decisions in the past and you should continue doing it going forward. Nothing wrong with being a scientist and a leader the same time. You also have great supporters like Coralreefer, Unvoid, .........and many nontechnical people like me.
|
My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
|
|
|
mm2543363580
|
|
March 07, 2017, 03:50:12 AM |
|
It looks like an interesting project, I will watch carefully maybe something unexpected appears.
|
|
|
|
clivemy
|
|
March 07, 2017, 09:22:03 AM |
|
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).
|
|
|
|
|
wizzardTim
Legendary
Offline
Activity: 1708
Merit: 1000
Reality is stranger than fiction
|
|
March 07, 2017, 11:32:41 AM |
|
I think the approach with SN is better too
|
Behold the Tangle Mysteries! Dare to know It's truth.
- Excerpt from the IOTA Sacred Texts Vol. I
|
|
|
Bgjjj2016
Sr. Member
Offline
Activity: 448
Merit: 250
Ben2016
|
|
March 07, 2017, 12:12:49 PM |
|
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 !
|
My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
|
|
|
techwriterjoe
Member
Offline
Activity: 95
Merit: 10
|
|
March 07, 2017, 01:47:39 PM |
|
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.
|
|
|
|
Mrboot
Legendary
Offline
Activity: 1204
Merit: 1000
|
|
March 07, 2017, 02:15:48 PM |
|
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.
SCRUM FTW
|
|
|
|
Selsonblue
|
|
March 07, 2017, 03:53:30 PM |
|
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.
|
|
|
|
techwriterjoe
Member
Offline
Activity: 95
Merit: 10
|
|
March 07, 2017, 05:16:04 PM |
|
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.
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.
|
|
|
|
techwriterjoe
Member
Offline
Activity: 95
Merit: 10
|
|
March 07, 2017, 05:21:12 PM |
|
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.
|
|
|
|
wpalczynski
Legendary
Offline
Activity: 1456
Merit: 1000
|
|
March 07, 2017, 11:29:43 PM |
|
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.
GO ahead, please make a roadmap. Devs are busy coding.
|
|
|
|
Bgjjj2016
Sr. Member
Offline
Activity: 448
Merit: 250
Ben2016
|
|
March 08, 2017, 02:52:46 AM |
|
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.
GO ahead, please make a roadmap. Devs are busy coding. As much as most of us here don't like the word " Roadmap", it could be used constructively as an informative tool for us and attract more people to this project as long as it's not being used for pushing our devs into a time restrain . IMHO
|
My " I want that Old Toyota Camry very bad" BTC Fund :1DQU4oqmZRcKSzg7MjPLMuHrMwnbDdjQRM
|
|
|
rubiprojects
|
|
March 08, 2017, 03:45:57 AM |
|
Elastic is catching my eyes, very impressive job you have done. I wait for the official launch, for the supercomputer on blockchain revolution.
|
|
|
|
cybterpunk
|
|
March 08, 2017, 09:44:35 AM |
|
Elastic is catching my eyes, very impressive job you have done. I wait for the official launch, for the supercomputer on blockchain revolution.
XEL is the real supercomputer. i will support it.
|
|
|
|
provenceday
Legendary
Offline
Activity: 1148
Merit: 1000
|
|
March 08, 2017, 10:10:53 AM |
|
time will reward people with patience.
|
|
|
|
|