www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Vision 2016 H1

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
In case you missed it from the announce forum: 
http://wiki.dlang.org/Vision/2016H1 -- Andrei
Jan 24 2016
next sibling parent tcak <1ltkrs+3wyh1ow7kzn1k sharklasers.com> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:

 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei


Is there a list or a proper place to put the list of 
desired/asked/necessary tools together with their purpose?
Jan 24 2016
prev sibling next sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:

 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei


Some comments:

- I'm not sure number of PRs is worth measuring, maybe a better 
metric would be number of devs submitting a PR, especially given 
your goal of raising participation.  If it's just a core group of 
devs submitting most of those PRs, does it matter much that they 
had more time to work on D a year ago?

- I don't think the language of military hierarchy, ie 
general/lieutenant/soldier, applies towards D.  It's more like a 
guerrilla army, think the US revolution and the Swamp Fox 
(https://en.wikipedia.org/wiki/Francis_Marion#Guerrilla_war).  
Since everybody is a volunteer, this is how it will be organized 
anyway, just pointing out that almost nobody wants to be called a 
lieutenant! :)

- It sounds like there's a fair amount of minutiae that's only 
handled by the core team right now.  I agree that formalizing 
that work into an official title or group would help get more 
people to do it, as has been done with the release manager role.  
On the other hand, every OSS project has this problem, as few 
will volunteer to take out the garbage. ;)

- Don't discount the debate on the newsgroup.  I lurked in the 
newsgroup for years before I got involved, to see what kinds of 
decisions were being made and how the process worked.  Yes, 
everybody would rather debate than chip in, but talking is 
usually a precursor for doing.

- I don't understand this section:

"This needs to be balanced with the false notion that any 
contribution must receive attention in proportion to the effort 
expended on it. 'I wrote a DIP therefore it must be worked on' 
quickly becomes 'There's no purpose in trying a DIP, nobody will 
look at it'."

Are you saying DIP and PR authors should not expect anybody to 
care about their efforts?  That would seem contrary to the goal 
of raising participation.

Perhaps a way to avoid this situation and formalize it would be 
to provide some sort of pre-approval process that is guaranteed 
to be checked by the core team (enhancement requests in bugzilla 
don't work, it's just too overstuffed with issues), so that 
contributors can be told _before_ they work on something whether 
it's likely to get serious consideration.  Maybe a wiki page 
that's monitored by the core team?

Swift also has the converse, a list of issues that are unlikely 
to be accepted:

https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md

- There's a couple mentions of tooling, but I don't get the 
impression that source formatters and parsers are what people 
have in mind.  I think they're talking about bugs or holes in the 
core tools, ie compilers, linkers, and debuggers.  This is a 
problem for any OSS project that doesn't have a commercial model, 
to fund such quality of implementation issues that volunteers 
don't want to take up.
Jan 24 2016
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2016-01-25 06:19, Joakim wrote:


 - I don't understand this section:

 "This needs to be balanced with the false notion that any contribution
 must receive attention in proportion to the effort expended on it. 'I
 wrote a DIP therefore it must be worked on' quickly becomes 'There's no
 purpose in trying a DIP, nobody will look at it'."

 Are you saying DIP and PR authors should not expect anybody to care
 about their efforts?  That would seem contrary to the goal of raising
 participation.


Just because you get more pull request (more participation) doesn't mean 
someone needs to look at them ;)

-- 
/Jacob Carlborg
Jan 25 2016
prev sibling next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 05:19:41 UTC, Joakim wrote:

 - Don't discount the debate on the newsgroup.  I lurked in the 
 newsgroup for years before I got involved, to see what kinds of 
 decisions were being made and how the process worked.  Yes, 
 everybody would rather debate than chip in, but talking is 
 usually a precursor for doing.


Yup, debates are important for creating shared understanding and 
consensus. Moving without consensus means a lot less will be done.

Good leaders create processes where consensus emerge AND a good 
shared understanding of why and how.
Jan 25 2016
prev sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2016 at 05:19:41 UTC, Joakim wrote:

 Since everybody is a volunteer, this is how it will be 
 organized anyway, just pointing out that almost nobody wants to 
 be called a lieutenant! :)


The name isn't that bad, but the authority question is... 
lieutenants would need enough documentation to make decisions on 
their own that they can be confident are correct and accepted by 
the leadership. We don't have that, so appointing someone to the 
title would be meaningless, regardless of what it is called.

General is a bit different because there's more autonomy there 
and such an individual may be ok making up their own rules.



 - There's a couple mentions of tooling, but I don't get the 
 impression that source formatters and parsers are what people 
 have in mind.


I'm not so sure... those do form the groundwork for a lot of 
requested things like refactoring tools too which are somewhat 
common requests.



  I think they're talking about bugs or holes in the core tools, 
 ie compilers, linkers, and debuggers.


And this too, of course.
Jan 25 2016
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 14:37:36 UTC, Adam D. Ruppe wrote:

 The name isn't that bad, but the authority question is... 
 lieutenants would need enough documentation to make decisions 
 on their own that they can be confident are correct and 
 accepted by the leadership. We don't have that, so appointing 
 someone to the title would be meaningless, regardless of what 
 it is called.

 General is a bit different because there's more autonomy there 
 and such an individual may be ok making up their own rules.


Well, as a former soldier serving at a national military HQ the 
terminology comes through as extremely childish and pushing all 
the wrong buttons.

The military is a rigid blind bureaucracy per excellence with 
absolutely no other purpose than being able to execute fast and 
predictable in a future crisis moving thousands of units. Outside 
that crisis it is slow, expensive, inefficient and the activities 
are pointless and non-negotiable. :-/
Jan 25 2016
next sibling parent Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2016 at 15:02:37 UTC, Ola Fosheim Grøstad 
wrote:

 The military is a rigid blind bureaucracy


That's kinda my point though, we can't even do bureaucracy 
because the rules aren't there so "lieutenants" would be 
completely lost, and we can't do autonomy because nobody is clear 
on who owns what.
Jan 25 2016
prev sibling parent reply kldjlkd <kldjlkd kldsjf.kd> writes:
On Monday, 25 January 2016 at 15:02:37 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 January 2016 at 14:37:36 UTC, Adam D. Ruppe wrote:

 The name isn't that bad, but the authority question is... 
 lieutenants would need enough documentation to make decisions 
 on their own that they can be confident are correct and 
 accepted by the leadership. We don't have that, so appointing 
 someone to the title would be meaningless, regardless of what 
 it is called.

 General is a bit different because there's more autonomy there 
 and such an individual may be ok making up their own rules.


 Well, as a former soldier serving at a national military HQ the 
 terminology comes through as extremely childish and pushing all 
 the wrong buttons.

 The military is a rigid blind bureaucracy per excellence with 
 absolutely no other purpose than being able to execute fast and 
 predictable in a future crisis moving thousands of units. 
 Outside that crisis it is slow, expensive, inefficient and the 
 activities are pointless and non-negotiable. :-/


You deny the whole modern history with such a speech. The current 
state of human being, with all its history and experience, is 
that so far we haven't found any better solution than being 
organized and prioritized (or specialized).

In the past, people tried to adopt a more horizontal system but 
it didn't work.
Jan 25 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 15:28:47 UTC, kldjlkd wrote:

 You deny the whole modern history with such a speech.


That's a bold statement with no argument to back it up.


 The current state of human being, with all its history and 
 experience, is that so far we haven't found any better solution 
 than being organized and prioritized (or specialized).

 In the past, people tried to adopt a more horizontal system but 
 it didn't work.


Of course we have horizontal and organic ways of organizing civil 
society. The military is just a very very special case where no 
failure is accepted in very chaotic situations. That means 
everything is routine. It is far more bureaucratic than even the 
most bureaucratic civil organization. The legal system is organic 
in comparison.

People who have romantic ideas about the army probably have their 
ideas of what it is like from movies or games. That does not 
reflect the incredibly dull day-to-day army life.

The overarching principle in the army is that nobody should need 
to be so skilled in their task that they cannot easily be 
replaced on the spot. Basically an ant colony.
Jan 25 2016
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
wrote:

 That does not reflect the incredibly dull day-to-day army life.


I don't think we should read *too* much into the words.

Whether we call them collaborators or middle managers or 
lieutenants or what isn't as important as actually just defining 
what we actually want to do.


In a few threads over the last few weeks, I've said that I don't 
want to be part of Phobos because it destroys my development flow 
and I've even gone so far as to fork Phobos itself and write a 
whole new generator to fix its documentation.

The main reason is in my own projects, I know exactly what is 
expected of me to get stuff done and there's very little process 
overhead. This way, I can make the most of my limited time.

Middle managers in Phobos need an environment where they won't 
feel the same way, they need some degree of ownership too.
Jan 25 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:

 I don't think we should read *too* much into the words.


Yeah, it's interesting. I recall thinking as I was drafting the 
document: "One word... ONE word that doesn't sit well and it will be all 
about that word." And now here we are. It's like those presidential or 
Fed chairman press conferences... :o).

I changed http://wiki.dlang.org/Vision/2016H1.


Andrei
Jan 25 2016
next sibling parent Joakim <dlang joakim.fea.st> writes:
On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
wrote:

 On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:

 I don't think we should read *too* much into the words.


 Yeah, it's interesting. I recall thinking as I was drafting the 
 document: "One word... ONE word that doesn't sit well and it 
 will be all about that word." And now here we are. It's like 
 those presidential or Fed chairman press conferences... :o).

 I changed http://wiki.dlang.org/Vision/2016H1.


It was just a suggestion for better naming, and it's hardly all I 
talked about.  I haven't liked that military terminology since a 
couple DConfs ago, but I felt it might turn off those coming 
across the language now who read the Vision document, so I 
finally mentioned it.  The last thing you'd want potential OSS 
contributors thinking is that we have some military-style 
bureaucracy here. ;) Dicebot's suggestion, which you use now, is 
much better.

btw, is there really an opening in "top leadership?"  I thought 
that door was shut. :)
Jan 25 2016
prev sibling next sibling parent reply Andrew Edwards <edwards.ac gmail.com> writes:
On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
wrote:

 On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:

 I don't think we should read *too* much into the words.


 Yeah, it's interesting. I recall thinking as I was drafting the 
 document: "One word... ONE word that doesn't sit well and it 
 will be all about that word." And now here we are. It's like 
 those presidential or Fed chairman press conferences... :o).

 I changed http://wiki.dlang.org/Vision/2016H1.


 Andrei


The bikeshed is now translucent... However, the community still 
lacks focus/direction. Pick a destination, establish To-dos and 
Milestones, empower the community to make it happen, then 
supervise to ensure everyone stays on task.

State the priority or at a least list of priorities. Everything 
under the sun cannot be THE priority.

e.g.
    1. Improve Module System
       -- To-dos
       -- Milestones

    2. Improve Memory Management
       2.1 Garbage Collector
           -- To-dos
           -- Milestones

       2.2 Manual Memory Management
           -- To-dos
           -- Milestones

    3. Tools
       3.1 Adapt dfmt
           -- To-dos
           -- Milestones

       3.1 Adapt dfix
           -- To-dos
           -- Milestones

After stating the priority, identify the most capable resources 
to head each initiative, empower them with a bit of autonomy and 
encourage the larger community to organize in support of these 
initiatives.

Finally, supervise!!!
Jan 25 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Monday, 25 January 2016 at 22:12:06 UTC, Andrew Edwards wrote:

 On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
 wrote:

 On 01/25/2016 11:02 AM, Adam D. Ruppe wrote:

 I don't think we should read *too* much into the words.


 Yeah, it's interesting. I recall thinking as I was drafting 
 the document: "One word... ONE word that doesn't sit well and 
 it will be all about that word." And now here we are. It's 
 like those presidential or Fed chairman press conferences... 
 :o).

 I changed http://wiki.dlang.org/Vision/2016H1.


 Andrei


 The bikeshed is now translucent... However, the community still 
 lacks focus/direction. Pick a destination, establish To-dos and 
 Milestones, empower the community to make it happen, then 
 supervise to ensure everyone stays on task.

 State the priority or at a least list of priorities. Everything 
 under the sun cannot be THE priority.

 e.g.
    1. Improve Module System
       -- To-dos
       -- Milestones

    2. Improve Memory Management
       2.1 Garbage Collector
           -- To-dos
           -- Milestones

       2.2 Manual Memory Management
           -- To-dos
           -- Milestones

    3. Tools
       3.1 Adapt dfmt
           -- To-dos
           -- Milestones

       3.1 Adapt dfix
           -- To-dos
           -- Milestones


I've been asking for this list for sometime now.  It is actually 
what I wanted from the Vision document, but that ended up too 
broad and vague.  I've since repeatedly pointed out that it 
should be more specific, more like a roadmap, as you lay out.


 After stating the priority, identify the most capable resources 
 to head each initiative, empower them with a bit of autonomy 
 and encourage the larger community to organize in support of 
 these initiatives.


These people will tend to be self-selected, but they could always 
be given some leeway in a named role.


 Finally, supervise!!!


I doubt this would ever happen: Walter and Andrei are not 
managers, and I doubt OSS contributors would want it.  The best 
one can do is define a roadmap and hope it's heeded.

I wanted to say this earlier but forgot: what D is trying to do 
is impossible.  You cannot have a successful OSS project that has 
a high technical standard and no commercial backing.  OSS 
projects tend to be more like ruby and rails, where most anything 
goes.  Projects with a high technical standard have to be more 
selective, so they go against the OSS grain.  When that happens 
in OSS, it's usually because of commercial backing.

It is amazing that D has gotten so far as an OSS project without 
commercial backing, a credit to the engineering sense of Walter 
and the core team.  But I don't think you can organize your way 
around that fundamental obstacle.

Of course, I'd likely have said OSS being so widespread would be 
impossible a couple decades ago, but OSS has certainly garnered a 
niche, once it was coupled with commercial models.
Jan 25 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:

 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering sense 
 of Walter and the core team.  But I don't think you can 
 organize your way around that fundamental obstacle.


I don't think that is accurate at all.

But paid work will make it easier to get the boring or difficult 
parts done. Hobby programmers will gravitate towards the fun 
parts and copying the design of others (e.g. Linux copying Unix).

For D, the difficult part is completing the language on paper. It 
is human nature to push difficult parts are into the future, but 
one should actually say "no more work on easy parts, we have to 
do the difficult parts first". And that takes decisive leadership.

Implementing is the easy part.
Jan 25 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 26 January 2016 at 07:18:43 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:

 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering sense 
 of Walter and the core team.  But I don't think you can 
 organize your way around that fundamental obstacle.


 I don't think that is accurate at all.


Which part?  There's at least three statements there, one largely 
factual, one opinion, then a prediction.  It's unclear what you 
think is inaccurate, since you don't say.


 But paid work will make it easier to get the boring or 
 difficult parts done. Hobby programmers will gravitate towards 
 the fun parts and copying the design of others (e.g. Linux 
 copying Unix).

 For D, the difficult part is completing the language on paper. 
 It is human nature to push difficult parts are into the future, 
 but one should actually say "no more work on easy parts, we 
 have to do the difficult parts first". And that takes decisive 
 leadership.

 Implementing is the easy part.


I wouldn't say D has pushed the difficult parts, and often 
implementing takes a lot of work too.  Obviously, the design is 
usually more important in the long-term, but the design "on 
paper" won't matter if nobody wants to implement it.
Jan 26 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 14:24:57 UTC, Joakim wrote:

 On Tuesday, 26 January 2016 at 07:18:43 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:

 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering sense 
 of Walter and the core team.  But I don't think you can 
 organize your way around that fundamental obstacle.


 I don't think that is accurate at all.


 Which part?  There's at least three statements there, one 
 largely factual, one opinion, then a prediction.  It's unclear 
 what you think is inaccurate, since you don't say.


I don't think OSS needs commercial backing to reach high 
technical levels. I do think that many OSS projects spend too 
little time on design and process, and well, design and 
coordination is more challenging when you aren't co-located in 
the same place.  I also think that often implementors take 
leading roles in OSS, when that role should have been taken by a 
designer/coordinator that would spend more time on leadership. If 
you spend 10% leading and 90% coding then the leading part 
suffers...

But there are tools we can use, if the issue was recognized.


 I wouldn't say D has pushed the difficult parts, and often


Memory management. Performant garbage collection. Coherent 
semantics.


 implementing takes a lot of work too.  Obviously, the design is 
 usually more important in the long-term, but the design "on 
 paper" won't matter if nobody wants to implement it.


They probably would if there was consensus behind it, it was 
solid, important and had a seal of approval.
Jan 26 2016
parent reply Joakim <dlang joakim.fea.st> writes:
On Tuesday, 26 January 2016 at 14:35:53 UTC, Ola Fosheim Grøstad 
wrote:

 On Tuesday, 26 January 2016 at 14:24:57 UTC, Joakim wrote:

 On Tuesday, 26 January 2016 at 07:18:43 UTC, Ola Fosheim 
 Grøstad wrote:

 On Tuesday, 26 January 2016 at 04:57:11 UTC, Joakim wrote:

 It is amazing that D has gotten so far as an OSS project 
 without commercial backing, a credit to the engineering 
 sense of Walter and the core team.  But I don't think you 
 can organize your way around that fundamental obstacle.


 I don't think that is accurate at all.


 Which part?  There's at least three statements there, one 
 largely factual, one opinion, then a prediction.  It's unclear 
 what you think is inaccurate, since you don't say.


 I don't think OSS needs commercial backing to reach high 
 technical levels. I do think that many OSS projects spend too 
 little time on design and process, and well, design and 
 coordination is more challenging when you aren't co-located in 
 the same place.  I also think that often implementors take 
 leading roles in OSS, when that role should have been taken by 
 a designer/coordinator that would spend more time on 
 leadership. If you spend 10% leading and 90% coding then the 
 leading part suffers...


OK, I finally know what you disagree with.  The fundamental 
problem is that without commercial funding, all OSS contributions 
are voluntary, usually done during their spare time, while 
focused design takes time, a lot of it.  Without commercial 
backing to fund that time, it is difficult for most to work 
towards that high level of technical design.  Perhaps that's why 
OSS devs spend most of their time coding, they want to focus what 
little time they have on getting some code out.

Now, every once in a while, some lone coder like Walter has the 
time to buck those odds.  But then the problem becomes scaling 
the OSS project, especially without a commercial model.  We're 
lucky that Walter and Andrei are financially independent enough 
to work on D full-time, but that's still only two people.  D 
certainly is going a lot slower than it would with commercial 
backing.

Now, corporate support is no panacea, it has its own pitfalls.  
And maybe if someone stuck a whole bunch of money behind D, 
Walter and Andrei wouldn't even know how to spend all of it well, 
ie torrid growth simply may not be possible at this point in the 
language growth curve.  But I think D would certainly have grown 
faster to this point if it had a commercial model, and that such 
funding generally allows time for the design and coordination you 
say most OSS projects don't do.


 But there are tools we can use, if the issue was recognized.


Such as?


 I wouldn't say D has pushed the difficult parts, and often


 Memory management. Performant garbage collection. Coherent 
 semantics.


It doesn't sound like Walter has much interest in the first two, 
and either nobody has picked those up or bothered to integrate 
PRs like Sociomantic's concurrent GC from D1.  As for the last, 
I'm sure he either disagrees or doesn't care.


 implementing takes a lot of work too.  Obviously, the design 
 is usually more important in the long-term, but the design "on 
 paper" won't matter if nobody wants to implement it.


 They probably would if there was consensus behind it, it was 
 solid, important and had a seal of approval.


I don't think consensus has been the issue as much as time, which 
is the killer for any OSS or voluntary project.
Jan 26 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 15:02:51 UTC, Joakim wrote:

 OK, I finally know what you disagree with.  The fundamental 
 problem is that without commercial funding, all OSS 
 contributions are voluntary, usually done during their spare 
 time, while focused design takes time, a lot of it.  Without 
 commercial backing to fund that time, it is difficult for most 
 to work towards that high level of technical design.  Perhaps 
 that's why OSS devs spend most of their time coding, they want 
 to focus what little time they have on getting some code out.


It is true that it is easier to jump in and out of "evolutionary 
coding" than focused design, but that's more of a convenience 
issue...

You can achieve a lot by cutting down the scope and use a divide 
and conquer strategy. So I don't think it is the most limiting 
factor, unless you try to implement an existing bloated standard 
like C++ or HTML5.


 I don't think consensus has been the issue as much as time, 
 which is the killer for any OSS or voluntary project.


I think one generally can get more done by having a design that 
is ready and that is partitioned into "implementable units". 
Design the APIs for a standard library up front, provide minimal 
proof-of-concept implementation, let other people replace it with 
production quality code.
Jan 26 2016
prev sibling parent Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On Monday, 25 January 2016 at 16:20:50 UTC, Andrei Alexandrescu 
wrote:

 Yeah, it's interesting. I recall thinking as I was drafting the 
 document: "One word... ONE word that doesn't sit well and it 
 will be all about that word." And now here we are. It's like 
 those presidential or Fed chairman press conferences... :o).

 I changed http://wiki.dlang.org/Vision/2016H1.


Yea, let's paint that non-pacifistic bikeshed ;-)

In seriousness: I think the vision in terms of improving 
engagement is fine, but what I would suggest in practice is to 
focus carefully on the decision-making structure that is needed 
in order for D to flourish.

That's going to involve some serious thought about, for example, 
what sort of decisions Walter and yourself are happy delegating, 
what circumstances you might reserve a veto or override, and how 
to arrange things (and provide structured guidance) so that the 
chances of you needing to pull those powers out are minimal.

It would also involve considering who gets a say about who sits 
in various decision-making roles (for example, how to mix 
top-down and bottom-up selection of people who will hold 
positions of responsibility).

I think that getting that basic structure right may do a lot in 
terms of making it possible to obtain, productively use, and 
retain contributors on every possible level.
Jan 25 2016
prev sibling next sibling parent reply JohnCK <j j.com> writes:
On Monday, 25 January 2016 at 16:02:09 UTC, Adam D. Ruppe wrote:

 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
 wrote:

 That does not reflect the incredibly dull day-to-day army life.


 I don't think we should read *too* much into the words.

 Whether we call them collaborators or middle managers or 
 lieutenants or what isn't as important as actually just 
 defining what we actually want to do.


I agree 100%!

Please guys don't get stuck on small things like this. I'm seeing 
this behavior growing up in here.

Maybe it's time to create a new group called: Drama. :)

And please don't waste your time answering this.

JohnCK.
Jan 25 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 16:31:50 UTC, JohnCK wrote:

 On Monday, 25 January 2016 at 16:02:09 UTC, Adam D. Ruppe wrote:

 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim 
 Grøstad wrote:


 Please guys don't get stuck on small things like this. I'm 
 seeing this behavior growing up in here.


It is not a small thing in the sense that it affects D's ability 
to complete features before adding more features.

Let's follow the metaphores:

- Andrei is the general.
- Walter is the general/special forces.

The special forces are highly skilled, but don't bring common 
soldiers along. They don't exercise leadership, but swiftly 
implement features on direct orders from the generals: like C++ 
exceptions, UDAs etc.

Here's the problem: features are added before the existing 
features are completed without any documentation/rationale for 
why the new features are of the highest priority.

This goes on while the population is suffering from traffic jam 
caused by a lack of basic infrastructure like non-GC 
memory-management.

Is the lack of memory management a small thing? Hell no. So why 
isn't it of the highest priority? Because it is difficult to 
design?

Well, then you need to replace the generals with a process that 
can bring in more viewpoints.

Now, in defense of Andrei, I'll say that he has become much less 
of a general in the past two years, and more of an enabler, and 
that he also created a forum to allow more viewpoints to be 
presented. But the generals aren't nurturing the process! And the 
implementation of D still depends on Walter operating as the 
special forces rather than bringing other people up closer to his 
level...

Not a small problem. Establishing a better process with better 
yield is a challenging problem. It won't happen by itself.



 And please don't waste your time answering this.


So you are basically in favour of censorship? Which is an 
authoritarian mode of leadership. Thus you don't mind having 
generals as a metaphor.

Don't you think that people can decide for themselves which 
debates they want to engage in? Which is a more democratic way of 
organizing decision making processes.
Jan 25 2016
parent reply JohnCK <j j.com> writes:
On Monday, 25 January 2016 at 18:37:44 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 January 2016 at 16:31:50 UTC, JohnCK wrote:

 ...
 And please don't waste your time answering this.


 So you are basically in favour of censorship? Which is an 
 authoritarian mode of leadership. Thus you don't mind having 
 generals as a metaphor.

 Don't you think that people can decide for themselves which 
 debates they want to engage in? Which is a more democratic way 
 of organizing decision making processes.


Please, you've exposed your opinion and Andrei already changed 
the document using "contributors". Engaging on this matter will 
be just a waste of time. Let's focus on D itself.

JohnCK.
Jan 25 2016
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 18:45:43 UTC, JohnCK wrote:

 Please, you've exposed your opinion and Andrei already changed 
 the document using "contributors". Engaging on this matter will 
 be just a waste of time. Let's focus on D itself.


Again you make an authoritarian statement "Engaging on this 
matter will be just a waste of time.".

Nobody has to waste their time, they don't have to read.

There is no way _you_ can know what leads to a change that will 
bring the necessary changes that makes D competitive.

D added  nogc YEARS ago, because I pushed the point that the GC 
would never be a viable option for real time programmers.  But we 
still have no competitive memory management on paper. That's two 
years too late. We should have been implementing it now.

D needs a competitive solution to Rust and C++ before C++ 
compilers implement the next generation C++ features. That might 
be next year?

I would love to get rid of C++, but I increasingly believe that 
this will not be a rational option. That's sad, because C++ is a 
nuisance.

You cannot focus on D without changing the process. Meaning: give 
critical features higher priority than "low hanging fruit".
Jan 25 2016
parent reply Meta <jared771 gmail.com> writes:
On Monday, 25 January 2016 at 20:34:40 UTC, Ola Fosheim Grøstad 
wrote:

 D added  nogc YEARS ago, because I pushed the point that the GC 
 would never be a viable option for real time programmers.


No. The only part you may have had in ushering in  nogc is 
putting the idea out there (although I'm pretty sure Manu and 
Bearophile were advocating it long before that).  nogc was 
brought about because Johannes Pfau had the initiative to 
implement the framework for it and push it through. Otherwise we 
would still just be talking about it as a nice idea, and you 
would be bringing it up for the nth time with absolutely no 
benefit to anyone.
Jan 25 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Tuesday, 26 January 2016 at 01:08:31 UTC, Meta wrote:

 No. The only part you may have had in ushering in  nogc is 
 putting the idea out there (although I'm pretty sure Manu and 
 Bearophile were advocating it long before that).  nogc was 
 brought about because Johannes Pfau had the initiative to 
 implement the framework for it and push it through. Otherwise 
 we would still just be talking about it as a nice idea, and you 
 would be bringing it up for the nth time with absolutely no 
 benefit to anyone.


No. This isn't about the idea of " nogc" or "better C", Walter 
did those on his own. It was about convincing Walter that enough 
people found the current situation not very useful for a 
particular type of programming. It was about having many 
viewpoints of how the GC situation was keeping D back. It was a 
very long and heated thread with many people commenting on what 
they needed to make better use of D.

Changes in D come from significant _vocal_ end user pressure. 
That is the historical trend. And that trend is very clear.
Jan 25 2016
prev sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 16:02:09 UTC, Adam D. Ruppe wrote:

 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
 wrote:

 That does not reflect the incredibly dull day-to-day army life.


 I don't think we should read *too* much into the words.


For individualistic people that have been drafted to boot camp 
and experienced being stripped off their individuality and 
drilled to blindly obey pointless "humiliating" orders by young 
and dumb seargents the words evoke the wrong _emotions_. I was so 
happy to put that part of my life behind me. It was a wasted year.

I don't have to read anything into the words. It is in my spine. 
There is no way I can pretend that military role-play in a 
supposedly productive environment isn't immature.



 Whether we call them collaborators or middle managers or 
 lieutenants or what isn't as important as actually just 
 defining what we actually want to do.


No, but it sends a message of what "generals" and "lieutenants" 
imagine to be the ideal development process.

Which is something I have complained loudly about before. I think 
it keeps D back. I think how you organize the process can have 
massive influence on degree of volunteering, enthusiasm and the 
quality of the decision-making.

If you take on the title "general" it does communicate something 
about your mental model of the process. It is a very pompous 
label that few normal adults would be comfortable with applying 
to themselves outside a game world.



 In a few threads over the last few weeks, I've said that I 
 don't want to be part of Phobos because it destroys my 
 development flow and I've even gone so far as to fork Phobos 
 itself and write a whole new generator to fix its documentation.

 The main reason is in my own projects, I know exactly what is 
 expected of me to get stuff done and there's very little 
 process overhead. This way, I can make the most of my limited 
 time.


And that is an interesting perspective that sends strong signals 
about a need to reconsider how the process can be organized so 
that people feel less resistance in their own 
productivity/satisfaction.

Evolving the process and motivational factors is a key leadership 
role, right?
Jan 25 2016
prev sibling parent reply kldjlkd <kldjlkd kldjlkd.fs> writes:
On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
wrote:

 On Monday, 25 January 2016 at 15:28:47 UTC, kldjlkd wrote:

 You deny the whole modern history with such a speech.


 That's a bold statement with no argument to back it up.


 The current state of human being, with all its history and 
 experience, is that so far we haven't found any better 
 solution than being organized and prioritized (or specialized).

 In the past, people tried to adopt a more horizontal system 
 but it didn't work.


 Of course we have horizontal and organic ways of organizing 
 civil society.


breaking news, the civil society has a horizontal organization...
What a joke.
Jan 25 2016
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= writes:
On Monday, 25 January 2016 at 17:18:40 UTC, kldjlkd wrote:

 On Monday, 25 January 2016 at 15:45:09 UTC, Ola Fosheim Grøstad 
 wrote:

 Of course we have horizontal and organic ways of organizing 
 civil society.


 breaking news, the civil society has a horizontal 
 organization...
 What a joke.


Read the sentence again. It is not uncommon in highly educated 
organizations to have flatter structures and high levels of 
autonomy.

I am not going to argue this point, that is my field after all.
Jan 25 2016
prev sibling parent reply Dicebot <public dicebot.lv> writes:
On Monday, 25 January 2016 at 14:37:36 UTC, Adam D. Ruppe wrote:

 On Monday, 25 January 2016 at 05:19:41 UTC, Joakim wrote:

 Since everybody is a volunteer, this is how it will be 
 organized anyway, just pointing out that almost nobody wants 
 to be called a lieutenant! :)


 The name isn't that bad, but the authority question is... 
 lieutenants would need enough documentation to make decisions 
 on their own that they can be confident are correct and 
 accepted by the leadership. We don't have that, so appointing 
 someone to the title would be meaningless, regardless of what 
 it is called.

 General is a bit different because there's more autonomy there 
 and such an individual may be ok making up their own rules.


I think more realistic name distinction would be "core team", 
"collaborators" and "contributors".
Jan 25 2016
parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 25 January 2016 at 15:05:45 UTC, Dicebot wrote:

 I think more realistic name distinction would be "core team", 
 "collaborators" and "contributors".


LOL. I was just reading the section on that in "The Design and 
Implementation of the FreeBSD Operating System" yesterday. What 
timing.

- Jonathan M Davis
Jan 25 2016
parent reply Dicebot <public dicebot.lv> writes:
On Monday, 25 January 2016 at 18:30:49 UTC, Jonathan M Davis 
wrote:

 On Monday, 25 January 2016 at 15:05:45 UTC, Dicebot wrote:

 I think more realistic name distinction would be "core team", 
 "collaborators" and "contributors".


 LOL. I was just reading the section on that in "The Design and 
 Implementation of the FreeBSD Operating System" yesterday. What 
 timing.

 - Jonathan M Davis


What section? I have no idea what you refer to :)
Jan 25 2016
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 25 January 2016 at 18:52:00 UTC, Dicebot wrote:

 On Monday, 25 January 2016 at 18:30:49 UTC, Jonathan M Davis 
 wrote:

 On Monday, 25 January 2016 at 15:05:45 UTC, Dicebot wrote:

 I think more realistic name distinction would be "core team", 
 "collaborators" and "contributors".


 LOL. I was just reading the section on that in "The Design and 
 Implementation of the FreeBSD Operating System" yesterday. 
 What timing.

 - Jonathan M Davis


 What section? I have no idea what you refer to :)


Section 1.4 where they go over the FreeBSD development model.

http://www.amazon.com/Design-Implementation-FreeBSD-Operating-System/dp/0321968972/ref=sr_1_1?ie=UTF8&qid=1453752473&sr=8-1&keywords=freebsd+operating+system

- Jonathan M Davis
Jan 25 2016
prev sibling next sibling parent Satoshi <satoshi gshost.eu> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:

 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei



Whats about reference counting as a main memory manager? It would 
be nice for low level programming where I cannot use GC and want 
use things like ~=, etc.
Jan 25 2016
prev sibling next sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:

 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei


Maybe we should finally decide what color to paint the bikeshed?
Jan 25 2016
parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Monday, 25 January 2016 at 15:38:01 UTC, rsw0x wrote:

 On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
 wrote:

 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei


 Maybe we should finally decide what color to paint the bikeshed?


Probably some shade that they can't actually make paint of for 
some reason. ;)

- Jonathan M Davis
Jan 25 2016
prev sibling parent reply rsw0x <anonymous anonymous.com> writes:
On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu 
wrote:

 In case you missed it from the announce forum: 
 http://wiki.dlang.org/Vision/2016H1 -- Andrei



We are still shorthanded with all aspects of D development: top 
leadership,


I'd be interested in seeing someone with good 
leadership/community skills(no offense to Andrei/Walter meant) 
become a "top" part of D like Andrei/Walter currently are. I can 
think of a few D core contributors off the top of my head that 
seem to possess good leadership qualities and seem to go out of 
their way to make sure things get done.
Jan 25 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 1/25/16 1:48 PM, rsw0x wrote:

 On Monday, 25 January 2016 at 03:14:47 UTC, Andrei Alexandrescu wrote:

 In case you missed it from the announce forum:
 http://wiki.dlang.org/Vision/2016H1 -- Andrei



 We are still shorthanded with all aspects of D development: top
 leadership,


 I'd be interested in seeing someone with good leadership/community
 skills(no offense to Andrei/Walter meant) become a "top" part of D like
 Andrei/Walter currently are. I can think of a few D core contributors
 off the top of my head that seem to possess good leadership qualities
 and seem to go out of their way to make sure things get done.


Yah, that aspect is less understood than it should. Say Herb Sutter 
would join the fray under an alias and started doing great things - I 
trust myself and Walter enough to think he'd be quickly recognized and 
"promoted". There definitely is room in the top ranks for one or more 
folks of that caliber. -- Andrei
Jan 25 2016
parent Bubbasaur <bubba gmail.com> writes:
On Monday, 25 January 2016 at 19:41:53 UTC, Andrei Alexandrescu 
wrote:

 ... There definitely is room in the top ranks for one or more 
 folks of that caliber. -- Andrei


Scott Meyers!
Jan 25 2016