This exemplifies the reason why design-by-committee is doomed to languishing failure.
Engineering is trade-offs, and the best trade-off based on the current engineering constraints is a single payout window. Everything else (two payout windows, unlimited repeating payout windows, et c) impacts scalability significantly.
There are regular, deep discussions in our engineering organizations about these tradeoffs, and it would be a full-time job for several people just to communicate the minutiae adequately (to people who mostly haven't read the code).
At some point, unless you want to come and sit in our office full time (or understand the c++ consensus code in full), changes like this are going to have to boil down to "trust us, we do this for a living". I think there about 6-8 people in total on all of Steemit that have qualified opinions about the "how" and the "why" of the engineering decisions of the actual implementation of these changes.
Alternately, go and read the code, and you won't have to trust us. It's open source for a reason. :)
We are gearing up to support a lot more users and posts, and have identified the scalability chokepoints and have a plan to eliminate most of them. This is crucial to that plan, at the expense of a tiny dent in UX (it would be lovely to keep 24h payouts, and payout indefinitely, but those implementations simply will not scale as we grow).
This is an important comment. Frankly, I don't believe in decentralized design-by-committee. It is painfully obvious that a small team with a singular vision is a much more efficient at a creative pursuit of any kind, including software development. Open source allows contributors to fill in the gaps, point out the bugs, but there needs to be a focused vision. Steemit Inc. got the platform running rapidly within a couple of months, while competitors are yet to show up with a usable product after years. That was obviously a result of a small team working in a focused manner. Since then, progress has been far too slow.
I have read through your comments in this thread and you make compelling arguments for each. This is enough detail to let us trust you - we don't need to know the exact code, though of course it helps that it's up for examination.
Here's the significant blunder on your part - much of this communication should have happened in January, and not one day after the hardfork was due. Or at worst, last week when witnesses weren't able to reach consensus. I look back to the original proposal post from early January with considerably concern from the community, yet there's little to no feedback from anyone at Steemit, Inc. Worse still, you went ahead and coded features that the community was clearly against, and no one bothered to argue otherwise... until it's too late (now). Had clear communication like ones you have provided above been done then, we would have saved weeks in time we can't afford.
My recommendation would be to clarify and communicate every detail with the community when you make your initial announcement proposal for the next Hardfork, and make sure there is consensus, before you get down to serious coding. This way, the hardfork will go through smoothly once the code is ready. It's fair to say we have lost months overall due to miscommunication.
I hope all of this will be part of the new Steem development procedure that you have teased. Eagerly awaiting your post for the same.
Keep up the good work, and hope to see a faster development pace in the future!
I agree 100%. All I can say on the matter is that I wasn't managing the backend development team then. I am now. People who know me know that I don't work like that. :)
A-fucking-men.
That is exactly the plan, and we're already revising the drafts of the announcement post for the new process. To do it any other way wastes your time and ours. There will be a schedule, so you will know what happens and when, well in advance.
[Nesting limit, can't wait for that to go away!]
It's very encouraging to hear all of this. Thank you for replying - awaiting details on your announcement post. All the best, I'm now optimistic about the future development pace.
Beginning with getting Hardfork 17 pass, of course. It can only be done with clear communication with the witnesses.