Daniel Shahaf wrote:
> Julian Foad wrote on Wed, Nov 06, 2019 at 16:07:23 +0000:
>> Perhaps one aspect of being in a mature and stable phase of a project's life
>> means that if we are going to change how an existing feature works, we
>> should not change it one little bit at a time like we did in early
>> development phases. Instead we should plan and release a set of related
>> changes all together. Instead of just changing "svn status" to not show
>> unmodified files, we should plan a set of improvements to changelists, and
>> that would be one of the changes.
>
> How do you figure this? What would be the benefit?
>
> If you say that we should plan ahead and keep the big picture in mind, I'd
> agree; but it sounds like you're saying that small, incremental changes and
> not letting the perfect be the enemy of the good were appropriate approaches
> for 0.x, while now is the time for making larger refactorings all at once…
Using the changelists UI as the example, I'm imagining if we change the
behaviour of "svn status" in the way I suggested, in one release, and in
the next release we found that made it less convenient to discover all
assigned changelists (though still possible through "status -v") so we
add an explicit way like "svn cl --list"... then in the next release we
add a way to select "the unnamed changelist" explicitly... and so on...
I feel users would get fed up with the apparently "random" bits of churn
in the feature in each release, and not consider this a stable product
to work with.
In particular, I might personally have some ideas of a set of related
changes that would lead to a better overall UX for changelists, but then
I might get as far as committing one or two increments and then never
get around to the rest, leaving the feature looking just pointlessly
modified with the real end benefits never realized.
If we are talking about non-LTS releases, we might well consider that is
in the nature and purpose of those releases to proceed incrementally and
release whatever fixes and improvements we get around to committing.
But that in itself will not result in a well planned set of changes
being ready for the next LTS release.
On the other hand, if we somehow arrange to make a (LTS, let's say)
release which says "The changelists feature has been overhauled. It was
deficient in a number of ways, so we have made a number of changes to
it, which lets it work better in <these> ways while being almost exactly
backwards compatible. Exceptions are <these>." ... That seems to me like
a better delivery.
That's to better explain what I was thinking. To take this thought to
the extreme, we would develop all changes on a branch until we think the
branch contains a complete new version of changelists. I don't know if
we would want to go that far. At least, though, it seems to me that it
would be wise to plan a group of changes that make sense all together,
and discuss whether we are happy with what the feature would look like
at the end, before we start making incremental changes. Then at least
if we make one or two changes and get stalled, we will have a collective
memory of where it was leading so someone else can continue in the same
direction instead of going off in a different direction.
- Julian
Received on 2019-11-07 12:44:18 CET