What don't you switch to GitHub issues

[H. S. Teoh]

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.