maybe a one step at a time approach is best - another round of testing with more votes per block for faster election/de-election of Masternodes, plus your own/elbandi's UI improvements?
Yes, a detailed road map with dates.
1. Clearly bring round 2 of testing to a public end.
2. Publish a brief summary of the results of round 2.
3. Decide and announce what's to be tested in round 3, with a timeline
4. Detailed planning of round 3
5. etc.
If the de/election process was about 10x faster it would be a great start.
Okay, but first we (I) need to understand why Mr Spread didn't make it 10x faster in the first place, i.e. we (I) need to discover and assess the tradeoffs involved.
Tangentially, I think the group could/would benefit a lot if technical discussions were to be held on github in the context of a new (membership-driven) spreadcoin-project github organisation that would offer a bit more structure for us to cling to (making effective open-source group decisions is hard enough as it is). Github offers a usefully practical workspace: issue ticketing, milestones, etc and, as an open source project, there are lots of quite generous closely-associated options open to the Spreadcoin development team w.r.t, to continuous integration / build etc.
Github repos come with a wiki and a web site, it seems suboptimal to have content owned and hosted by an individual when it can be collectively owned, maintained and hosted for free --- or at least until the Spreadcoin “community” (for want of a better word) develops more formal principles of self-administration and collective curation of commons-generated value.
As regards the UI and other blockchain-neutral wallet enhancements, it's all up in the air. I agreed with the poster in the darkcointalk thread who found fault with the lack of public vision. It's problematic in that there is no coherent vision for functionality - in contrast with, say, the Clams wallet and the latest SecurityCoin2.1 wallet.
Cheers
Graham