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
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 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
prev sibling next sibling parent "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
prev sibling next sibling parent "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
prev sibling 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 "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
prev sibling next sibling 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 "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
prev sibling next sibling parent "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
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 "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
prev sibling next sibling 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 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
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 "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 next 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 "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 next sibling parent "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
prev sibling next 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 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 "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
prev sibling next sibling parent "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: # Articles # ## Improving Performance With Static Polymorphism ## 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) ## Functional image processing in D ## 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.

 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?

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?

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
prev sibling next sibling parent 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
prev sibling 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 next sibling 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 "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:

 # Articles #

 ## Improving Performance With Static Polymorphism ##

 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)

 ## Functional image processing in D ##

 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
prev sibling next 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 "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
prev sibling next sibling 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 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.

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.

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.

potentially change someone's workflow, either by adding new tools or by changing/tightening the semantics of a feature.
 Also, what is GMN?

 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.

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 next sibling 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 Martin Nowak <code dawg.eu> writes:
Thanks, this looks really promising.
Apr 04 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:

 # Articles #

 ## Improving Performance With Static Polymorphism ##

 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)

 ## Functional image processing in D ##

 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