Front page | perl.perl5.porters |
Postings from December 2017
On Fri, Dec 29, 2017 at 6:57 PM, Zefram <zefram@fysh.org> wrote: > Leon Timmermans wrote: >>I'm not aware of any other major open source language that quite dumps new >>features on their users like we do. > > We've got feature flags and experimental status to manage this. We mostly > stopped just dumping new features onto users years ago. I think you missed my point. That is not really a replacement for actual communication to our end-user base. A conversation I had the other day with Salve did make me realize I forgot an important stage in my post: user testing. Let some users from outside our echo chamber play with it and then ask them what they thought of it and look at what they did with it. Use this as input in the iteration process. Essentially, we're using experimental status for that now. This is like a REPL to the community with a roundabout time of a full year/release cycle (if not longer). We should strive for something faster with more effective ways of communication. As far as I'm concerned pulling an experimental feature entirely should be an ejection seat, not a normal feature of the airplane. > [smartmatch] >> Late in that discussion changes were introduces >>with compatibility consequences that weren't immediately recognized as >>such; > > What specifically are you referring to here? I don't see anything > matching that description. The only compatibility consequence that > I see that was not immediately spotted was the issue of the "switch" > feature being on by default for some existing version bundles, which > interacts with the changes in keywords, but these changes didn't really > start "late in that discussion". I also doubt that thinking about it in > advance would have spotted that issue. It certainly wouldn't have made > a difference to the resolution: if the changes hadn't been reverted, > I was going to tweak the feature flag setup, in exactly the same manner > that I would have if I'd been aware of the issue in advance. Splitting when into whereso and whereis meant that it is no longer possible to write code using the switch feature that works on both 5.26 and 5.28. That gives a completely different kind of transition than was the case before. >>Only after that one can actually design the feature. > ... >>After that, "Someone with time on their hands" can actually implement it > > I reject the notion that a waterfall process is a good approach in general > or that enforcing such a process would solve problems. Issues often arise > during development that were not apparent before touching any code, and > spending longer before touching any code doesn't prevent that happening. > If you enforce the sequential requirements-design-implementation process > then that just means that you can't address these problems when they > inevitably arise. I don't mean to waterfall at all, I said "reality is probably iterative". I do mean that we need to explicitly say "this is what we're trying to do, and this is what we shouldn't". We tend to focus too much on the "how" and too little on the "what". LeonThread Previous | Thread Next