On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:
> On 5/22/17 6:53 PM, cym13 wrote:
>
> One thing that several of those people emphasized is we need to improve leadership and decision. "You are trying to do democracy and democracy doesn't work here" (by a successful serial entrepreneur). Walter and I have implicitly fostered a kind of meritocracy whereby it's the point/argument that matters. It should be meritocracy of the person - good proven contributors have more weight and new people must prove themselves before aspiring to influence. Historically, anyone with any level of involvement with D could hop on the forum and engage the community and its leadership in debate. Subsequently, they'd be frustrated with the ensuing disagreement and also get a sense of cheapness - if I got to carry this unsatisfactory debate with the language creator himself, what kind of an operation is this?
>
> Since anything can be debated by anyone, everything gets debated by everyone. Anyone can question any decision at any time and expect a response. It's the moral equivalent of everyone in a 5000-person company building can expect to stop the CEO on the way to his/her office and engage them in a conversation of any length. The net consequence is slower progress.
>
> Where we need to be is fostering strong contributions and contributors. The strength of one's say is multiplied by his/her contributions (and that simply means pulled PRs, successful DIPs - not "won" debates).

I strongly suggest to have a clear and transparent procedure to collect impressions and  suggestion from *commercials* that are *actually using* the language in production, and separate those from other things to discuss.

Guru meditation: try not to loose talented contributors involved... Dicebot, Kenji, Bearofile... what's happened, and what can be done on this front?

Sincerely
/Paolo

On Friday, 26 May 2017 at 16:55:44 UTC, Joakim wrote:
> On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:
>> Documentation of vibe.d was also mentioned as an important problem. More precisely, it's the contrast between the quality of the project and that of the documentation - someone said his team ended up with a different (and arguably inferior) product that was better documented. Literally they had the same engineer try each for a day. Reportedly it was very difficult to even figure whether vibe.d does some specific thing, let alone tutorials and examples of how to do it.
>
> Eh, documentation is going to be sparse for a non-corporate OSS project.  If they're building products with vibe.d, presumably they can throw some consulting dollars Sonke's way and get him to help.

A reasonable presumption, but I do not know if Sonke himself has capacity for such as he seems quite busy.

So it might be worth thinking about alternative ways to move towards better docs for vibe.d (in collaboration with Sonke).

On Friday, 26 May 2017 at 16:55:44 UTC, Joakim wrote:
> On Friday, 26 May 2017 at 11:32:21 UTC, Andrei Alexandrescu wrote:
>> Walter and I have implicitly fostered a kind of meritocracy whereby it's the point/argument that matters.

I don't see any evidence of this statement being true. Unfortunately.

> That's because that's all that matters.  It is what almost every worthwhile organization aspires to, though very few get there.  Doing anything else would be a mistake.

True.

> Of course, like anything, debate can be overdone and you're probably right that it has been at times here.  But an open source project is a fundamentally different thing than a startup, it requires much more community involvement and deliberation.

Right,  feedback and arguments about semantics are good, feedback on usability or integration problems are good.

What is not good is lifting out design-issues into small packages and trying to fix them one-by-one with a strong emphasis on implementation cost.

Democracy is great for building big things if the vision is clear and shared.

Democracy is great for pointing out where the systemic problems are.

Democracy is great for adapting something that is complete to new use cases.

Democracy is not great for innovation, designing new solution, creating good UI experiences or even engineering...

So, why-oh-why so much effort on writing DIPs on stuff like pre/post condition syntax? This has to be designed into a whole and would be better done by a small team of designers taking the _problems_ into account consulting experts on the specifics of the area. But if you want expertise you actually have to be interested in learning about that topic instead of defending what is there already.

Anyway, if people sense that semantic changes are too hard to get through I guess they will aim for something that is on the surface (like "body"). As a symbolic act to see if change is at all possible.

But it is rather inconsequential and rather inefficient use of resources. Which will happen to any project without a list of priorities.

On Saturday, 27 May 2017 at 10:50:34 UTC, Ola Fosheim Grøstad wrote:
> Anyway, if people sense that semantic changes are too hard to get through I guess they will aim for something that is on the surface (like "body"). As a symbolic act to see if change is at all possible.

Don't mistake my intentions. I proposed removing `body` because not being able to use it as a symbol name is often complained about on the forums, because it is a small, manageable and understandable change, because it is a net (admittedly tiny) improvement to the language, and because I wanted to write a "practice" DIP to familiarize myself with the process in the event that I decide to write a larger one in the future (such as fixing up and resubmitting Kenji's tuple DIP).

On Saturday, 27 May 2017 at 20:21:56 UTC, Meta wrote:
> On Saturday, 27 May 2017 at 10:50:34 UTC, Ola Fosheim Grøstad wrote:
> Don't mistake my intentions. I proposed removing `body` because not being able to use it as a symbol name is often complained about on the forums, because it is a small, manageable and understandable change, because it is a net (admittedly tiny) improvement to the language, and because I wanted to write a

Sure, there are many small improvements that could be made, but this is a lot of bureaucracy for the 15 minutes it takes to turn it into a contextual keyword...