@Panther not easy questions to answer it turns out:
How do we keep track of the ideas developed during a discussion?
There is not set process. Keeping track of 'feature requests' is done via larger list in forums, for a specific feature, there is nothing set. The answer to this I don't think changes whether we are pre-merge or post-merge of the first version of a feature. We should not expect for updates to have every feature on the first version. Merges are not indicating that a feature is done and complete and will not be touched, but it means we have a minimum, useful start. For example, detecting a scramble is a feature, displaying the warning is a feature that builds on top, and giving an option to hide/ignore or always show the warning is yet another feature. It's not just one feature, but a set of features, we should not try to build it all at once.
The feature for now has been included "as is" with the normative power of the fact.
I respectively disagree with the concept of 'normative power of the fact'. I see many shortcomings from legacy technology that have morphed from "we don't do this because the technology does not allow us to", to "it is a rule that we don't do this". We lose sight of when we don't do something because we couldn't, rather than shouldn't. Having access to the code history, a number of things are clearly accidental and limitations rather than intentional rules.
To illustrate this difference in perception, a good example is spaces in names. Many years ago, lots of code was rushed out. Shortly later, it was realized that tracking users by name is not a great thing and there are problems with it. There was more code added to handle this situation, hence why duplicate logins get the " (1)" appended to them and a rule was added to disallow spaces in names so that player tracking strategy (by name) would work. Later the context was forgotton, lost, polished over, and the original: "we hacked up some code and made a bad decision and then hacked in even more code to make it work", morphed into: "It was wisely decided and mandated that users should have no spaces in their names."
So maybe to another extent I agree actually to this "normative power", but I'd point out that a number of the norms are accident, not the results of reasoned decisions. We have the power to release frequently now, to make updates to the codebase without huge overhead, so we can change things. Before it was all a process of sending email patches to Veqryn to be included on the next release, that is a six month turn-around, something that we do now in hours.
This topic will get buried in forum history soon.
The merged feature is behind the 'beta-feature' flag. It won't come out from that for a bit. That helps ensure we keep working on it. This thread won't drop in history quite that fast.
A bigger issue is we need to decide requirements for the next iteration sooner, rather than later. If we can't come up with those requirements, the coder will do their best and will be forced to decide them where needed. If we delay on defining requirements, it's going to be a headache and lost effort.
I expect @Alexei-Svitkine will jump in at some point, summarize the suggestions and discuss pros/cons and which ones he thinks are feasible and best to continue exploring.
