@MZMcBride, this proposal has gone through a review process as part of #Google-Summer-of-Code-2015 and now we are in full development mode. Let's  help @Tinaj1234 (our GSoC student for this project) focus on the existing plan, which right now welcomes implementable feedback and suggestions for improvement. The result of this work should be a functional extension running in a Labs instance why the end of September (latest). From there we will discuss whether this makes sense for Wikimedia and, if so, what is missing for a deployment.

>>! In T76199#1386184, @MZMcBride wrote:
> Parts of this proposal feel like natural complements to the existing work that's already been done in MassMessage.

Just for the background: in T59935 we decided to detach newsletter types of features from MassMessage. Legoktm has been following this project and I think both extensions will be good neighbors accomplishing complementary but not equivalent objectives.

> Are users really interested in the flexibility of receiving the Military history newsletter via e-mail, but the Signpost via talk page message (which would trigger an e-mail for most users anyway...)? Are per-newsletter delivery preferences something we actually want or need?

We are not planning to per-newsletter delivery preferences, see {T100492} and comment there if you have feedback.
 
> As always, I'm wary of yet another preferences tab, especially sitting next to an existing "Notifications" tab.

There is no new preferences tab, just a new entry for Newsletters in the Notifications tab, as this will be integrated with Echo. If you want to discuss further, see {T101546}.

 
> I'm not yet convinced of the need for a separate MediaWiki extension here. Publishing content is what the core wiki software should be good at already. I don't see the great value in a specialized layer for creating newsletters specifically.

For what is worth, we made a {T100604} and authors of actual newsletters think this project is useful for their needs. This extension doesn't deal with publishing content per se, as this is done through regular wiki pages. What this extension aims to solve are problems that our current software doesn't solve well: possibility to subscribe/unsubscribe easily to newsletters (without relying on watchlists) and possibility to announce new issues of newsletters via email or web notification (without relying on Talk pages). While advanced users of watchlist and talk pages might see little difference / value, we expect this extension to help newsletter authors to get a lot more subscribers (even among new users feeling more comfortable about subscribing to a newsletter than about start editing on a regular basis) and a lot more actual readers not missing their issues as easily as they might miss changes in their watchlists.

I hope this reply is good enough to see the point of this GSoC project. Your attention to detail is welcome in the ongoing tasks or in new tasks that you are encouraged to create.