www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - (DO NOT POST TO HACKERNEWS/REDDIT/ETC.) RFC for a Community Newsletter

reply "Meta" <jared771 gmail.com> writes:
Thanks to an unexpected free afternoon due to a brutal spring 
blizzard, and large amount of caffeine, I've come up with an 
initial draft of a D newsletter. It's tentatively named "What's 
New in D", and it's purpose is to aggregate the important 
community news in one place, as well as to give D some 
well-deserved publicity.

As I said, this is an initial rough draft to show how I envision 
the basic format. The end product, of course, will not be hosted 
on Google Docs... I've been considering using GitHub Pages to 
host it, but if anyone has a better suggestion, please let me 
know. I think it would be really neat to write these newsletters 
in DDOC, but I know barely anything about DDOC.

The current format is somewhat similar to This Week in Rust. A 
little opening blurb, followed by a paragraph detailing any 
recent articles, followed by a couple of the big announcements, 
which each get a whole paragraph to themselves, followed by a 
list of one-line smaller announcements. Next is Community 
Overview, with another short introductory paragraph, and a couple 
of paragraphs detailing interesting discussions from the 
newsgroup.

After that is a list of new pull requests and commits to master. 
This is the section that needs the most work; right now, it's 
just two bulleted lists of two pulls/commits each, separated by 
whether they were made to DMD/Phobos/Druntime. In the finished 
product, these sections will contain all or most of the recent 
pulls/commits... which leads me to worry that it could turn into 
a space issue. However, if I prune the lists to include only what 
I think is interesting, somebody is bound to get upset (probably 
rightly so). On the other hand, if I just randomly pick, some of 
the good stuff will inevitably get passed over. I'm not sure how 
to handle this fairly. Thoughts?

Last is Miscellania. for Adopt a Bug Report and Adopt a Bounty, 
I'll choose a random bug report/bounty that people can tackle (or 
not). The whole point is to try to mitigate the fact that a lot 
of bug reports and/or bounties can go a long time without any 
action, and get buried under new stuff coming in. I also 
considered Adopt a Pull Request, to let people know about pull 
requests sitting around without getting a review. I also included 
Music for Hackers as a sort of fun little afterthought. Thoughts?

Most of my time spent writing this was trawling through the 
newsgroup and Github to find stuff, but I'm hoping that once this 
gets going, people will email me a lot of the stuff to be 
included in the newsletter. Dicebot has already offered to let me 
know about stuff he notices, and I'd really like to get the word 
out that I'm looking for interesting/noteworthy submissions (I 
set up a new email for this: Whats.New.in.D gmail.com).

You might notice that I went out of my way to avoid any mention 
of a specific interval for the newsletter. That's because I'm not 
really sure whether it should be weekly or bi-weekly. I went in 
thinking that bi-weekly would be best, as to avoid those slow 
weeks with little newsworthy items, but I ended up having much 
more than I expect in just the time period from ~March 23-April 
1, which suggests to me that a weekly format might be preferable.

This raises an issue, however. I'm a university student, and 
while I'm currently working, I'll be returning to school in the 
fall. I'm worried that during extremely busy weeks, as well as 
during midterms and exams, I won't have the time to get 
everything in order. The only solution I can think of is to have 
a couple of people who would be willing to release the issue if 
I'm unable to for whatever reason. I expect this to be a rare 
occurrence, but it must be accounted for, so if there were just a 
few people willing to volunteer in case of such a eventuality, 
I'd be grateful.

The last thing is licensing, for completeness. Maybe I'm 
overthinking this, but why not shore up a potential hole while it 
still exists? I think either Boost or GPL would be serviceable.

Obviously none of this is final, and I'm willing to change up 
most of it if somebody has a better idea. I'm not crazy about 
having multiple big lists of links (announcements, pull requests, 
commits), so I'd really appreciate input on that, as well as 
suggestions for other sections to add/replace.

You can view the rought draft here.

https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing

Again, please DO NOT submit this to Hackernews/Reddit, etc., as 
it needs a lot more work before it's ready for public consumption.

DO destroy.
Apr 01 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

 Thanks to an unexpected free afternoon due to a brutal spring 
 blizzard, and large amount of caffeine, I've come up with an 
 initial draft of a D newsletter. It's tentatively named "What's 
 New in D", and it's purpose is to aggregate the important 
 community news in one place, as well as to give D some 
 well-deserved publicity.

 As I said, this is an initial rough draft to show how I 
 envision the basic format. The end product, of course, will not 
 be hosted on Google Docs... I've been considering using GitHub 
 Pages to host it, but if anyone has a better suggestion, please 
 let me know. I think it would be really neat to write these 
 newsletters in DDOC, but I know barely anything about DDOC.

 The current format is somewhat similar to This Week in Rust. A 
 little opening blurb, followed by a paragraph detailing any 
 recent articles, followed by a couple of the big announcements, 
 which each get a whole paragraph to themselves, followed by a 
 list of one-line smaller announcements. Next is Community 
 Overview, with another short introductory paragraph, and a 
 couple of paragraphs detailing interesting discussions from the 
 newsgroup.

 After that is a list of new pull requests and commits to 
 master. This is the section that needs the most work; right 
 now, it's just two bulleted lists of two pulls/commits each, 
 separated by whether they were made to DMD/Phobos/Druntime. In 
 the finished product, these sections will contain all or most 
 of the recent pulls/commits... which leads me to worry that it 
 could turn into a space issue. However, if I prune the lists to 
 include only what I think is interesting, somebody is bound to 
 get upset (probably rightly so). On the other hand, if I just 
 randomly pick, some of the good stuff will inevitably get 
 passed over. I'm not sure how to handle this fairly. Thoughts?

 Last is Miscellania. for Adopt a Bug Report and Adopt a Bounty, 
 I'll choose a random bug report/bounty that people can tackle 
 (or not). The whole point is to try to mitigate the fact that a 
 lot of bug reports and/or bounties can go a long time without 
 any action, and get buried under new stuff coming in. I also 
 considered Adopt a Pull Request, to let people know about pull 
 requests sitting around without getting a review. I also 
 included Music for Hackers as a sort of fun little 
 afterthought. Thoughts?

 Most of my time spent writing this was trawling through the 
 newsgroup and Github to find stuff, but I'm hoping that once 
 this gets going, people will email me a lot of the stuff to be 
 included in the newsletter. Dicebot has already offered to let 
 me know about stuff he notices, and I'd really like to get the 
 word out that I'm looking for interesting/noteworthy 
 submissions (I set up a new email for this: 
 Whats.New.in.D gmail.com).

 You might notice that I went out of my way to avoid any mention 
 of a specific interval for the newsletter. That's because I'm 
 not really sure whether it should be weekly or bi-weekly. I 
 went in thinking that bi-weekly would be best, as to avoid 
 those slow weeks with little newsworthy items, but I ended up 
 having much more than I expect in just the time period from 
 ~March 23-April 1, which suggests to me that a weekly format 
 might be preferable.

 This raises an issue, however. I'm a university student, and 
 while I'm currently working, I'll be returning to school in the 
 fall. I'm worried that during extremely busy weeks, as well as 
 during midterms and exams, I won't have the time to get 
 everything in order. The only solution I can think of is to 
 have a couple of people who would be willing to release the 
 issue if I'm unable to for whatever reason. I expect this to be 
 a rare occurrence, but it must be accounted for, so if there 
 were just a few people willing to volunteer in case of such a 
 eventuality, I'd be grateful.

 The last thing is licensing, for completeness. Maybe I'm 
 overthinking this, but why not shore up a potential hole while 
 it still exists? I think either Boost or GPL would be 
 serviceable.

 Obviously none of this is final, and I'm willing to change up 
 most of it if somebody has a better idea. I'm not crazy about 
 having multiple big lists of links (announcements, pull 
 requests, commits), so I'd really appreciate input on that, as 
 well as suggestions for other sections to add/replace.

 You can view the rought draft here.

 https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing

 Again, please DO NOT submit this to Hackernews/Reddit, etc., as 
 it needs a lot more work before it's ready for public 
 consumption.

 DO destroy.


Looks good.

http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d

Vote up, everyone!
Apr 01 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:

 Looks good.

 http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d

 Vote up, everyone!


Please remove this, as I explicitly asked it not to be posted yet.
Apr 01 2014
next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 1 April 2014 at 23:30:02 UTC, Meta wrote:

 On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:

 Looks good.

 http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d

 Vote up, everyone!


 Please remove this, as I explicitly asked it not to be posted 
 yet.


Seemed like an appropriate day to make this joke :). No removal 
needed (it's not a real link).
Apr 01 2014
next sibling parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 1 April 2014 at 23:33:48 UTC, Brad Anderson wrote:

 On Tuesday, 1 April 2014 at 23:30:02 UTC, Meta wrote:

 On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:

 Looks good.

 http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d

 Vote up, everyone!


 Please remove this, as I explicitly asked it not to be posted 
 yet.


 Seemed like an appropriate day to make this joke :). No removal 
 needed (it's not a real link).


Ha, I forgot it was April Fool's today. You nearly gave me a 
heart attack.
Apr 01 2014
prev sibling next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/14, 4:33 PM, Brad Anderson wrote:

 On Tuesday, 1 April 2014 at 23:30:02 UTC, Meta wrote:

 On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:

 Looks good.

 http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d


 Vote up, everyone!


 Please remove this, as I explicitly asked it not to be posted yet.


 Seemed like an appropriate day to make this joke :). No removal needed
 (it's not a real link).


Got a good laugh! -- Andrei
Apr 01 2014
prev sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
On Tue, 01 Apr 2014 19:33:47 -0400, Brad Anderson <eco gnuk.net> wrote:


 On Tuesday, 1 April 2014 at 23:30:02 UTC, Meta wrote:

 On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:

 Looks good.

 http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d

 Vote up, everyone!


 Please remove this, as I explicitly asked it not to be posted yet.


 Seemed like an appropriate day to make this joke :). No removal needed  
 (it's not a real link).


I've been on alert all day today. This still got me :)

-Steve
Apr 01 2014
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/14, 4:30 PM, Meta wrote:

 On Tuesday, 1 April 2014 at 23:28:31 UTC, Brad Anderson wrote:

 Looks good.

 http://www.reddit.com/r/programming/comments/2fjk2ti/a_community_newsletter_for_d


 Vote up, everyone!


 Please remove this, as I explicitly asked it not to be posted yet.


Let's also note how incredibly polite this was! -- Andrei
Apr 01 2014
next sibling parent "bearophile" <bearophileHUGS lycos.com> writes:
Andrei Alexandrescu:


 Let's also note how incredibly polite this was! -- Andrei


I agree. Meta is good.

Bye,
bearophile
Apr 01 2014
prev sibling parent "Mike" <none none.com> writes:
On Wednesday, 2 April 2014 at 00:56:29 UTC, Andrei Alexandrescu 
wrote:

 On 4/1/14, 4:30 PM, Meta wrote:

 Please remove this, as I explicitly asked it not to be posted 
 yet.


 Let's also note how incredibly polite this was! -- Andrei


+1.  Indeed!
Apr 01 2014
prev sibling next sibling parent reply "Brad Anderson" <eco gnuk.net> writes:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

 https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing


The link requires access to be granted to view (it lets you 
request access). Perhaps this was intentional but I thought you 
should know.
Apr 01 2014
parent "Meta" <jared771 gmail.com> writes:
On Tuesday, 1 April 2014 at 23:35:55 UTC, Brad Anderson wrote:

 On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

 https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing


 The link requires access to be granted to view (it lets you 
 request access). Perhaps this was intentional but I thought you 
 should know.


Yes, I revoked access as soon as I saw the Reddit link =) It's 
back now.
Apr 01 2014
prev sibling next sibling parent reply "Mike" <none none.com> writes:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

This is really great!


 Most of my time spent writing this was trawling through the 
 newsgroup and Github to find stuff, but I'm hoping that once 
 this gets going, people will email me a lot of the stuff to be 
 included in the newsletter. Dicebot has already offered to let 
 me know about stuff he notices, and I'd really like to get the 
 word out that I'm looking for interesting/noteworthy 
 submissions (I set up a new email for this: 
 Whats.New.in.D gmail.com).


I think the email will work well, but it might also be nice to 
have a public document that contributors could edit directly.  It 
might save you some cutting/pasting/word-smithing time.  Maybe 
then all you would need to do is perform a final edit.  Wiki or 
Github, mabye? (or maybe not)


 You might notice that I went out of my way to avoid any mention 
 of a specific interval for the newsletter. That's because I'm 
 not really sure whether it should be weekly or bi-weekly. I 
 went in thinking that bi-weekly would be best, as to avoid 
 those slow weeks with little newsworthy items, but I ended up 
 having much more than I expect in just the time period from 
 ~March 23-April 1, which suggests to me that a weekly format 
 might be preferable.


If you (us?) can keep it up every week, that would be nice.  But 
if it starts with weekly, beware the commitment and readers' 
expectations.


 This raises an issue, however. I'm a university student, and 
 while I'm currently working, I'll be returning to school in the 
 fall. I'm worried that during extremely busy weeks, as well as 
 during midterms and exams, I won't have the time to get 
 everything in order. The only solution I can think of is to 
 have a couple of people who would be willing to release the 
 issue if I'm unable to for whatever reason. I expect this to be 
 a rare occurrence, but it must be accounted for, so if there 
 were just a few people willing to volunteer in case of such a 
 eventuality, I'd be grateful.


Having to do the same thing every week can get old, too.  Again, 
I think some way for the general D public to contribute directly 
would help with this, but I know that has the potential to become 
a management nightmare in itself.



 Obviously none of this is final, and I'm willing to change up 
 most of it if somebody has a better idea. I'm not crazy about 
 having multiple big lists of links (announcements, pull 
 requests, commits), so I'd really appreciate input on that, as 
 well as suggestions for other sections to add/replace.


I hate to suggest things I can't do myself, but a stats section 
might be nice.  For example:
x bugs opened
x bugs closed
x pull requests submitted
x pull requests merged
x pull requests closed
x pull request waiting for Walter/Andrei ;-)
etc...

I've seen some talent here in this community make some really 
fantastic tools, and maybe this is something someone could throw 
together easily and just execute once a week.

What are your plans for publication and distribution?

And where will they be stored so one could reminisce in nostalgia?

Thanks for this!
Mike
Apr 01 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 2 April 2014 at 00:25:08 UTC, Mike wrote:

 I think the email will work well, but it might also be nice to 
 have a public document that contributors could edit directly.  
 It might save you some cutting/pasting/word-smithing time.  
 Maybe then all you would need to do is perform a final edit.  
 Wiki or Github, mabye? (or maybe not)


I entertained the idea of hosting it on GitHub. This would make 
"moderation" of submissions in the form of pull requests fairly 
simple. The drawback of this, however, is that anyone can see 
each issue long before it is finished, diminishing the "impact" 
of the actual release. Maybe this isn't a huge problem, though.



 If you (us?) can keep it up every week, that would be nice.  
 But if it starts with weekly, beware the commitment and 
 readers' expectations.


Seeing as I have never maintained something like this before, 
maybe it *would* be best to start out bi-weekly. I do not have a 
clear idea of how much work subsequent issues will take. This is 
more or less unknown territory for me.



 Having to do the same thing every week can get old, too.  
 Again, I think some way for the general D public to contribute 
 directly would help with this, but I know that has the 
 potential to become a management nightmare in itself.


With a few other volunteers, we could take turns round-robin 
style. It depends on who else wants to volunteer their time, I 
guess. The more I think about having a community-contributed list 
on Github, the more I like it, but that seems to conflict with 
why I'm doing this in the first place, i.e., nobody else wants to 
do it.



 I hate to suggest things I can't do myself, but a stats section 
 might be nice.  For example:
 x bugs opened
 x bugs closed
 x pull requests submitted
 x pull requests merged
 x pull requests closed
 x pull request waiting for Walter/Andrei ;-)
 etc...


That is a good idea, but it would be extremely tedious and 
annoying to do by hand.


 I've seen some talent here in this community make some really 
 fantastic tools, and maybe this is something someone could 
 throw together easily and just execute once a week.


If somebody wants to generate these statistics, I will be more 
than happy to include them.



 What are your plans for publication and distribution?
 And where will they be stored so one could reminisce in 
 nostalgia?


Publication is probably too formal of a word. TWiR does it 
blog-style, hosting it on GitHub pages, and I don't see any 
reason why I shouldn't do the same.
Apr 01 2014
parent "Joakim" <dlang joakim.airpost.net> writes:
On Wednesday, 2 April 2014 at 00:50:56 UTC, Meta wrote:

 On Wednesday, 2 April 2014 at 00:25:08 UTC, Mike wrote:

 I think the email will work well, but it might also be nice to 
 have a public document that contributors could edit directly.  
 It might save you some cutting/pasting/word-smithing time.  
 Maybe then all you would need to do is perform a final edit.  
 Wiki or Github, mabye? (or maybe not)


 I entertained the idea of hosting it on GitHub. This would make 
 "moderation" of submissions in the form of pull requests fairly 
 simple. The drawback of this, however, is that anyone can see 
 each issue long before it is finished, diminishing the "impact" 
 of the actual release. Maybe this isn't a huge problem, though.


 Having to do the same thing every week can get old, too.  
 Again, I think some way for the general D public to contribute 
 directly would help with this, but I know that has the 
 potential to become a management nightmare in itself.


 With a few other volunteers, we could take turns round-robin 
 style. It depends on who else wants to volunteer their time, I 
 guess. The more I think about having a community-contributed 
 list on Github, the more I like it, but that seems to conflict 
 with why I'm doing this in the first place, i.e., nobody else 
 wants to do it.


Nice draft, looks good. I'll agree with others that you should 
crowdsource as much as possible.  Even if very few people ever 
contribute, it helps that the option is there and I imagine some 
will use it.  I think people being able to access the in-progress 
newsletter before release is a feature not a bug, for those who 
must know what's going on as it happens.  Most will probably just 
access it upon release.  I'm not a fan of using github for 
everything though, maybe the existing wiki would be a more 
lightweight way to collaborate?

I just ran across LLVM Weekly, a newsletter for the LLVM project 
started earlier this year, might be worth looking at.  They 
recently mentioned Warp, and the fact that clang still beats it, 
;) in their latest newsletter:

http://blog.llvm.org/2014/03/llvm-weekly-13-mar-31st-2014.html
Apr 04 2014
prev sibling next sibling parent reply "bearophile" <bearophileHUGS lycos.com> writes:
Meta:


 https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing


Looks quite nice. But I suggest to avoid this wizbang style of 
writing, and use one more fit for a technical newsletter:


It’s been an amazing couple of weeks for D. From some great 
discussion on the newsgroup to a batch of exciting new pull 
requests, the tireless machine that is the D community motors 
ever onward.<




 I'm worried that during extremely busy weeks, as well as during 
 midterms and exams, I won't have the time to get everything in 
 order.


To reduce the probability of such delays, and to make you less 
bored of this work in the following years, I suggest to make your 
work (to create a post) as fast as possible and as much automatic 
as possible. This means creating scripts for the automatic 
upload, etc.

Bye,
bearophile
Apr 01 2014
parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 2 April 2014 at 00:26:58 UTC, bearophile wrote:

 Looks quite nice. But I suggest to avoid this wizbang style of 
 writing, and use one more fit for a technical newsletter:


I'm worried about it being too dry, as it's really just 
regurgitating information that's already freely available and 
probably has already been read by a lot of people who watch the 
newsgroup/Github. Also, we have to think about the image that the 
D community projects, so I'd like to keep a friendly and informal 
tone. However, perhaps the machine metaphor is a bit too 
poetic/pretentious.



 To reduce the probability of such delays, and to make you less 
 bored of this work in the following years, I suggest to make 
 your work (to create a post) as fast as possible and as much 
 automatic as possible. This means creating scripts for the 
 automatic upload, etc.


I agree. The problem is that I'm not entirely sure what I need 
currently, and I suspect that I won't know until I'm in the thick 
of things. It's good to keep in mind, however, that this is not 
meant to be a big professionally-produced undertaking (unless 
other people want to contribute and make it professional). I'm 
only one person, after all, so I do not want to be overly 
ambitious in scope.
Apr 01 2014
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
It's really quite awesome. Thank you!

Nit: Needs a prominent date display.
Apr 01 2014
prev sibling next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/14, 4:25 PM, Meta wrote:

 Thanks to an unexpected free afternoon due to a brutal spring blizzard,
 and large amount of caffeine, I've come up with an initial draft of a D
 newsletter. It's tentatively named "What's New in D", and it's purpose
 is to aggregate the important community news in one place, as well as to
 give D some well-deserved publicity.


This is awesome. I intentionally have little to say on the content 
proper because of the considerations that follow.

1. As one who led similar efforts (magazine columns etc) I concur that 
this is a marathon more than a jog.

2. Because of that, make sure whatever you do you get satisfaction from 
it. That means enjoying freedom to choose content and format etc. Do it 
the way it pleases you, of course with feedback from the community since 
you'll derive a good fraction of your enjoyment from the positive feedback.

3. Choose a pace that works for you, and try to keep it.

4. Accept contributions and contributors, but try to give the newsletter 
personality by writing it in your "voice".


Andrei
Apr 01 2014
next sibling parent "Mike" <none none.com> writes:
On Wednesday, 2 April 2014 at 01:05:31 UTC, Andrei Alexandrescu 
wrote:

 On 4/1/14, 4:25 PM, Meta wrote:

 This is awesome. I intentionally have little to say on the 
 content proper because of the considerations that follow.

 1. As one who led similar efforts (magazine columns etc) I 
 concur that this is a marathon more than a jog.

 2. Because of that, make sure whatever you do you get 
 satisfaction from it. That means enjoying freedom to choose 
 content and format etc. Do it the way it pleases you, of course 
 with feedback from the community since you'll derive a good 
 fraction of your enjoyment from the positive feedback.

 3. Choose a pace that works for you, and try to keep it.

 4. Accept contributions and contributors, but try to give the 
 newsletter personality by writing it in your "voice".


 Andrei


Best advice I've read in years!  Could easily be applied to any 
new undertaking.
Apr 01 2014
prev sibling parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 2 April 2014 at 01:05:31 UTC, Andrei Alexandrescu 
wrote:

 This is awesome. I intentionally have little to say on the 
 content proper because of the considerations that follow.

 1. As one who led similar efforts (magazine columns etc) I 
 concur that this is a marathon more than a jog.

 2. Because of that, make sure whatever you do you get 
 satisfaction from it. That means enjoying freedom to choose 
 content and format etc. Do it the way it pleases you, of course 
 with feedback from the community since you'll derive a good 
 fraction of your enjoyment from the positive feedback.

 3. Choose a pace that works for you, and try to keep it.

 4. Accept contributions and contributors, but try to give the 
 newsletter personality by writing it in your "voice".


I will keep this in mind. Do you have any specific tips on 
"hidden" difficulties that come up?
Apr 01 2014
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/1/14, 6:15 PM, Meta wrote:

 I will keep this in mind. Do you have any specific tips on "hidden"
 difficulties that come up?


The worst for me was lacking the "inspiration of the month" when the 
deadline would be looming but I'd have no fresh ideas. Fortunately 
that's less likely to happen once you get into a habit, especially since 
a part of the work is aggregating stuff that's going about.

Other than that, it's just motivation, motivation, motivation. You've 
got to keep it up and understand that oftentimes a silent answer is 
positive, whereas negative feedback is more strident.


Andrei
Apr 01 2014
prev sibling next sibling parent "Rikki Cattermole" <alphaglosined gmail.com> writes:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

 Thanks to an unexpected free afternoon due to a brutal spring 
 blizzard, and large amount of caffeine, I've come up with an 
 initial draft of a D newsletter. It's tentatively named "What's 
 New in D", and it's purpose is to aggregate the important 
 community news in one place, as well as to give D some 
 well-deserved publicity.

 As I said, this is an initial rough draft to show how I 
 envision the basic format. The end product, of course, will not 
 be hosted on Google Docs... I've been considering using GitHub 
 Pages to host it, but if anyone has a better suggestion, please 
 let me know. I think it would be really neat to write these 
 newsletters in DDOC, but I know barely anything about DDOC.

 The current format is somewhat similar to This Week in Rust. A 
 little opening blurb, followed by a paragraph detailing any 
 recent articles, followed by a couple of the big announcements, 
 which each get a whole paragraph to themselves, followed by a 
 list of one-line smaller announcements. Next is Community 
 Overview, with another short introductory paragraph, and a 
 couple of paragraphs detailing interesting discussions from the 
 newsgroup.

 After that is a list of new pull requests and commits to 
 master. This is the section that needs the most work; right 
 now, it's just two bulleted lists of two pulls/commits each, 
 separated by whether they were made to DMD/Phobos/Druntime. In 
 the finished product, these sections will contain all or most 
 of the recent pulls/commits... which leads me to worry that it 
 could turn into a space issue. However, if I prune the lists to 
 include only what I think is interesting, somebody is bound to 
 get upset (probably rightly so). On the other hand, if I just 
 randomly pick, some of the good stuff will inevitably get 
 passed over. I'm not sure how to handle this fairly. Thoughts?

 Last is Miscellania. for Adopt a Bug Report and Adopt a Bounty, 
 I'll choose a random bug report/bounty that people can tackle 
 (or not). The whole point is to try to mitigate the fact that a 
 lot of bug reports and/or bounties can go a long time without 
 any action, and get buried under new stuff coming in. I also 
 considered Adopt a Pull Request, to let people know about pull 
 requests sitting around without getting a review. I also 
 included Music for Hackers as a sort of fun little 
 afterthought. Thoughts?

 Most of my time spent writing this was trawling through the 
 newsgroup and Github to find stuff, but I'm hoping that once 
 this gets going, people will email me a lot of the stuff to be 
 included in the newsletter. Dicebot has already offered to let 
 me know about stuff he notices, and I'd really like to get the 
 word out that I'm looking for interesting/noteworthy 
 submissions (I set up a new email for this: 
 Whats.New.in.D gmail.com).

 You might notice that I went out of my way to avoid any mention 
 of a specific interval for the newsletter. That's because I'm 
 not really sure whether it should be weekly or bi-weekly. I 
 went in thinking that bi-weekly would be best, as to avoid 
 those slow weeks with little newsworthy items, but I ended up 
 having much more than I expect in just the time period from 
 ~March 23-April 1, which suggests to me that a weekly format 
 might be preferable.

 This raises an issue, however. I'm a university student, and 
 while I'm currently working, I'll be returning to school in the 
 fall. I'm worried that during extremely busy weeks, as well as 
 during midterms and exams, I won't have the time to get 
 everything in order. The only solution I can think of is to 
 have a couple of people who would be willing to release the 
 issue if I'm unable to for whatever reason. I expect this to be 
 a rare occurrence, but it must be accounted for, so if there 
 were just a few people willing to volunteer in case of such a 
 eventuality, I'd be grateful.

 The last thing is licensing, for completeness. Maybe I'm 
 overthinking this, but why not shore up a potential hole while 
 it still exists? I think either Boost or GPL would be 
 serviceable.

 Obviously none of this is final, and I'm willing to change up 
 most of it if somebody has a better idea. I'm not crazy about 
 having multiple big lists of links (announcements, pull 
 requests, commits), so I'd really appreciate input on that, as 
 well as suggestions for other sections to add/replace.

 You can view the rought draft here.

 https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing

 Again, please DO NOT submit this to Hackernews/Reddit, etc., as 
 it needs a lot more work before it's ready for public 
 consumption.

 DO destroy.


Just an idea, however how would you feel about doing it as a 
github repository and that way anybody can edit the next edition. 
The only issue I can think of is getting github markdown to be 
rendered in e.g. an email. Or at least converted to something 
clients can understand.
At worse the issue tracker would be a great way to allow others 
to tell you about content ext.
Apr 01 2014
prev sibling next sibling parent reply "Dicebot" <public dicebot.lv> writes:
Awesome stuff there!

I do want to propose one fundamental change though - change 
grouping / ordering to be based on potential importance to the 
casual end user and not by information origin. For example, I am 
pretty sure that merged -vgc thing is more important from 
marketing point of view than half of actual announcements. Of 
course importance judgement will be biased but it is still better 
than unsorted list.

Don't forget that primary audience for such publication is 
someone who does not code in D now and/or actively follow the 
development but wants to be aware of "big things" to possibly 
reconsider. Plain pull request description list will likely to 
look quite cryptic.
Apr 02 2014
parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 2 April 2014 at 11:34:34 UTC, Dicebot wrote:

 Awesome stuff there!

 I do want to propose one fundamental change though - change 
 grouping / ordering to be based on potential importance to the 
 casual end user and not by information origin. For example, I 
 am pretty sure that merged -vgc thing is more important from 
 marketing point of view than half of actual announcements. Of 
 course importance judgement will be biased but it is still 
 better than unsorted list.


I mostly agree at this point, although in this case, I think 
Dconf news and Facebook open-sourcing Warp should still take 
precedence.


 Don't forget that primary audience for such publication is 
 someone who does not code in D now and/or actively follow the 
 development but wants to be aware of "big things" to possibly 
 reconsider. Plain pull request description list will likely to 
 look quite cryptic.


That's true. I'm thinking that maybe the pull requests should be 
limited to just a couple of the most important ones, with a 
paragraph or so explanation each. Then at the end I can provide 
links to each of the full PR lists on Github. Or maybe the Github 
links aren't necessary at all, as it is already linked in the 
introduction paragraph at the top of the page.
Apr 03 2014
prev sibling next sibling parent reply "Wyatt" <wyatt.epp gmail.com> writes:
This is a good base.  In general, I would suggest not shying away 
from subheadings.  It gives you more opportunities to catch the 
eye and tends to allow readers to see the parts that interest 
them more easily.  Conversely, making phrases links tends to make 
reading harder; would it be acceptable to just put the link 
after?  See below.

On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

 The current format is somewhat similar to This Week in Rust. A 
 little opening blurb, followed by a paragraph detailing any 
 recent articles


For articles, I'd also recommend a sentence or three describing 
what the article actually covers.  To clarify, I'm thinking 
something like this:





Atíla Neves talks about how he retooled his serialiser library to 
eliminate allocations and dramatically improve performance.  He 
explains the underlying idea in detail, then shows benchmarks 
covering the possible improvements he mentioned.

* [Atíla's Blog]($url)



Vladimir Panteleev has written a "highlights reel" post to 
demonstrate his overhauled graphics library with an emphasis on 
composition, laziness, and templating.

* [Vladimir's Blog]($url)


 followed by a couple of the big announcements, which each get a 
 whole paragraph to themselves


Broken up with subs, this is good.


 followed by a list of one-line smaller announcements.


Suggest bulleted list, maybe below the important NG threads.  But 
what qualifies as a smaller announcement?


 Next is Community Overview, with another short introductory 
 paragraph, and a couple of paragraphs detailing interesting 
 discussions from the newsgroup.


See the articles suggestion.


 However, if I prune the lists to include only what I think is 
 interesting, somebody is bound to get upset (probably rightly 
 so). On the other hand, if I just randomly pick, some of the 
 good stuff will inevitably get passed over. I'm not sure how to 
 handle this fairly. Thoughts?


 From my perspective, most PRs are probably not all that 
interesting. If they are, they'll get documented in the 
changelog.  If there's a big hurly-burly about it on the NG, then 
maybe it's worth more coverage under a "Notable Pulls" heading, 
but it might not be so important on the whole.  After all, it 
won't affect most people until it makes it into a release anyway.


 Last is Miscellania. for Adopt a Bug Report and Adopt a Bounty, 
 I'll choose a random bug report/bounty that people can tackle 
 (or not). The whole point is to try to mitigate the fact that a 
 lot of bug reports and/or bounties can go a long time without 
 any action, and get buried under new stuff coming in. I also 
 considered Adopt a Pull Request, to let people know about pull 
 requests sitting around without getting a review. I also 
 included Music for Hackers as a sort of fun little 
 afterthought. Thoughts?


All sounds fine by me, if you want to include it.

Newsletters are a common thing for distros to do...
...and then stop doing because of a lack of manpower.  Andrei's 
right to call it a marathon.

Thinking back, one common thing is to point major news coverage, 
so a "D in the Press" might not be a bad idea when there's 
something to put there.  Developer interviews come up 
semi-regularly (and are pretty light on their editorial needs, 
usually), so it might be worth trying.  I recall seeing some job 
posting sections in the past, too.

I'll second the request for Bugzilla stats; they're a frequent 
feature and it can help remind people to do filing, triage, and 
the like.  I'm told this is what we use to aggregate those for 
GMN; maybe you can make it work for your case? 
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/gwn/

It doesn't seem common for language communities to have an 
"official" newsletter (that I've seen), but here's a few samples 
of how they've been formatted/managed in the past at the distro 
level; they may be helpful inspiration:
https://blogs.gentoo.org/news/2014/01/31/gentoo-monthly-newsletter-january-2014/
http://www.gentoo.org/news/en/gwn/20071015-newsletter.xml (old, 
weekly format)
https://www.archlinux.org/static/magazine/2010/ALM-2010-Jan.html
https://www.archlinux.org/static/magazine/2004/newsletter-2004-Dec-19.html 
(old format)
https://www.debian.org/News/weekly/current/issue/
https://en.opensuse.org/Archive:Weekly_news_134

Cheers,
Wyatt
Apr 02 2014
parent reply "Meta" <jared771 gmail.com> writes:
On Wednesday, 2 April 2014 at 14:31:49 UTC, Wyatt wrote:

 This is a good base.  In general, I would suggest not shying 
 away from subheadings.  It gives you more opportunities to 
 catch the eye and tends to allow readers to see the parts that 
 interest them more easily.  Conversely, making phrases links 
 tends to make reading harder; would it be acceptable to just 
 put the link after?  See below.


The links, especially the Github ones, tend to be quite long, and 
I didn't want to take up too much space with them, especially 
with the "one link per line" format. I think this might be okay 
for the one-line announcements and pull-requests, as I think 
people generally care more about what's at the actual link itself 
(e.g., a pull request on Github or an announcement post in the 
newsgroup) than one line in a list. I'll experiment with one 
descriptive line plus a link just below and see how it looks.



 For articles, I'd also recommend a sentence or three describing 
 what the article actually covers.  To clarify, I'm thinking 
 something like this:





 Atíla Neves talks about how he retooled his serialiser library 
 to eliminate allocations and dramatically improve performance.  
 He explains the underlying idea in detail, then shows 
 benchmarks covering the possible improvements he mentioned.

 * [Atíla's Blog]($url)



 Vladimir Panteleev has written a "highlights reel" post to 
 demonstrate his overhauled graphics library with an emphasis on 
 composition, laziness, and templating.

 * [Vladimir's Blog]($url)


 followed by a couple of the big announcements, which each get 
 a whole paragraph to themselves


 Broken up with subs, this is good.


Yes, I think this is much better. Thanks for the suggestion.



 Suggest bulleted list, maybe below the important NG threads.  
 But what qualifies as a smaller announcement?


That's what I'm trying to figure out. I may just use my own 
judgement to figure out what's important, although I am open to 
suggestions.



 From my perspective, most PRs are probably not all that 
 interesting. If they are, they'll get documented in the 
 changelog.  If there's a big hurly-burly about it on the NG, 
 then maybe it's worth more coverage under a "Notable Pulls" 
 heading, but it might not be so important on the whole.  After 
 all, it won't affect most people until it makes it into a 
 release anyway.


That's true, it'll always be in the changelog. Already, though, 
Dicebot has suggested that the -vgc pull should be featured more 
prominently. I agree, and I am somewhat worried about making a 
"wrong" choice for what to feature.



 Thinking back, one common thing is to point major news 
 coverage, so a "D in the Press" might not be a bad idea when 
 there's something to put there.  Developer interviews come up 
 semi-regularly (and are pretty light on their editorial needs, 
 usually), so it might be worth trying.  I recall seeing some 
 job posting sections in the past, too.


Good idea. However, right now this info is sporadic enough that I 
can just include/not include a section featuring it when it comes 
up, or put it in the announcements.



 I'll second the request for Bugzilla stats; they're a frequent 
 feature and it can help remind people to do filing, triage, and 
 the like.  I'm told this is what we use to aggregate those for 
 GMN; maybe you can make it work for your case? 
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/gwn/


I'll take a look. Also, what is GMN?



 It doesn't seem common for language communities to have an 
 "official" newsletter (that I've seen), but here's a few 
 samples of how they've been formatted/managed in the past at 
 the distro level; they may be helpful inspiration:
 https://blogs.gentoo.org/news/2014/01/31/gentoo-monthly-newsletter-january-2014/
 http://www.gentoo.org/news/en/gwn/20071015-newsletter.xml (old, 
 weekly format)
 https://www.archlinux.org/static/magazine/2010/ALM-2010-Jan.html
 https://www.archlinux.org/static/magazine/2004/newsletter-2004-Dec-19.html 
 (old format)
 https://www.debian.org/News/weekly/current/issue/
 https://en.opensuse.org/Archive:Weekly_news_134


Thanks for the links. The word "newsletter" is probably a 
misnomer, as that makes this sound more professional than it is. 
This is really just an attempt to aggregate the important news 
together in one place, the same as TWiR.
Apr 03 2014
next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Thursday, 3 April 2014 at 16:07:06 UTC, Meta wrote:

 The links, especially the Github ones, tend to be quite long, 
 and I didn't want to take up too much space with them, 
 especially with the "one link per line" format.


To clarify, I'm not against descriptive text serving as a link; 
my concern was only regarding the link formatting causing breaks 
in sentence flow.  I just used markdown-style notation for 
convenience in my example.


 Suggest bulleted list, maybe below the important NG threads.  
 But what qualifies as a smaller announcement?


 That's what I'm trying to figure out. I may just use my own 
 judgement to figure out what's important, although I am open to 
 suggestions.


Point releases for libs/tools/applications might be good.  Meant 
to mention that before, but forgot.


 That's true, it'll always be in the changelog. Already, though, 
 Dicebot has suggested that the -vgc pull should be featured 
 more prominently. I agree, and I am somewhat worried about 
 making a "wrong" choice for what to feature.


A rule of thumb might be to point out things that could 
potentially change someone's workflow, either by adding new tools 
or by changing/tightening the semantics of a feature.


 Also, what is GMN?


Gentoo Weekl^w Monthly Newsletter.


 Thanks for the links. The word "newsletter" is probably a 
 misnomer, as that makes this sound more professional than it 
 is. This is really just an attempt to aggregate the important 
 news together in one place, the same as TWiR.


Huh, I've never thought of it that way.  Silly languages and 
their vagueness.  But that is pretty much what all the 
(successful) distro newsletters are like, so we agree in spirit! 
;)

Cheers,
Wyatt
Apr 03 2014
prev sibling parent =?UTF-8?B?IkTEgXZpcyI=?= <davispuh gmail.com> writes:
On Thursday, 3 April 2014 at 16:07:06 UTC, Meta wrote:

 On Wednesday, 2 April 2014 at 14:31:49 UTC, Wyatt wrote:

 This is a good base.  In general, I would suggest not shying 
 away from subheadings.  It gives you more opportunities to 
 catch the eye and tends to allow readers to see the parts that 
 interest them more easily.  Conversely, making phrases links 
 tends to make reading harder; would it be acceptable to just 
 put the link after?  See below.


 The links, especially the Github ones, tend to be quite long, 
 and I didn't want to take up too much space with them, 
 especially with the "one link per line" format. I think this 
 might be okay for the one-line announcements and pull-requests, 
 as I think people generally care more about what's at the 
 actual link itself (e.g., a pull request on Github or an 
 announcement post in the newsgroup) than one line in a list. 
 I'll experiment with one descriptive line plus a link just 
 below and see how it looks.



 For articles, I'd also recommend a sentence or three 
 describing what the article actually covers.  To clarify, I'm 
 thinking something like this:





 Atíla Neves talks about how he retooled his serialiser library 
 to eliminate allocations and dramatically improve performance.
  He explains the underlying idea in detail, then shows 
 benchmarks covering the possible improvements he mentioned.

 * [Atíla's Blog]($url)



 Vladimir Panteleev has written a "highlights reel" post to 
 demonstrate his overhauled graphics library with an emphasis 
 on composition, laziness, and templating.

 * [Vladimir's Blog]($url)


 followed by a couple of the big announcements, which each get 
 a whole paragraph to themselves


 Broken up with subs, this is good.


 Yes, I think this is much better. Thanks for the suggestion.



 Suggest bulleted list, maybe below the important NG threads.  
 But what qualifies as a smaller announcement?


 That's what I'm trying to figure out. I may just use my own 
 judgement to figure out what's important, although I am open to 
 suggestions.



 From my perspective, most PRs are probably not all that 
 interesting. If they are, they'll get documented in the 
 changelog.  If there's a big hurly-burly about it on the NG, 
 then maybe it's worth more coverage under a "Notable Pulls" 
 heading, but it might not be so important on the whole.  After 
 all, it won't affect most people until it makes it into a 
 release anyway.


 That's true, it'll always be in the changelog. Already, though, 
 Dicebot has suggested that the -vgc pull should be featured 
 more prominently. I agree, and I am somewhat worried about 
 making a "wrong" choice for what to feature.



 Thinking back, one common thing is to point major news 
 coverage, so a "D in the Press" might not be a bad idea when 
 there's something to put there.  Developer interviews come up 
 semi-regularly (and are pretty light on their editorial needs, 
 usually), so it might be worth trying.  I recall seeing some 
 job posting sections in the past, too.


 Good idea. However, right now this info is sporadic enough that 
 I can just include/not include a section featuring it when it 
 comes up, or put it in the announcements.



 I'll second the request for Bugzilla stats; they're a frequent 
 feature and it can help remind people to do filing, triage, 
 and the like.  I'm told this is what we use to aggregate those 
 for GMN; maybe you can make it work for your case? 
 http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo/src/gwn/


 I'll take a look. Also, what is GMN?



 It doesn't seem common for language communities to have an 
 "official" newsletter (that I've seen), but here's a few 
 samples of how they've been formatted/managed in the past at 
 the distro level; they may be helpful inspiration:
 https://blogs.gentoo.org/news/2014/01/31/gentoo-monthly-newsletter-january-2014/
 http://www.gentoo.org/news/en/gwn/20071015-newsletter.xml 
 (old, weekly format)
 https://www.archlinux.org/static/magazine/2010/ALM-2010-Jan.html
 https://www.archlinux.org/static/magazine/2004/newsletter-2004-Dec-19.html 
 (old format)
 https://www.debian.org/News/weekly/current/issue/
 https://en.opensuse.org/Archive:Weekly_news_134


 Thanks for the links. The word "newsletter" is probably a 
 misnomer, as that makes this sound more professional than it 
 is. This is really just an attempt to aggregate the important 
 news together in one place, the same as TWiR.


Here's another example:
KDE Commit-Digest, a weekly overview of the development activity 
in KDE. http://commit-digest.org/

Only there haven't been new issues for a while...
Apr 05 2014
prev sibling next sibling parent reply Joseph Rushton Wakeling <joseph.wakeling webdrake.net> writes:
On 02/04/14 01:25, Meta wrote:

 Thanks to an unexpected free afternoon due to a brutal spring blizzard, and
 large amount of caffeine, I've come up with an initial draft of a D newsletter.
 It's tentatively named "What's New in D", and it's purpose is to aggregate the
 important community news in one place, as well as to give D some well-deserved
 publicity.


Very nice!  It's great that you've stepped up to do this.


 As I said, this is an initial rough draft to show how I envision the basic
 format. The end product, of course, will not be hosted on Google Docs... I've
 been considering using GitHub Pages to host it, but if anyone has a better
 suggestion, please let me know. I think it would be really neat to write these
 newsletters in DDOC, but I know barely anything about DDOC.


Honestly think that you should go with the solution that will make it easiest
to 
write and share the results.  The point of a newsletter like this is to 
communicate!  You could do much worse than a Wordpress blog -- simple, has 
built-in comments and lots of plugins, talks very easily to lots of the rest of 
the internet ...
Apr 02 2014
next sibling parent "Wyatt" <wyatt.epp gmail.com> writes:
On Wednesday, 2 April 2014 at 20:53:53 UTC, Joseph Rushton 
Wakeling wrote:

 You could do much worse than a Wordpress blog -- simple, has 
 built-in comments and lots of plugins, talks very easily to 
 lots of the rest of the internet ...


...and it has all the security of a plastic sieve filled with lit 
thermite!  It's possible for Wordpress to not suck, but it takes 
effort and care; it's not a fire-and-forget sort of affair.  It's 
true you could do much worse, but that's only because the bottom 
of the barrel is truly rock-bottom.

-Wyatt
Apr 03 2014
prev sibling parent "Meta" <jared771 gmail.com> writes:
On Wednesday, 2 April 2014 at 20:53:53 UTC, Joseph Rushton 
Wakeling wrote:

 Honestly think that you should go with the solution that will 
 make it easiest to write and share the results.  The point of a 
 newsletter like this is to communicate!  You could do much 
 worse than a Wordpress blog -- simple, has built-in comments 
 and lots of plugins, talks very easily to lots of the rest of 
 the internet ...


I have used Wordpress before, but I think even that is too 
overkill. I really just need a readily-accessible place to host 
each new issue. I'm heavily leaning toward GitHub Pages with 
Jekyll at this point.
Apr 03 2014
prev sibling next sibling parent reply "Vladimir Panteleev" <vladimir thecybershadow.net> writes:
On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

 You can view the rought draft here.

 https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing


Could you please use canonical links to forum posts?

http://forum.dlang.org/help#canonical

If linking to the first post in a thread, replacing /thread/ with 
/post/ is enough.
Apr 03 2014
parent "Meta" <jared771 gmail.com> writes:
On Thursday, 3 April 2014 at 16:34:28 UTC, Vladimir Panteleev 
wrote:

 On Tuesday, 1 April 2014 at 23:25:07 UTC, Meta wrote:

 You can view the rought draft here.

 https://docs.google.com/document/d/1Elwm-k6Gs9f7Y-FQNmRVt1uycPEtLkHgpR4v2aQjGwc/edit?usp=sharing


 Could you please use canonical links to forum posts?

 http://forum.dlang.org/help#canonical

 If linking to the first post in a thread, replacing /thread/ 
 with /post/ is enough.


Will do.
Apr 03 2014
prev sibling parent Martin Nowak <code dawg.eu> writes:
Thanks, this looks really promising.
Apr 04 2014