On Thu, Jan 04, 2018 at 10:23:57AM +0000, Paolo Invernizzi via Digitalmars-d wrote:
> On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
> > [...]
> 
> I'm missing Kenji...

Me too. :-(  Does anybody know what happened to him? He just sortof dropped off the radar suddenly and I haven't been able to find out where he went or what happened to him since ~2 years ago.


On Thu, Jan 04, 2018 at 11:29:20AM +0000, codephantom via Digitalmars-d wrote:
> On Thursday, 4 January 2018 at 07:47:41 UTC, H. S. Teoh wrote:
> > It all comes down to who's doing the actual work vs. who's just telling others what they think they should be doing, which rarely, if ever, works.
[...]
> I think that view really needs to be challenged.
> 
> Those who might be willing to contribute are probably not sitting around waiting for someone to tell them what to do. On the other hand, there may be legitmate reasons why they are not just getting involved and doing things.

I'm pretty sure there are legitimate reasons for not getting involved. But the point is, at the end of the day, *somebody* has to do the work. And since this is an open source project, we are all volunteers (except perhaps for a few that are being sponsored by the D Foundation). Experience has proven time and again that telling volunteers to do something other than what they're currently doing just does not work.

You can have all the most legitimate reasons and the most sound arguments, but the fact of the matter is, volunteers in an open source project aren't going to do what you tell them to do; they're going to do what interests them.  This isn't just in D; it's the general pattern across the majority of open source projects.  The best arguments are not worth much when it comes down to how much work is actually getting done, which, at the end of the day, is what counts.

So, one can choose to be part of the noise, or part of the real work. If you don't like the way certain things are done, then step up and do it differently. Usually, within reason, the result will be that you get noticed, and then you get granted the privileges of making things happen.  Or you can choose not to participate, which is perfectly fine, but in that case nothing will change.  That's all there is to it.


> I suspect, and I could be wrong, that a lack of clear process could be a matter of concern. I also suspect, and I could be wrong, that working out where best to exert their effort is not as simple as just finding something that interest them.
> 
> I also expect, that not everyone using D, or using these forums, need to be, or are equipped to be, contributors to resolving D's bugs. Such people should still feel free to express their concerns, without being told that they should go and do something.

You are always free to express your concerns. My point wasn't to discourage anyone from doing so.  Just that doing so only rarely leads to actual results.  Sometimes, if you're lucky, some sympathetic volunteers will pick up the tab and do the work for you, but that only happens rarely.  The way I see it is, I could choose to complain and moan about why X, Y, Z aren't being done right in D, or I can choose to dive into the work and actually get things done. One choice leads to not much happening, and the other leads to change.  To me, it's only logical to choose the path that leads to change, rather than the path that's been proven time and again to be ineffective.  But that's just me. *shrug*


> Software quality is more important than ever, as it can impact us in dramatic ways these days. D needs to have quality assurance process in place to ensure that D's repository of bugs are appropriately being assessed, categorised, prioritised, and actioned - and this needs to evident to all.  Then and only then, wil willing contributors be better positioned to make decisions about where to exert their effort.

And how are you measuring software quality?

If, and this is just pure speculation on my part, you're basing your perception on the bug count, I'm sorry to be the one to break the bad news to you that *all* software projects are full of bugs. If you're lucky, they're "only" in the thousands. Most real-world software projects have more than that, in fact, sometimes orders of magnitude more.  Most proprietary software houses deal with this by simply closing bugs they deem unimportant, or have been "inactive" for some arbitrary amount of time.  This certainly helps to keep the bug count down, and it certainly helps to make people feel good about themselves, but it does not mean that the software has better quality. It just means that we've willfully "forgotten" about the bugs that still exist.

My preferred approach, and I'm glad that D has been taking this approach, is to be honest and admit that yes, there are still thousands of open bugs.  The brutal fact is that *all* complex software have these numbers of bugs, and one might as well admit to oneself that there's room for improvement. Being honest with oneself and recognizing that there are problems is the first step towards a solution, and an actual increase in software quality. Sweeping things under the carpet ain't helping the actual code quality any.

Furthermore, a good number of bugs in bugzilla are enhancement requests, so they don't really represent flaws in the current implementation of D, just that there's more room for improvement. If a piece of software ever reaches the point where there's no more room for improvement, that's when that software project is as good as dead.


> I see this a problem for the D Foundation to address, and not something left up to the randomness of the open source development model.

That's a decision for the D Foundation to make, not for us.


On Thu, Jan 04, 2018 at 12:36:58PM +0000, codephantom via Digitalmars-d wrote: [...]
> 1000's of bugs suggest to me, a lack of QA.

Nonsense. All real-world software have thousands of bugs. If you're lucky, that is. Most have a lot more than that. Today's software is complex enough that many of these bugs are non-trivial to fix. It does not necessarily correspond with the lack (or not) of QA.


> A lack of QA suggests to me, a lack of concern for the interests of users.

You seem to have an overly-simplified, idealistic view of QA. In my experience, the existence of a QA department does little in terms of actually eradicating bugs from software. What it does, especially in an enterprise environment, is to encourage coders to hide problems because they don't want the QA people to constantly be breathing down their necks about long-standing bugs that are non-trivial to fix. It's either that, or they are motivated to implement quick-n-dirty hacks instead of addressing the fundamental problem, because they just don't want to deal with the issue right now and implementing hacks instead of real solutions keeps the bug count down (makes them look good and makes the managers happier), keeps QA off their backs, and keeps them on schedule against unreasonable deadlines.

Now I'm not saying D doesn't need to improve its QA process -- that would be quite welcome, in fact.  But don't be so naïve to imagine that that alone is going to magically solve our problems. It may create new ones instead.


> There are numerous research papers in this area, some of which I am in the process of reading, to gain a better understanding of QA in open source projects - and apparently it's a real issue of concern to those researching this topic.
> 
> Anyway, as I go through these research papers, I suspect that it is unlikely they will conclude that bugs are just a part of software, and that's just life.. and least.. I hope not.

Unfortunately, the fact of the matter is that software is complex, and especially in this day and age, of a scale where the complexity is beyond an ordinary person's ability to fully grasp. Anyone who tells you otherwise has no idea what they're talking about, and/or is trying to sell you snake oil. Turing-completeness comes at a cost, and part of that cost is manifested in how a large software project becomes so complex that no single person can possibly understand all of it, and therefore any change that one makes is bound to cause unforeseen, unexpected, or unintended consequences somewhere else in the system. When you have a whole bunch of people contributing changes, the existence of bugs is almost an inescapable fact.

One can look at this from the pessimist's point-of-view, that all software is hopelessly buggy and we might as well give up now, or one can look at this from the opportunist's point-of-view, that there is much room for improvement, much room to make meaningful contributions, and much space to go much farther than we already have.


T

-- 
Philosophy: how to make a career out of daydreaming.