On Fri, Feb 7, 2020 at 4:43 PM <[email protected]> wrote:
> On 2020/02/07 09:19:03, hanwenn wrote:
> > On 2020/02/06 14:29:55, Dan Eble wrote:
> > More code means more maintenance liability, so unless
> > it either solves a problem, or it simplifies the existing system, it
> would be a
> > net negative.
>
> You're preaching to the choir.
>
Thanks; sorry for the lecture.
> I would really like the problem defined before we try solving it.
> [...]
> > I hope I am not demoralizing you
>
> It's a good thing you threw in that last part, because from over here it
> was sounding rather like you resented my posting this for review. I'll
> try to keep my reply descriptive.
>
I was confused by the review, because it both claims to be experimental
("maybe never"), but also asks questions that are only relevant if this is
going to be a bona fide feature (editor configs, naming). The latter part
motivated the lecture.
I have seen that mailing-list discussions on detailed design--even for
> features people recognize they need, but especially for those they
> don't--do not go far or fast. I suppose it's because few people have
> the level of familiarity, the current interest, or the time to devote to
> written communication on those topics. I'm not blaming them; it's just
> my diagnosis. Posting a review gives them something concrete to comment
> on, and that gets a discussion going.
>
> I have the sense that most of my successful contributions have gone this
> way. Is this approach as effective as one that might be taken by a
> professional software development team? No, but my code is in LilyPond.
> Are the factors that make this the most effective approach in this
> context going to change? Not likely.
>
You have a good point, but hopefully, I will be able to make enough time to
comment on technical feasibility so design questions can get better answers
henceforth.
--
Han-Wen Nienhuys - [email protected] - http://www.xs4all.nl/~hanwen
