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

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.

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.

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.
>
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

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 ...

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

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.

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.

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.

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.