On Tuesday, 24 May 2022 at 18:07:30 UTC, max haughton wrote:
> https://sharedphysics.com/everything-is-important/#step-1-create-a-unified-view-of-all-existing-work
>
> We need step 1 (and then the others), but step 1 in particular is something we're missing.
>
> Suggestions as to how to implement this are appreciated.

ummm..divide and conquer.

to get a unified view of a business, for example, you divide it into its components (sales, marketing, customer-service, logistics, I.T, finance...etc).

Then you ensure there is management, and competent management, in those areas.

Then you bring that management together, and try to get the big picture.

You replace those management who are unable to assist in this process ;-)

On Tuesday, 24 May 2022 at 22:44:36 UTC, forkit wrote:
> On Tuesday, 24 May 2022 at 18:07:30 UTC, max haughton wrote:
>> https://sharedphysics.com/everything-is-important/#step-1-create-a-unified-view-of-all-existing-work
>>
>> We need step 1 (and then the others), but step 1 in particular is something we're missing.
>>
>> Suggestions as to how to implement this are appreciated.
>
> ummm..divide and conquer.
>
> to get a unified view of a business, for example, you divide it into its components (sales, marketing, customer-service, logistics, I.T, finance...etc).
>
> Then you ensure there is management, and competent management, in those areas.
>
> Then you bring that management together, and try to get the big picture.
>
> You replace those management who are unable to assist in this process ;-)

We don't have people enough to need to do that, what I mean is that we need to build systems on servers rather than brains to keep track of what people are doing and observe the effects.

If we take Boyd's OODA loop as an abstraction to target we currently are struggling with step one and two: Observation is somewhat informal but not impossible, orientation is very hard because we can't easily keep track of what's happening in way that's accessible to either external readers or would-be volunteers.

On Wednesday, 25 May 2022 at 00:15:56 UTC, max haughton wrote:
> On Tuesday, 24 May 2022 at 22:44:36 UTC, forkit wrote:
>> On Tuesday, 24 May 2022 at 18:07:30 UTC, max haughton wrote:
>>> https://sharedphysics.com/everything-is-important/#step-1-create-a-unified-view-of-all-existing-work
>>>
>>> We need step 1 (and then the others), but step 1 in particular is something we're missing.
>>>
>>> Suggestions as to how to implement this are appreciated.
>>
>> ummm..divide and conquer.
>>
>> to get a unified view of a business, for example, you divide it into its components (sales, marketing, customer-service, logistics, I.T, finance...etc).
>>
>> Then you ensure there is management, and competent management, in those areas.
>>
>> Then you bring that management together, and try to get the big picture.
>>
>> You replace those management who are unable to assist in this process ;-)
>
> We don't have people enough to need to do that, what I mean is that we need to build systems on servers rather than brains to keep track of what people are doing and observe the effects.
>
> If we take Boyd's OODA loop as an abstraction to target we currently are struggling with step one and two: Observation is somewhat informal but not impossible, orientation is very hard because we can't easily keep track of what's happening in way that's accessible to either external readers or would-be volunteers.

You put too much faith in 'systems on servers' ;-)

There are six git repositories, and one issues repository.

At the very least, there should be a (separate) human in charge of managing each, and also attracting, organising, and delegating, to other talented humans, within each repository.

To the extent that the 'systems on servers' do not meet the needs of those managing each repository, that is a matter for them to attend to.

Managing is the key to success, not 'systems on servers'.

If there's failure in the D community, it is failure of managing.

On Wednesday, 25 May 2022 at 00:15:56 UTC, max haughton wrote:
>
>
> If we take Boyd's OODA loop as an abstraction to target ....
> ...

Boyd's loop is targetted towards decision makers (i.e. management) - ie. humans.

If you're saying D does not have the humans to put into management positions, then D does not have the humans to make decisions, and thus, pursuing Boyd's loop (or any other form of managing).. is kinda pointless ;-)

On Wednesday, 25 May 2022 at 03:16:05 UTC, forkit wrote:
> On Wednesday, 25 May 2022 at 00:15:56 UTC, max haughton wrote:
>>
>>
>> If we take Boyd's OODA loop as an abstraction to target ....
>> ...
>
> Boyd's loop is targetted towards decision makers (i.e. management) - ie. humans.

D contributors are indeed human

> If you're saying D does not have the humans to put into management positions, then D does not have the humans to make decisions, and thus, pursuing Boyd's loop (or any other form of managing).. is kinda pointless ;-)

I'm saying we have enough humans to do stuff we are just not good at keep them pointing at the right stuff, for reasons similar to those described in the linked article.

In a project like D naively aiming to manage people will just piss people off, we need to make progress observable and make it obvious where actually needs work and what other people are trying to do. Being able to measure some notion of progress, even if fuzzy, is good way of getting more of that thing: In a very simple sense, which types of D outreach bring the most traffic to dlang.org? How many people have downloaded the nightly build on github etc. (hint: not many).

Managing programmers is a full time job even if you're paying them to work for you. I think a lot of these nicely packaged ideas like OODA are bullshit, I just think there is obviously progress we can make either for individuals or for D as a directed programming language in the rough concept of the loop. The specifics don't really matter.

This concept has an added benefit in allowing people new to contributing to find something to do without having to actively seek out people they may not know exist yet. Similarly we have no data on whether people try and fail to contribute, get stuck, etc: sticking a little survey somewhere is better than nothing.

On Wednesday, 25 May 2022 at 03:44:08 UTC, max haughton wrote:
> ...
> I'm saying we have enough humans to do stuff we are just not good at keep them pointing at the right stuff, for reasons similar to those described in the linked article.

You need better managers then.

> In a project like D naively aiming to manage people will just piss people off, we need to make progress observable and make it obvious where actually needs work and what other people are trying to do. Being able to measure some notion of progress, even if fuzzy, is good way of getting more of that thing: ...

This is why you need managers. Not to 'manage people', but to manage these issues.

> Managing programmers is a full time job even if you're paying them to work for you.

One does not manage programmers ;-)

>
> This concept has an added benefit in allowing people new to contributing to find something to do without having to actively seek out people they may not know exist yet. Similarly we have no data on whether people try and fail to contribute, get stuck, etc: sticking a little survey somewhere is better than nothing.

Again, this is why you need someone managing this. It won't happen otherwise.

Try asking the most important questions first.

Who is managing this repository, and that repository?

At the moment, I don't know. Do you? Is it Walter? Does he do it all?

I cannot currently go to a manager and say, hey, I think these areas need to be improved, and here are some ideas on how it might be done.

Just having the idea and spraying it around the NG won't make much difference to anything.

If D wants to set itself up for a new phase, it will need good managers, not just good programmers.

On Wednesday, 25 May 2022 at 08:44:47 UTC, forkit wrote:
>

Perhaps D needs a formal, 'engineering services' team?

(with the emphasis on 'team', as opposed to 'person')

case study:

https://azure.microsoft.com/mediahandler/files/resourcefiles/devops-at-microsoft-innovating-on-open-source/DevOps%20at%20Microsoft%20-%20.NET.pdf

On Wednesday, 25 May 2022 at 09:09:40 UTC, forkit wrote:
>

I think this says it all ;-)

https://wiki.dlang.org/?title=Special:Search&search=Vision%2F

On Wednesday, 25 May 2022 at 09:09:40 UTC, forkit wrote:
> On Wednesday, 25 May 2022 at 08:44:47 UTC, forkit wrote:
>>
>
> Perhaps D needs a formal, 'engineering services' team?
>
> (with the emphasis on 'team', as opposed to 'person')
>
> case study:
>
> https://azure.microsoft.com/mediahandler/files/resourcefiles/devops-at-microsoft-innovating-on-open-source/DevOps%20at%20Microsoft%20-%20.NET.pdf

We have recently starting making a push to get everything under one IaC roof when it comes to infrastructure. The whole idea behind doing that is to eliminate much of the need for a team at all, it's just code.