www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Re: What don't you switch to GitHub issues

reply "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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.
Jan 04
parent codephantom <me noyb.com> writes:
On Thursday, 4 January 2018 at 18:27:37 UTC, H. S. Teoh wrote:
 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.
I hear this argument too much in the D community. It is not the solution D needs. Plenty of people are willing to step up. The problem, as I see it, is a lack of process to ensure such peoples efforts are worthwhile. I volunteer in the community (nothing to do with computing), and I only volunteer with organisations that have clear strategic goals, well defined processes, and good management. These things form a vital framework that encourages and retains volunteers, and the best of them too. The open souce development model is all about volunteers... I get that...but from what I can tell, it often lacks such a necessary framework... and this becomes self evident over time. I do not see it as the responsibility of volunteers to create such a framework. This should be motivated and sponsered by core, just as it would in a real world scenario.
 And how are you measuring software quality?
By looking for that essential framework I mentioned previously.
 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.
Indeed!
 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.
Rubbish. QA and number of bugs are correlated.
 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.
Those coders are working for the wrong company.
 Now I'm not saying D doesn't need to improve its QA process -- 
 that would be quite welcome, in fact.
Finally! We agree!
 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.
Hence the need for QA.
 When you have a whole bunch of people contributing changes, the 
 existence of bugs is almost an inescapable fact.
Hence the need for QA.
 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.
QA is optimistic, not pessimitic.
Jan 04