What don't you switch to GitHub issues

[codephantom]

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.