What don't you switch to GitHub issues

[Paolo Invernizzi]

On Friday, 5 January 2018 at 13:02:20 UTC, Andrei Alexandrescu 
wrote:
> On 1/5/18 6:04 AM, Paolo Invernizzi wrote:
>> Andrei recently posted that he is following less the forums as 
>> he prefer to invest his time in a different way ...
>> Adam suggested Walter to follow the 'learn' forum to have a 
>> cleaner idea about common problems in the language usage, and 
>> Walter replied that he prefers to invest his time digging  and 
>> solving Bugzilla issues...
>>
>> There's nothing wrong with that, and it's reasonable also.
>> 
>> But it's a sign, IMHO, of something wrong with the management 
>> of the 'human factors' in dlang-land.
>
> Thanks for writing. We are following the forums, just that we 
> are trying to convert idle debates into actual impact. Michael 
> Parker is very helpful as well. My perception is we are in 
> touch with the community, though definitely things could be 
> improved. -- Andrei

Thanks Andrei, glad to hear that, and you are right about Michael.
Laeeth is also doing a very positive work in keep things focused 
in discussions.

Having just read that Walter is working on coloured error 
messages, as a contribution to the community I'm quoting what 
I've emailed to you quite long ago.
Let's see if we can do something about this.

"Regarding what I’ve written as an advice, I’m not an engineer, 
I’m coming for school of economics (but I’m a programmer, too), 
but hey, my fast advice are:

- be proud: commercials are appreciating that the D core team is 
encouraging companies to submit their needs. Not only Industry 
proven, Industry Friendly and supportive, should be big on the 
DLang site, and it’s already happening.

- be selective: their needs in the _actual_ D usage; they are 
taking a risk and investing in D, feedback coming from companies 
using D daily with large codebase, must have a bigger weight than 
other feedback.

- be open: just transform that feedback, with the right omissis 
if necessary, in something public.

- be addicted to facts: try to separate opinions from facts on 
the previous point, digging from requests for a feature to the 
problem that they are trying to solve with the requested feature.

- be predictive: before taking a choice on the language, make a 
public statement about what you are expecting as a result in the 
use of D, and how it will be measured in the future: a LOT of 
things are measurable.

- be quantitative: your download statistics are a good start, try 
to collect from commercials statistics about the length of the 
codebase, the compilation times, how many are using a feature 
(C++ integration, allocators, scope when polished).

- be fact driven: analyse your own predictions about metrics with 
what you are as results from measuring, and iterate on the next 
decisions (also) based on that."

/Paolo