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

Reply via email to