> ... in this post I will argue against frequent soft forks with a single or minimal
> set of features and instead argue for infrequent soft forks with batches
> of features.
I think this type of development has been discussed in the past and has been rejected.
Matt: Follow the will of the community, irrespective of individuals or
unreasoned objection, but without ever overruling any reasonable
objection. Recent history also includes "objection" to soft forks in the
form of "this is bad because it doesn't fix a different problem I want
fixed ASAP". I don't think anyone would argue this qualifies as a
reasonable objection to a change, and we should be in a place, as a
community (never as developers or purely one group), to ignore such
objections and make forward progress in spite of them. We don't make
good engineering decisions by "bundling" unrelated features together to enable political football and compromise.
AJ: - improvements: changes might not make everyone better off, but we
don't want changes to screw anyone over either -- pareto
improvements in economics, "first, do no harm", etc. (if we get this
right, there's no need to make compromises and bundle multiple
flawed proposals so that everyone's an equal mix of happy and
miserable)
I think Matt and AJ's PoV is widely reflected in the community that bundling changes leads to the inclusion of suboptimal features.
Even worse is the "horse-trading" sort of compromise: "I object to
your proposal for such-and-so reasons. You object to my proposal for
this-and-that reason. Neither of us agree. If you stop objecting to
my proposal, I'll stop objecting to your proposal and we'll put them
both in." That again results in an "agreement" of sorts, but instead
of just one outstanding unaddressed issue, this sort of compromise
results in two, again ignoring them for the sake of expedience.
These sorts of "capitulation" or "horse-trading" compromises have no
place in consensus decision making. In each case, a chair who looks
for "agreement" might find it in these examples because it appears
that people have "agreed". But answering technical disagreements is
what is needed to achieve consensus, sometimes even when the people
who stated the disagreements no longer wish to discuss them.
If you would like to advocate bitcoin development run counter to that, you should provide a much stronger refutation of these engineering norms.