On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote:
> On 1/5/2018 3:04 AM, Paolo Invernizzi wrote:
>> 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...
>
> I could easily spend 30 hours per day just reading the n.g. Or 30 hours per day just reviewing PRs. Or ...
>
> I have to manage my time.

That sounds really exhausting.

We have it a bit easier here on planet earth, as we only have 24 hours in a day.

Perhaps you should consider moving?

On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote:
> On 1/5/2018 3:04 AM, Paolo Invernizzi wrote:
>> 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...
>
> I could easily spend 30 hours per day just reading the n.g. Or 30 hours per day just reviewing PRs. Or ...
>
> I have to manage my time.

A good way to clean it up would be to create a "Complain about D's GC" ng section.  Then you will see a 80% drop in General and can focus better.

On Friday, 5 January 2018 at 22:55:43 UTC, Adam D. Ruppe wrote:
> On Friday, 5 January 2018 at 22:45:15 UTC, Walter Bright wrote:
>> I could easily spend 30 hours per day just reading the n.g.
>
> Learn threads tend to be quite short. Just skim the first post in a thread to see what people talk about. It takes mere minutes, spread out over the day.

+1

We all have to manage time, me too: for example, I try to give advices on something that's specific in my domain, see [1], as I've very very little time to spare in d-land...

You wrote [2] that the main problem is "more people doing quality work. Not more process".
So It really worth spending your time in coding for compiler coloured messages and not in trying to solve that?

As an example for reasoning, you have just written [3] that merging PR that are OK but not great is bad, as they resulted in more regression to be fixed by you.

Main problem: more people doing quality work.

"""
Dear community, as we are trying to leverage the number of people doing quality work on the compiler, we will merge PR that are OK but not great, for a Z months period.

We are expecting an increase in the number of people studying and working on the compiler, training them to become potential future core team members.

In the judgement of the core time, now we have X skilled core contributors, while you can find below:
- the numbers for distinct people who opened pull request month by month.
- the numbers of regressions open and closed weekly for the past period.
- the numbers for OK and great PR pushed in the past.

We are expecting to increase the number of skilled core contributors from X to Y at the end of the period, an increase of the monthly open regression to K balanced by an increased rate of closed regression by Z.
"""

Then, after the period, you simply retake the measure, and you have put in front of everybody an evidence.

That is just a fast crafted example, not so pertinent, but it gives the idea of what I'm trying to suggest. I would be interested in hearing Laeeth opinion on that.

But, where are the metrics? I'm always so marvelled that engineers use so often 'their personal impressions' instead of a sane, carefully crafted metric (instead of the actual vanity and not actionable number of downloads). That would be a good field of work for the foundation, for example.

/P

[1] http://forum.dlang.org/post/pdbpremnjtuzakkjapjh@forum.dlang.org
[2] http://forum.dlang.org/post/p2pdn5$8dm$1@digitalmars.com
[3] http://forum.dlang.org/post/p2pcts$76k$1@digitalmars.com