I've been on somewhat of a hiatus these past few months and have only worked on D-related development sporadically.  There are several reasons for my absence, some of which will hopefully change soon, and I hope to make a comeback.  Below are the reasons why my contributions have declined and some suggestions for improvements to the D community where the issues aren't specific to me:

0.  There's a lot less stuff that's broken or missing now than a few years ago when I started contributing.  This has led to a mild complacency as D is already awesome.  For example, it's been a long time since I hit a compiler bug that caused me significant hassle.

1.  I'm writing my Ph.D. thesis and looking for jobs.  I still have some time to contribute, but D development isn't the top idea in my mind due to these distractions.  This is in some ways the root of the problem, as I have less time and mental energy to keep up with D through informal channels.  I think my job search is over, though, so that's one less distraction.

2.  Because I'm writing my thesis, I don't program much for my research anymore.  I therefore don't notice little things that are broken or get cool ideas from other languages as often.  To make it easier for someone to find bugs and enchancement requests in areas he/she is already familiar with, I'd like to see an ability to search by module (for Phobos/druntime) or feature (for DMD) in Bugzilla.  For example, in Phobos I'm most familiar with std.range, std.algorithm, std.parallelism and std.functional.  I'd like to be able to easily query a list of bugs specific to those modules.

3.  As the community has grown larger, more people besides me have stepped up.  Of course this is a good thing.  The only downside is that I've lost track of who's working on what, what its status is, what still needs to be done, and what the holdups are.  Perhaps we need some central place other than this newsgroup where this information is posted for key D projects.  For example, we'd have a page that says "Person X is working on a new std.xml.  Here's the Github repository.  It's stalled because noone can agree on a design for Y."  We should also maintain a slightly more formal wishlist of stuff that noone's working on that's waiting to be done.

BTW, if noone is working on a new std.xml anymore, I might want to start.  I interviewed for a job where they wanted me to do a small prototype as part of the hiring process that involved parsing XML.  I was allowed to use any language I wanted.  I think my D projects played a large role in me getting an offer, but I couldn't use it for the prototype because std.xml is so bad.  I ended up using Python instead.

4.  The release cycle has slowed greatly.  What happened here?  The 1-2 month release cycles were a good motivator because they created mild deadline pressure to get features and fixes checked in before the next release.

5.  The amount of stuff on this forum and the mailing lists has become overwhelming.  I've recently remedied this to a small degree by unsubscribing from dmd-internals.  I've never been a contributor to the compiler itself and had only subscribed to this list to track bug fixes and 64-bit support implementation.  Now, the signal-to-noise ratio of my inbox is good enough that I actually read the Phobos and druntime stuff again instead of just glossing over all my D-related email.

As far as this forum, I suggest a split something like the following, so that it has a better signal-to-noise ratio from the perspective of people with specific interests:

D.language-design:  Long, complicated threads about language features and the theory behind them belong here.

D.phobos-design:  Since the Phobos mailing list is intended mostly for regular contributors and is focused on individual pull requests and commits, this is where high-level design stuff would get discussed w.r.t. Phobos.

D.ecosystem:  Stuff about third-party libraries, Deimos, toolchains, etc. goes here.

D.adoption:  Discussions about why D was or wasn't adopted for a given project and how to increase its adoption go here.

D.learn:  Questions about using D.  We already have this, but we need to encourage people to use it more instead of posting to the main group.

On 15-07-2012 06:02, dsimcha wrote:
> I've been on somewhat of a hiatus these past few months and have only
> worked on D-related development sporadically.  There are several reasons
> for my absence, some of which will hopefully change soon, and I hope to
> make a comeback.  Below are the reasons why my contributions have
> declined and some suggestions for improvements to the D community where
> the issues aren't specific to me:
>
> 0.  There's a lot less stuff that's broken or missing now than a few
> years ago when I started contributing.  This has led to a mild
> complacency as D is already awesome.  For example, it's been a long time
> since I hit a compiler bug that caused me significant hassle.

Indeed! Things have gotten a lot better as of late.

>
> 1.  I'm writing my Ph.D. thesis and looking for jobs.  I still have some
> time to contribute, but D development isn't the top idea in my mind due
> to these distractions.  This is in some ways the root of the problem, as
> I have less time and mental energy to keep up with D through informal
> channels.  I think my job search is over, though, so that's one less
> distraction.
>
> 2.  Because I'm writing my thesis, I don't program much for my research
> anymore.  I therefore don't notice little things that are broken or get
> cool ideas from other languages as often.  To make it easier for someone
> to find bugs and enchancement requests in areas he/she is already
> familiar with, I'd like to see an ability to search by module (for
> Phobos/druntime) or feature (for DMD) in Bugzilla.  For example, in
> Phobos I'm most familiar with std.range, std.algorithm, std.parallelism
> and std.functional.  I'd like to be able to easily query a list of bugs
> specific to those modules.

+1.

>
> 3.  As the community has grown larger, more people besides me have
> stepped up.  Of course this is a good thing.  The only downside is that
> I've lost track of who's working on what, what its status is, what still
> needs to be done, and what the holdups are.  Perhaps we need some
> central place other than this newsgroup where this information is posted
> for key D projects.  For example, we'd have a page that says "Person X
> is working on a new std.xml.  Here's the Github repository.  It's
> stalled because noone can agree on a design for Y."  We should also
> maintain a slightly more formal wishlist of stuff that noone's working
> on that's waiting to be done.

We should use Trello much more than we do now: https://trello.com/dlang

I've also been keeping an eye on Phabricator (http://phabricator.org)...

>
> BTW, if noone is working on a new std.xml anymore, I might want to
> start.  I interviewed for a job where they wanted me to do a small
> prototype as part of the hiring process that involved parsing XML.  I
> was allowed to use any language I wanted.  I think my D projects played
> a large role in me getting an offer, but I couldn't use it for the
> prototype because std.xml is so bad.  I ended up using Python instead.
>
> 4.  The release cycle has slowed greatly.  What happened here?  The 1-2
> month release cycles were a good motivator because they created mild
> deadline pressure to get features and fixes checked in before the next
> release.

I'm not actually sure what happened here. I suspect the problem is that most people are against releasing with regressions, but there's no one to actually fix them.

>
> 5.  The amount of stuff on this forum and the mailing lists has become
> overwhelming.  I've recently remedied this to a small degree by
> unsubscribing from dmd-internals.  I've never been a contributor to the
> compiler itself and had only subscribed to this list to track bug fixes
> and 64-bit support implementation.  Now, the signal-to-noise ratio of my
> inbox is good enough that I actually read the Phobos and druntime stuff
> again instead of just glossing over all my D-related email.
>
> As far as this forum, I suggest a split something like the following, so
> that it has a better signal-to-noise ratio from the perspective of
> people with specific interests:
>
> D.language-design:  Long, complicated threads about language features
> and the theory behind them belong here.
>
> D.phobos-design:  Since the Phobos mailing list is intended mostly for
> regular contributors and is focused on individual pull requests and
> commits, this is where high-level design stuff would get discussed
> w.r.t. Phobos.
>
> D.ecosystem:  Stuff about third-party libraries, Deimos, toolchains,
> etc. goes here.
>
> D.adoption:  Discussions about why D was or wasn't adopted for a given
> project and how to increase its adoption go here.
>
> D.learn:  Questions about using D.  We already have this, but we need to
> encourage people to use it more instead of posting to the main group.

I agree with all of these. The main D newsgroup has way too many things going on at the same time. We've needed this split badly for a while.

I would also suggest a forum for druntime/GC development and design. Whether it would be used, I don't know, but I think it's worth trying. Sometimes it's hard to get replies on the druntime mailing list, and I think a newsgroup would help here, since it's more persistent in nature.

-- 
Alex Rønne Petersen
alex@lycus.org
http://lycus.org

On Sunday, July 15, 2012 00:02:09 dsimcha wrote:
> BTW, if noone is working on a new std.xml anymore, I might want to start.  I interviewed for a job where they wanted me to do a small prototype as part of the hiring process that involved parsing XML.  I was allowed to use any language I wanted.  I think my D projects played a large role in me getting an offer, but I couldn't use it for the prototype because std.xml is so bad.  I ended up using Python instead.

Someone was working on it (Tomaz?) and was supposedly making good progress, but last time I checked, they hadn't posted anything since some time in 2010. So, as far as I can tell, that project is effectively dead. I have no idea what state it was in before it stalled or whether the code is available anywhere online. I expect that anyone who wants to work on it will either have to start from scratch or grabbing one of the existing xml parsers floating around and adjust it (though I suspect that if it's going to be range-based like it's supposed to be that any existing parsers floating around probably would need quite a bit of work to get the right API, but I don't know). It's the sort of thing that I'd love to work on given the time, but I have so much else going on that it would be ridiculous for me to even consider it. If you want to take up that baton, then I think that's great. Even if you end up taking a while to do it, that's better than getting nothing and seeing no progress as we have been for quite some time now.

- Jonathan M Davis

On 7/15/2012 4:54 AM, Jonathan M Davis wrote:
> On Sunday, July 15, 2012 00:02:09 dsimcha wrote:
>> BTW, if noone is working on a new std.xml anymore, I might want to
>> start.  I interviewed for a job where they wanted me to do a small
>> prototype as part of the hiring process that involved parsing XML.  I
>> was allowed to use any language I wanted.  I think my D projects played
>> a large role in me getting an offer, but I couldn't use it for the
>> prototype because std.xml is so bad.  I ended up using Python instead.
>
> Someone was working on it (Tomaz?) and was supposedly making good progress,
> but last time I checked, they hadn't posted anything since some time in 2010.
> So, as far as I can tell, that project is effectively dead. I have no idea what
> state it was in before it stalled or whether the code is available anywhere
> online. I expect that anyone who wants to work on it will either have to start
> from scratch or grabbing one of the existing xml parsers floating around and
> adjust it (though I suspect that if it's going to be range-based like it's
> supposed to be that any existing parsers floating around probably would need
> quite a bit of work to get the right API, but I don't know). It's the sort of
> thing that I'd love to work on given the time, but I have so much else going
> on that it would be ridiculous for me to even consider it. If you want to take
> up that baton, then I think that's great. Even if you end up taking a while to
> do it, that's better than getting nothing and seeing no progress as we have
> been for quite some time now.
>
> - Jonathan M Davis
>


Ok, well I'll at least try to get a better handle on what's involved and how much time I'm going to have over the next few months.  I'm not saying I definitely want to take it on yet.

On 7/15/12 9:38 AM, dsimcha wrote:
[about std.xml]
> Ok, well I'll at least try to get a better handle on what's involved and
> how much time I'm going to have over the next few months. I'm not saying
> I definitely want to take it on yet.

FWIW, it would be great if you worked on std.xml.

Andrei

On Sunday, 15 July 2012 at 04:02:48 UTC, dsimcha wrote:
> 5.  The amount of stuff on this forum and the mailing lists has become overwhelming.  I've recently remedied this to a small degree by unsubscribing from dmd-internals.  I've never been a contributor to the compiler itself and had only subscribed to this list to track bug fixes and 64-bit support implementation.
>  Now, the signal-to-noise ratio of my inbox is good enough that I actually read the Phobos and druntime stuff again instead of just glossing over all my D-related email.

I take it you are referring to the GitHub commit messages which are relayed to dmd-internals? Because except for those (which I just made a filter rule for), the list is really quite low-volume. Maybe we should create a dedicated d-commits list to which all the GitHub notifications get sent, similar to what other projects have? The occasional post-commit discussion could then be continued on one of the repository-specific lists, just like they are now.

David

On Sunday, 15 July 2012 at 15:46:38 UTC, David Nadlinger wrote:
> On Sunday, 15 July 2012 at 04:02:48 UTC, dsimcha wrote:
>> 5.  The amount of stuff on this forum and the mailing lists has become overwhelming.  I've recently remedied this to a small degree by unsubscribing from dmd-internals.  I've never been a contributor to the compiler itself and had only subscribed to this list to track bug fixes and 64-bit support implementation.
>> Now, the signal-to-noise ratio of my inbox is good enough that I actually read the Phobos and druntime stuff again instead of just glossing over all my D-related email.
>
> I take it you are referring to the GitHub commit messages which are relayed to dmd-internals? Because except for those (which I just made a filter rule for), the list is really quite low-volume. Maybe we should create a dedicated d-commits list to which all the GitHub notifications get sent, similar to what other projects have? The occasional post-commit discussion could then be continued on one of the repository-specific lists, just like they are now.
>
> David

Yeah.  The problem is that for a while, D mailing lists became so overwhelming that I got into the habit of reflexively ignoring them completely due to poor signal-to-noise ratio w.r.t stuff I actually work on and being preoccupied with other things.  Your idea may be a good one, since only the core DMD devs care about every commit but others might want to participate in higher level discussions.