On Thursday, 16 April 2015 at 04:05:19 UTC, Andrei Alexandrescu wrote:
> (sometimes trivial). Lists, labels, management techniques that are touted in this forum every few months or so - no avail. The vision document that everybody asked about? Read and dutifully ignored

I've seen capable people in the forums repeatedly asking for things to do that matters, but not receiving an answer. Silence. That's lost opportunities. Frequently.

A vision for the language is still missing. Is it a system programming language, for what application area, or is it a java replacement? What are the missing bits for D to be a viable system programming language?

The vision document you created was like a milestone map without milestones and dependencies, and no measures to evaluate it by, but work did get done on GC/C++ even though the evaluation is missing. Where is the long term road map? What is at the end of the road? What are the dependencies? Where are the designs described? Where is a list of fun low-entry projects? How do you get there from the front page? How is the project organized?

Now that you are moving DMD to D, you surely can need some help with refactoring... That means you'll have do to design on paper that others can implement.

Why did you spend time on remaking the web site when several capable people were willing? What was the road block? The build system? The approval process? Why didn't you approve a design on paper and let someone else execute it?

Which one is the official production compiler? DMD, GDC, LDC or SDC? None? That's a roadblock by itself.

On Thursday, 16 April 2015 at 06:02:19 UTC, Andrei Alexandrescu wrote:
> This is good stuff. FWIW we do have a keyword "preapproved" on bugzilla:
>
> https://issues.dlang.org/buglist.cgi?f1=keywords&list_id=200200&o1=equals&query_format=advanced&resolution=---&v1=preapproved
>
> It has 23 items of various ages. I didn't notice the presence of the keyword helping in any way. So spending time annotating issues with "preapproved" is possibly a waste of time. I suspect maintaining lists of stuff to do is also low-impact.

Is this keyword documented somewhere easily accessible, like on the wiki?  If not, how do you expect someone new and looking for a way to contribute to find it?  I agree that it's unlikely that someone will saunter in and learn the codebase and provide good fixes in their spare time, which is why I remain skeptical of the open source approach taken by the D community.  But there are ways to encourage more open source contribution, and prioritized lists are one of them.

> Yeah, we know what to do. A ton of it is easy to derive directly from the vision, do I need to provide the food already chewed? Eliminate gratuitous garbage from Phobos, create good unique and reference counted types (and see if we need something beside DIP25 to make them safe), improve associative arrays (apparently there's no reasonable way to free an AA manually...), documentation, documentation, documentation... there's a bunch of stuff to do all over the difficulty spectrum. It's painfully trivial to find easy and high impact stuff to work on. That's not low-hanging fruit, it's fruit that falls into one's lap.

The problem is that there's so much "fruit" in bugzilla that someone new is overwhelmed.  If they're not scratching their own itch, how do they know whether the random issue they've chosen is actually a priority?  If you want to pull new people from outside the core team, you need to provide them an easy way in, such as an easily found, prioritized list from the core team, after which they may realize it's not so hard after all, and stick around and provide more.  Yes, you're holding their hands initially, but if it leads to the core team getting larger, that's well worth it.

> Now that I got started, there are two more topics that I think we could do a lot better at:
>
> 1. Challenging Walter on anything and everything seems to have become a rite of passage in our community. Some of the reviews of his code are the most petty and meaningless I've seen in my career, bar none. It doesn't help that he doesn't budge on some of the petty issues, thus a vicious circle gets created. In a recent review, after his code had been pecked within an inch of its death, it took me minutes to find two bugs that nobody had the eyes for in spite of every token of his code having been scrutinized.

I've been surprised by how much people challenge him on the forums, seemingly ignoring the fact that he's been writing compilers for decades.  He's been very patient in explaining his viewpoint on the forums, which is a big plus for the community, though it would be better if he didn't have to repeat himself so many times.

> 2. Turning the hay over and over and over again. I've mentioned this before - there's just an astounding amount of tweaking and shuffling and moving around code that works well under serious-sounding pretexts such as "refactoring" and "maintenance". Sometimes really difficult stuff, too. A lot of it is low-impact work that makes Phobos' codebase look horribly overcooked. There's been more than one instance when I revisited some file I knew most of the code of. Elegant solutions. Nimble code. Just to find it mutated into the stuff of Agent Smith's world. One horrible contraption layered on top of another to the extent it's difficult to find where work is being done.
>
> There is a way out of this, and that for us all to give good examples that demonstrate what good contributions are and what good reviews are.

Sure, and lists of priority issues can even emphasize to the current contributors which high-impact work you feel should be done first.

You have pointed out which direction you want the community to go in the vision document, but some of those are too broad, ie "improve quality."  Stick some meat on those bones, by providing a list of issues you feel would move those agendas forward, and you might get the language moving further in your direction.

On Thursday, 16 April 2015 at 08:12:59 UTC, Joakim wrote:
> for a way to contribute to find it?  I agree that it's unlikely that someone will saunter in and learn the codebase and provide good fixes in their spare time, which is why I remain skeptical of the open source approach taken by the D community.

Yet again, people do learn parts of the code base and create their own version of it... Like ketmar and I, and probably others too.

To some people the main road block is a total disregard for CS as a profession in the D community. The language design discussions that moves outside C++ are like watching people building their own house without reading up on the topic then telling the carpenter that they are completely clueless for pointing out some real issues that will actually make the house rot. Like putting the damp sealing on the outside of the wall rather than on the inside, clearly you should put it where it rains? (Nope, the humidity is coming from inside the house in winter).

Too much NiH and ignorance wears out people with a CS background and they leave, which incidentally are the people you need the most for designing novel language features! There's a big difference between implementing a spec and designing it. Stick to Simula/Java and you are safe. Stick to C++ and you get some of their problems. Invent your own without spending time on PLT and you'll never get done.

Still, D is better off than the BitC community, which have very educated discussions. So it is safe to say that to pull it off you also have to be stubborn even when you are wrong (otherwise you'll just redesign over and over and over). A hard balance to get right. C++ is getting there (after being wrong). I think D can too.

On Thursday, 16 April 2015 at 05:01:16 UTC, H. S. Teoh wrote:
> This is why I've reduced my participation in forum threads... It's much
> more productive to submit PRs than to engage in endless debates that, at
> the end of the day, don't have very much to show for the amount of
> energy expended in the discussion.

I was about to joke how quickly this thread is going to degrade into another meaningless debate that has nothing to do with original post but looks like I am already too late.

On 4/16/15 1:12 AM, Joakim wrote:
[edited]

Cherry-picking one easy-to-address question:

> If they're not scratching their own itch, how do they know whether
> the random issue they've chosen is actually a priority?

That's simple - does it fit with the vision or not? Walter and I also find it useful to use that way.

> Sure, and lists of priority issues can even emphasize to the current
> contributors which high-impact work you feel should be done first.
>
> You have pointed out which direction you want the community to go in the
> vision document, but some of those are too broad, ie "improve quality."
> Stick some meat on those bones, by providing a list of issues you feel
> would move those agendas forward, and you might get the language moving
> further in your direction.

This is worth trying. I'll put a list together perhaps during the hackathon. The more difficult part will be maintaining it, which becomes a job - one extra thing on the plate of the same people. I guess the first item on the list will be "maintain the list". Deliciously self-referential :o).


Andrei

On Thursday, 16 April 2015 at 04:05:19 UTC, Andrei Alexandrescu wrote:
> On 4/15/15 8:42 PM, Joakim wrote:
>> On Wednesday, 15 April 2015 at 08:13:20 UTC, deadalnix wrote:
>>> OK, do not expect SDC to compile your code yet, but it got to a point
>>> where the base is fairly stable, and thing can get better. I compiled
>>> a list of high impact items, ranging from relatively easy bug fixes,
>>> to compiler guru level.
>>>
>>> https://github.com/deadalnix/SDC/wiki/TODO-list
>>>
>>> If some of you want to contribute, that'd be awesome. SDC can happen,
>>> and you can be a part of this, so go cloning the repo now :)
>>
>> That's a nice list to get more people involved.  I've been
>> calling for Andrei/Walter to put up a similar list on the D wiki,
>> with specific issues they think need dealing with or that would
>> be pre-approved.
>
> Forgive my being skeptical but my repeated appeals to contributions - most of them important, urgent, and of high impact - sometimes labeled with [WORK] in this forum, have been answered by the same very small kernel of contributors (including Walter and myself), regardless of their difficulty (sometimes trivial). Lists, labels, management techniques that are touted in this forum every few months or so - no avail. The vision document that everybody asked about? Read and dutifully ignored - back to the next naming debate. The sad reality is that if one of about a handful of core folks doesn't do it, it won't get done. My resolution is to do more of everything; that way more of everything will get done. -- Andrei

In my case I don't know where to start. I'll leave the Phobos and compiler code to the experts, but I'm sure I can help with documentation. On my own small projects, I can clone a repo, make a small change, and create a pull request. If it were that simple, I'd already be contributing to the documentation, because the things that need improvement aren't hard to find.

Unfortunately I have no idea how to get started. All I can find is this:

"The source code for the D website, compiler, runtime library, and Phobos (the standard library), are all available on GitHub. Contributions to the source code are done via pull requests. Please note that contributions to DMD source code will only be accepted if the author agrees to have the copyright of the code assigned to Digital Mars.

To find something to work on, you can search the bug list for issues that you can help fix, or view the most-voted-for issue list."

How do I make changes to the documentation and then test them? How do I know that I'm not wasting my time? What guidelines am I supposed to follow?

Rather than open that can of worms, I spend my scarce time working on my own D libraries and showing my coauthors/students how to use them. The problem may be a steep learning curve combined with a lack of clarity about what is expected. I don't think the problem is that the rest of us are simply unwilling to contribute.

On Thursday, 16 April 2015 at 15:47:10 UTC, bachmeier wrote:
> On Thursday, 16 April 2015 at 04:05:19 UTC, Andrei Alexandrescu wrote:
>> On 4/15/15 8:42 PM, Joakim wrote:
>>> On Wednesday, 15 April 2015 at 08:13:20 UTC, deadalnix wrote:
>>>> OK, do not expect SDC to compile your code yet, but it got to a point
>>>> where the base is fairly stable, and thing can get better. I compiled
>>>> a list of high impact items, ranging from relatively easy bug fixes,
>>>> to compiler guru level.
>>>>
>>>> https://github.com/deadalnix/SDC/wiki/TODO-list
>>>>
>>>> If some of you want to contribute, that'd be awesome. SDC can happen,
>>>> and you can be a part of this, so go cloning the repo now :)
>>>
>>> That's a nice list to get more people involved.  I've been
>>> calling for Andrei/Walter to put up a similar list on the D wiki,
>>> with specific issues they think need dealing with or that would
>>> be pre-approved.
>>
>> Forgive my being skeptical but my repeated appeals to contributions - most of them important, urgent, and of high impact - sometimes labeled with [WORK] in this forum, have been answered by the same very small kernel of contributors (including Walter and myself), regardless of their difficulty (sometimes trivial). Lists, labels, management techniques that are touted in this forum every few months or so - no avail. The vision document that everybody asked about? Read and dutifully ignored - back to the next naming debate. The sad reality is that if one of about a handful of core folks doesn't do it, it won't get done. My resolution is to do more of everything; that way more of everything will get done. -- Andrei
>
> In my case I don't know where to start. I'll leave the Phobos and compiler code to the experts, but I'm sure I can help with documentation. On my own small projects, I can clone a repo, make a small change, and create a pull request. If it were that simple, I'd already be contributing to the documentation, because the things that need improvement aren't hard to find.
>
> Unfortunately I have no idea how to get started. All I can find is this:
>
> "The source code for the D website, compiler, runtime library, and Phobos (the standard library), are all available on GitHub. Contributions to the source code are done via pull requests. Please note that contributions to DMD source code will only be accepted if the author agrees to have the copyright of the code assigned to Digital Mars.
>
> To find something to work on, you can search the bug list for issues that you can help fix, or view the most-voted-for issue list."
>
> How do I make changes to the documentation and then test them? How do I know that I'm not wasting my time? What guidelines am I supposed to follow?
>
> Rather than open that can of worms, I spend my scarce time working on my own D libraries and showing my coauthors/students how to use them. The problem may be a steep learning curve combined with a lack of clarity about what is expected. I don't think the problem is that the rest of us are simply unwilling to contribute.


Relating to the first part of your post,
While it may seem daunting, I found the D community extremely helpful and welcoming to new people submitting PRs. Just make sure you mention you're new to contributing to D in your PR.

On 2015-04-16 16:49, Andrei Alexandrescu wrote:

> This is worth trying. I'll put a list together perhaps during the
> hackathon. The more difficult part will be maintaining it, which becomes
> a job - one extra thing on the plate of the same people. I guess the
> first item on the list will be "maintain the list". Deliciously
> self-referential :o).

There are some thing other developer are better suited for and some things are better suited to be handled by a project manager/owner.

Example, updating the website is something I would recommend delegating to someone else. Deciding the future of D sounds more a job for you and Walter.

-- 
/Jacob Carlborg

On 4/16/15 8:47 AM, bachmeier wrote:
> How do I make changes to the documentation and then test them?

Please let me know if https://github.com/D-Programming-Language/dlang.org/blob/master/CONTRIBUTING.md floats your boat. We should make it more visible, too. -- Andrei

On 4/16/15 9:51 AM, Jacob Carlborg wrote:
> Example, updating the website is something I would recommend delegating
> to someone else.

Good example. The question is who'd want to take that job. -- Andrei