Extension talk:Newsletter/Archive 1

Hello there,

I created a new newsletter to announce the m:WIKIMOVE podcast. The documentation pages of the podcast are on Meta, as well as the page that I would like to use as "Page title of the issue". Tony already told me that only Mediawiki pages were accepted, I tried anyways to add a page title with "m:", and I got the error message "m:WIKIMOVE/Podcast is an interwiki title, should be local."

So that's my ultimate wish, I hope one day we can have newsletters that link to pages from other Wikimedia wikis :)

In the meantime, as a workaround, I created Wikimove/Podcast that contains a redirect to m:WIKIMOVE/Podcast. However, this is a "soft" redirect, and when a user clicks on the notification link, they arrive on the Mediawiki page and have to click once more to finally arrive on the Meta page. Hence my question: is there a way to do a more "aggressive" redirect, that would bring people directly where I want to bring them, which is m:WIKIMOVE/Podcast?

Thanks in advance!

Hi @01tonythomas, I wanted to talk to you about this during the hackathon but I didn't find time. Do you know if there's any possibility to create a newsletter with the Extension that would link to the newsletter page on Meta or Wikidata instead of Mediawiki?

Thanks a lot!

But what is a newsletter? Is it a chunk of wikitext that gets put on a user's talk page, or an expanding set of wiki pages? Link to an example.

Also "an existing wiki page that will serve as main page". Main page of/for what? Explain and again link to an example.

I'm with you, SPage (WMF). I think a simple wireframe, or a paragraph or two describing what functionality this would produce, would be tremendously helpful. If I can help (e.g., by interviewing somebody and documenting what I learn), I'd be happy to do so. At the Signpost, we are continually looking for ways to automate aspects of our publication and notification processes, so that we can focus more heavily on the actual writing and editing of the newspaper...so I'm very interested in knowing more about what's envisioned here. -Pete F (talk) 20:32, 29 December 2016 (UTC)

OK, I understand it now. I initially thought this was an effort to ease the creation, publication, subscription, and delivery of newsletters. But (mainly through Quiddity's mockup image below) I now understand -- it's merely intended to ease the subscription and delivery aspects. There are already a number of newsletters (now in links in other threads) with existing subscription and delivery methods -- and, as far as I know, the only standard delivery method is talk page notification. The extension would centralize the subscription aspect, so that every user can subscribe to a variety of newsletters through a pane in their "preferences" screen; and it could also add Echo notification and email notification (and possibly email delivery as well) as options. Do I have that right, Qgil-WMF? -Pete Forsyth (talk) 06:04, 4 January 2017 (UTC)

Yes, we need to improve the Extension page (this is a proposed Google Code-in task right now, so we might get that page updated very soon thanks to new volunteers).

What is missing is a good definition of a newsletter. The content of the newsletter (main page and all the issues) are created independently as regular wiki pages, just like The Signpost does today. What this extension offers is the possibility to "register" your newsletter (probably better wording than "create"?) in order to ease

• its promotion through a Special page listing all the newsletters registered
• subscriptions from users, who only can subscribe/unsubscribe with a simple click
• announcements of new issues, simply by pointing to the URL of the new issue
• reception of notifications via web or email, using the Echo framework.

"Register" is a better word, yes! Much clearer to me. I don't know what a Google Code-in task is, or what the implications are, but if it means this is likely to be more fully developed and implemented in the Wikimedia world, that sounds like good news! -Pete Forsyth (talk) 22:39, 4 January 2017 (UTC)

How can I add every user account on the wiki to the subscription-list of a newsletter? Is it even possible?

I just tested this Extension. I like the idea and would love a Newsletter that I can manage completely from within the wiki (Thanks for development so far!).

When publishing a newsletter, subscribers receive an email saying something along the lines of "a new issue has been published, find it [here]; [and a quick summary typed when publishing]". Is it possible to include the actual newsletter in the email subscribers get? Or alternatively: modify the content of the email that is sent out?

I don't want to count on people opening a browser window to see the contents of my newsletter, but rather serve it to them in their email inbox.

Before making a decision about implementing the extension in wikis that have existing newsletters, we should have a clear inventory of the possible impacts (both positive and negative). Here is my attempt to delineate them; please expand, adjust, and/or comment on this table. -Pete Forsyth (talk) 20:25, 9 January 2017 (UTC)

Method	Pro boldface = feature preserved in extension	Con boldface = fault fixed by extension
User talk notification (currently used on enwp etc.)	Immediate notification via Echo. Immediate notification via watchlist. Publishers can customize presentation. For instance, the Signpost, the Bugle, and the Education Newsletter summarize & link specific articles. Actualités just links each edition. After initial notification, subscribers can leave the talk page notification on their page for future reference for an arbitrary length of time. (Roughly equivalent to leaving a magazine on your coffee table until it's time to discard or file it.) Different users, different preferences. Editions with personal value might be kept longer than others. Many non-subscribers, including new users, are exposed to newsletters via user talk pages on their watchlist. (Roughly equivalent to finding a magazine at a friend's house or coffee shop.) Subscriber list is public. (Either "pro" or "con" depending on perspective.)	User talk page may become cluttered if not carefully maintained. Impractical to subscribe without publicly declaring subscription (watchlisting main page is a workaround) Notification via MassMessage is cumbersome for publishers, and requires a user right that may be difficult to obtain. Publication of a newsletter can spam the watchlists of editors who watch the userpages of many other editors. (if they keep bot edits visible) (Either "pro" or "con" depending on perspective; now listed in both columns.)
Echo web notification (implemented in extension)	Immediate notification via Echo. The Echo link points to a central/canonical table of contents, rather than mass-replicating the TOC. (This impacts some, like the Bugle, but not others, like the Signpost, which uses transclusion.) This makes updates/fixes easy. (Do updates ever happen? -PF) Centralized-content, makes discussion easier and perhaps more likely. (Are there newsletters that publish content to user-talk, rather than just links? If so, which, and let's find out why they do it? -PF) Publication is easy; does not require advanced user rights. User talk pages/archives are not "cluttered up" with announcements. Cross-wiki notification is possible.	Non-subscribers are not exposed to contents of newsletters. No facility (yet?) for cross-wiki notification.
Echo email notification (implemented in extension)	Subscriber may maintain their own customized archive For newsletters that publish entire contents of an issue on one wiki page, this will enable easy offline reading Less cluttered formatting (sidebar, top bar absent)	Publishers will have no insight into email-based readership (unless implementing a web beacon, which is not likely to be met with enthusiasm in the Wikimedia community) Formatting may not be identical to web presentation (?) -- complex elements like sortable tables, interactive data-based graphics, image galleries, etc. may render differently No direct access to talk pages and (where applicable) transcluded comment section
Blend of User Talk & Echo	Permits publishers to meet wishes of diverse subscriber base, where some subscribers prefer each method.	Publisher must maintain two separate subscription lists Publisher must do more work than currently, to publish in both ways Wikimedia users will see one page that claims to be "central," but which does not actually list all options; and may not list all newsletters (if some newsletters choose not to participate in new extension) No easy path for subscribers wishing to change subscription method (unless publisher makes complete transition)

Will it be possible for wiki users to do something like "view history" on the list of subscribers, or the list of publishers? To see changes in the raw number of subscribers over time, and also to determine when a specific user started or stopped being a subscriber or a publisher? -Pete Forsyth (talk) 05:26, 13 January 2017 (UTC)

I can't say for sure, but from what I saw it appears that only the publication managers can see the current enrollment, and I didn't see any history features (I don't know if this is helpful, though, you have the same access that I do).

Thanks. I wasn't able to find anything either, but wanted to check. This seems like important historical info to preserve in some way. Any number of people in the future might be interested in tracking it. -Pete Forsyth (talk) 06:59, 13 January 2017 (UTC)

@01tonythomas please correct me if I'm wrong. Even when subscribe/unsubscribe actions are logged, there is no history page to check them at once. As far as I remember, this is the first time we get this request. Could you create a task in Phabricator for it, please?

Right. We do not have log-subscribers-add/remove yet. Created https://phabricator.wikimedia.org/T155273. Do we have agreement on who should've access to these ?

We have logging for adding/removing in publishers though - which you can see for the test-wiki here

I can't see any reason why the information shouldn't be public, and I think the "wiki way" would generally be to default to public logging.

I suppose that in the broader world, subscribers to pornography often want/expect privacy ("your package will arrive in a discreet brown envelope..."), and there is certainly sensitivity in the wiki world around page access logs. But we have always had public subscription lists, and IMO unless there is a strong, compelling reason to move to private lists, we should sustain the status quo.

@Peteforsyth this is an important discussion that deserves its own thread. I think subscriptions to newsletters are similar to watchlists, and they deserve similar expectations of privacy. Let's discuss this feature request and its implications at T155273, please.

3 points added. (NOTE: Used wrong account, should've been –Quiddity (talk))

Thanks @Quiddity (WMF), some of these prompted some questions, which I inserted inline.

• Re: transclusion vs raw content - I think most of the other newsletters do the latter. Some perhaps partially because they're distributed on multiple projects, hence would still have to create local versions of anything that was to be transcluded. I'm not sure why the others all do.
  • E.g. WikiCup, GoodArticles, Women in Red, The Center Line, Books & Bytes, GOCE, Wikidata, Tech/News, GLAM, etc.
  • The only counter example I can find is WikiProject Videogames (plus The Signpost)
• Re: are fixes ever made? - yes, I know of two newsletter deliveries that had a serious error, which led to a few hours of going through hundreds of pages fixing a broken link. I vaguely recall a few more minor errors that were ignored, because the time-cost of fixing the errors wasn't warranted.
• Re: "Publication of a newsletter can spam the watchlists of editors" - I agree that it can be good for 'general awareness about the existence of a newsletter', for the delivery to show up on usertalkpages, by letting other people discover it there. - I was meaning 'spam the watchlists' as in, I see dozens of items in my watchlist every time certain popular newsletters are delivered (because I watchlist a lot of userpages), which can sometimes make me mass-unwatch userpages due to the annoyance. I can't think of a good solution that keeps the former benefit, whilst resolving the latter problem (beyond just hiding bot edits).

(NOTE: Used wrong account, should've been –Quiddity (talk))

Thanks:

• Some of your examples are actually TOCs or summaries, which link to more detailed pages. The ones that distribute content (the first bullet) would need to substantially change their model to work with this extension; I'm curious what the publishers of those newsletters think about the transition. Reflecting your bulleting, I'd categorize them more like this (with some additions).
  • Content on user talk: WikiCup, GoodArticles, Women in Red, GOCE,
  • TOC or summary on user talk: Videogames, Signpost, Bugle, Education Newsletter, Center Line, Books & Bytes, Wikidata, Tech/News, GLAM
• Now that I realize a number of newsletters do distribute content rather than just TOC (amazing I could overlook this! I've read many of those), I'm not surprised. I do wonder why those publications have declined to create a central repository up until now, and would hope that a new tool like this might be a good incentive for them to shift in that direction.
• I don't think we have any disagreement on the final point. I agree that clutter is a nuisance. I wonder, though, what the impact would be if newsletters suddenly lost the only opportunity there is for accidental readership, without anything in place to replace it. I realize this is a volunteer-driven initiative, but even som, I'm feeling a bit disheartened to learn that this hasn't been seriously considered yet. If there's serious consideration now, maybe we can come up with something. Qgil-WMF, do you see the signifigance of the issues I'm bringing up, or do you feel they are minor details or unimportant? -Pete Forsyth (talk) 20:17, 10 January 2017 (UTC)

See https://phabricator.wikimedia.org/T110170#2904129, https://phabricator.wikimedia.org/T110170#2904627, https://phabricator.wikimedia.org/T154228. The current design was mostly settled upon during an idea solicitation phase back in August (?) 2015, and it's only now getting to another inflection point in maturity.

Note that email notifications are implemented already, as part of Echo.

Interesting. I must be missing something -- I do not see that option in the test instance, and I don't see it documented on the main page here or the Help page recently created. Perhaps something to address? -Pete Forsyth (talk) 17:20, 10 January 2017 (UTC)

In http://newsletter-test.wmflabs.org/wiki/Special:Preferences#mw-prefsection-echo, at Newsletters you should see checkboxes for web and email. I have updated the documentation, which was outdated. Sorry for the confusion.

@Peteforsyth you are presenting the problem as if we would have an equal choice between deploying the Newsletter extension with support to Talk pages or without it. This is not accurate. Implementing Talk page support is probably a task of months (in calendar terms) for this team of busy volunteer developers. Therefore, your request in reality means to choose between releasing the Newsletter extension in a few weeks (without Talk page support, which you can get using MassMessage in parallel) or to release the extension in some indeterminate future, after Talk page support has been implemented.

So no, we Newsletter team are not in a good position to make this comparative research, because in reality our only clear choice is to release soon with the feature set we have. On the other hand, you Signpost publishers are in a much better position to make this comparative research: offer to your readers the option to subscribe to notifications via web/email without touching the current system based on MassMessage/Talk pages, and see how subscribers react.

Qgil-WMF, you make about 4 or 5 mistaken assumptions (about my position, about what I know, etc.) in your first paragraph, so I will ignore that one for now, except to say that this brand new (to me) information, that the extension may be released in as little as a few weeks, is most welcome! And would have been helpful to know sooner.

On your second point, I think it would be excellent to poll our readers about their preferences, as a first step in that direction. Maybe it will make sense for us to test the extension on the "bleeding edge," and maybe not -- I'd enjoy the opportunity if things line up.

Ordinarily, my preference is to share a common draft of poll questions and discuss them with people involved. But I'm a bit torn. Your recent messages are absolutely full of misunderstandings of my comments, and what seems like an uncharacteristically hostile comment (about volunteer time). You've declined my suggestions that you reconsider your words inaccurate words. So I'm not sure what to do. If you think a poll would be valuable, and want to review a draft, and are willing to give it better attention than you've given the rest of this discussion, let me know. -Pete Forsyth (talk) 07:07, 11 January 2017 (UTC)

@Peteforsyth, what is inaccurate in my words, how can I avoid having here an argument? I don't understand why you find my comment about volunteer time hostile. This is a project we do for fun. Please let's keep the fun in these discussions.

I am trying to explain the situation of this team, why our priority is to release this extension as soon a possible, why implementing support for Talk pages would be an epic task for us, and why we don't think we should wait to deploy the extension in Wikimedia.

The idea of a poll is interesting. What would be its objective?

"How can I avoid having an argument" -- very easy:

1. Read what I have said (paying close attention, perhaps, to places where I have repeated myself).
2. If you think I have argued for X, do not immediately (and repeatedly!) present an argument against X; instead, DOUBLE-CHECK to see whether or not I have EVER argued for X. If unsure, ask whether I am aiming for X.
3. On the hostility point: Why would you point out the value of volunteers' time, unless you're implying that I do not value volunteers' time? I don't know why you'd make the point to begin with, but if you must make the point, perhaps you could also acknowledge that everybody with a stake in the extension (including newsletter subscribers and newsletter publishers, and also the person you are talking to) are also volunteers whose time should be valued.

In language that will perhaps be more familiar to you:

"When objections are raised, they are discussed with the crew, who may stop the boat to fix the problems or sail back to previous stages."

I have requested that something be discussed with the crew, and I have asked questions about the boat's immediate and longer-term destinations. I have also updated the documentation of the boat's destinations, as my understanding improves.

I have NEVER ONCE said that the boat must be stopped, or that we should turn the boat around. Yet, you repeatedly state as a premise that it's my position, and then you run off on all kinds of irrelevant tangents.

I have, though, suggested that perhaps the boat could communicate better with the world outside the boat about its destination, and the benefits of it getting there. After all, this isn't a mere pleasure cruise, is it? Doesn't the captain hope his voyage will improve things for a collection of people outside the boat?

-Pete Forsyth (talk) 16:29, 12 January 2017 (UTC)

Thank you. I re-read your comments, and indeed I had misread them. I was left with the impression that you were proposing to block the deployment until the future of the support to Talk pages notifications was clear, and perhaps that some research would be needed to support that. All in all I understood that what you were proposing meant a potential sudden block in our deployment plans that could cause another delay of months, when we are so close to bring this extension to a Wikimedia wiki now (mediawiki.org, hopefully in a few weeks). The impression that you were asking for this made me think that perhaps you thought that implementing this feature is simple, or that (just like me) other WMF people were involved in this project and therefore it should be possible to invest a good amount of time if the WMF really wanted.

This is not what you said, so I apologize for this misinterpretation. We have discussed many times in the past, but this is the first time where we are doing it in this context, where my role is so different even if the username is the same. There are a couple of sentences that I read incorrectly, perhaps because I read them jetlagged, while I should be sleeping, in the very middle of the Wikimedia Developer Summit and one of the most intense weeks of my year.

Let's move on? I will keep trying to do my best to have the Newsletter extension deployed in Wikimedia, making newsletter publishers and readers as happy as possible with the resources we have at each moment.

Thank you @Qgil-WMF, I'm very relieved to see this. Your apology is very gladly accepted. It's been a bit stressful for me, it felt like I was being dismissed as a troll, when my whole purpose in coming here has been to help.

Now that you see more clearly what I'm not advocating, maybe we can get back to some discussion -- which of course need not impact an initial release, but which could potentially expose useful information for a later (or fork) release -- about what tweaks in messaging or substance might improve the long-term chances of successful adoption on English Wikipedia, and any other wikis that have similar collections of existing newsletters. To that end, you might be interested in my general comments to Signpost personnel. The questions I raise there are the ones a poll would be designed to inform.

I'm glad to learn that deployment to MediaWiki.org is coming so soon. It will be very helpful to experiment with the software in a richer environment than the test wiki.

On a side note, we have the Newsletter `Main page` field connected to the main page of the newsletter wherever it is, like somewhere say 'mw:SignPost'. As an immediate solution, the talk page of the Main_Page can be the best point of talk-communications here, like `talk:mw:SignPost' I guess.

We've published a poll of Signpost readers, to learn more about their preferences for subscription/notification.

• "From the editor" post introducing the poll (and some discussion on its talk page)
• Background information, and wiki version of poll questions
• Direct link to poll on Google Drive

We plan to publish the results of the poll in the next edition of the Signpost, in early February. I'll post back here as well.

See title.

That's tracked at phab:T175280 and related

Qgil-WMF et al,

As I believe you're aware, we've been running a poll of our readers since January 17. Thus far we have pretty strong response; while we plan to keep the poll open for another few days, I doubt the results will change significantly. Some of the information will be especially useful to us in determining our engagement with the Newsletter extension, so I thought I'd share some early results here.

• 6% of respondents feel that subscription information should be kept private.
• 56% prefer to receive the Signpost, with links to individual stories, on their talk page.
• 39% first learned about the Signpost by seeing it on another user's talk page.

These results suggest to me that we should be cautious about changes, especially ones that either remove existing options or strongly change the dynamics of how people learn about them.

We'll publish a more thorough breakdown in the next edition, but I wanted to give a heads-up about our thinking here in the meantime. -Pete Forsyth (talk) 19:23, 25 January 2017 (UTC)

Thank you, this is useful.

The universe of this poll are existing Signpost readers, presumably many of them subscribers through MassMessage, and this introduces a bias that needs to be acknowledged.

• About privacy, the big majority doesn't have a strong opinion, which sounds fair enough when probably many of them have posted their username in a MassMessage page already. 19% says it should be kept public. Does the poll offer any hint about their reasons? My (totally subjective) suspicion is that the same question would obtain a very different answer when asked to people not subscribed to the Signpost, to casual editors not familiar with MassMessage, to Wikipedia readers who have never subscribed to any of our newsletters. In other words, to people who have subscribed to many publications in the Internet, and never saw their subscriptions made public. The Newsletter extension wants to become a tool to get readers a bit more involved in Wikimedia life, easily. I personally fear that public subscriptions will confuse this target audience and drive many away.
• About support to Talk pages, again, it is not surprising that those who are already receiving the Signpost through that method are OK with it. I still wonder how heavy would be the use case of talk pages compared to web/email when looking at newsletter in general and the subscribers they don't have yet. Support to talk pages would be nice to have, the question is who will code it and when. Meanwhile, since MassMessage will continue to exist, publications really needing that feature can use / keep using MassMessage, alone or in combination with the Newsletter extension.

Good observations, Qgil-WMF

Your statement about bias is puzzling; as you can see above, I presented this to you as "a poll of [the Signpost's] readers." I made no claims about Wikimedians more generally; if somebody (not me) were to do so, then yes, that would introduce bias.

But hopefully, I have persuaded you that digging into the wishes of Wikimedians broadly construed is a worthwhile pursuit. I continue to hope you will undertake an effort to vet your personal opinions, whether through broader surveys or another scientific approach, before seeking broad adoption of the extension.

Some further breakdowns, which may speak to your points:

• Of the sample used for my previous statistics, 67% self-identify as Signpost subscribers. The meaning of that may not be 100% consistent, as we did not specify; but I expect that means that 67% receive the Signpost on their user talk pages via MassMessage.

Considering only the self-identified non-subscribers:

• 3.7% say the list should not be public; 19% say it should stay public; 78% don't care.
• 52% prefer single Echo web notification; 35% prefer user talk page notification; 13% prefer a single link via email.

The non-subscriber cut is of course getting down to a pretty small sample size (30 responses), so caveat emptor. -Pete Forsyth (talk) 01:08, 27 January 2017 (UTC)

I'm not saying your poll is biased, it is a fair poll of Signpost readers indeed. I was trying to say that Signpost readers are probably not a representative sample of the different audiences the Newsletter extension aims to satisfy.

About vetting my personal opinions... As volunteer contributor, my personal priorities are to deploy this extension in Wikimedia (starting with MediaWiki.org) and to prioritize improvements taking as main indicators feedback from actual/potential users (like yours, which I appreciate) and adoption data. Prioritize is all I can do, as I am not a software developer, I cannot code or mentor others to code. The actual implementation of new features depends on volunteer developers showing up, and many times they work on the features interesting to them, which may or may not coincide with project priorities or user research.

If The Signpost or someone else find developers willing to work in the features they are missing, they are welcome to join this project.

We seem to be talking in circles again. I have not been strongly urging you to develop features, I've been strongly urging you to gather information about whether the communities you intend to serve actually want the things you think they want.

I want to add -- thanks for the expression of appreciation for my feedback. But I think the more important stakeholder group is newsletter readers (and potential readers). We publishers can work any hiccups in the publication process into our workflows; but at the end of the day, our work is intended to reach an audience, and the engagement and satisfaction level of that audience is paramount.

And, there's no timetable on my requests, besides hoping that you will undertake them well in advance of proposing broad adoption. It's my understanding that the features for the current version are pretty well established, and that you intend to deploy it on MediaWiki.org. I have no quarrel with any of that. But anything that would change the nature of subscription/notification on production wikis should be accompanied by strong buy-in, which I believe will only result from design adjustments informed by actual end-user preferences, and a sound basis for predicting their behavior (i.e., will potential subscribers actually find the publications, and actually subscribe).

We published the results of the poll, and our analysis, here: W:en:Wikipedia:Wikipedia Signpost/2017-02-27/From the editors

Qgil-WMF, I'm pleased to see progress in the extension and the documentation. One issue stands out to me, and I'm curious how you're planning to approach it. Since 2006, the Signpost and the Bugle (the two longest-standing newsletters I'm aware of) have been using user talk pages to notify users. For many years, both have used a fairly standard format for doing so; see examples below. (For the Bugle, I have reproduced the wikitext of an announcement; for the Signpost, it's a screenshot, since the code is much more complex and does not work well across wikis.)

Will the extension, by the time it is released, permit subscribers to receive the same kind of notifications, or will it require publications to adjust the format of their delivery methods in order to participate?

If it's the latter, I would suggest making that very clear, and approaching those of us working on those newsletters as far in advance as possible, to increase the likelihood that we're able to move over to a new system with shared enthusiasm. If it's not fully understood ahead of time, I'd expect a number of stakeholders would be surprised, and might resist a change. -Pete Forsyth (talk) 22:31, 7 January 2017 (UTC)

The Bugle: Issue LVI, October 2010

Your Military history Newsletter Project News: Editors for the newsletter, GAN backlog reduction drive Articles: The month's featured and A-class Milhist content Members: Contest results, A-class medal recipients Editorial: EyeSerene sums up our "Five years of military history"

To stop receiving this newsletter, please list yourself in the appropriate section here. To assist with preparing the newsletter, please visit the newsroom. BrownBot (talk) 22:25, 21 November 2010 (UTC)

The Newsletter extension does not post content on subscribers' Talk pages, and we don't have plans to implement that feature. Instead, it sends notifications via web or email, according to users' Preferences.

Current publishers may choose to use the Newsletter extension and leave the delivery to Talk pages behind, may stick to MassMessage (or whatever method are using now) and not use the Newsletter extension, or use both. The arrival of the Newsletter extension doesn't eliminate any existing methods, and nobody will be forced to "migrate".

We reached out to several publishers at the beginning of the project, back in Spring-Summer 2015, in order to share plans and discuss requirements with them. Both The Signpost and The Bugle were contacted -- see phab:T100604. While we obviosly want this extension to be adopted in Wikimedia, we actually are in no rush to create excitement, push people to migrate... On the contrary, this is a new extension and we'd rather let people time to see how it works and whether it is useful for them.

I have no doubt that the extension will be popular for new newsletters and use cases, because people understand the usefulness of subscribing/unsubscribing with a single click and receiving web or email notifications. This is how the Internet works out there for the most part.  :) If the new newsletters are successful, then the existing newsletters will pay attention, and their publishers will be able to test them and take their time before making any change in their current setup.

This shows user talk notification as an option, but is apparently not the active spec

OK, thank you for clarifying that point. I had misunderstood; I thought the mockup Quiddity had posted was part of the spec, and I thought when you said "web notifications" that the kind of "web notifications" newsletters have used for years would still be in play (i.e., user talk page notifications).

I did not mean to suggest you hadn't approached newsletter publishers; in fact I learned about this from Resident Mario from the Signpost. But this point is only just now coming into focus (at least, for me). There are various advantages to user talk page notifications; if some newsletter subscribers and/or publishers prefer the existing system over the new one, I think you'll find that the goals of simplifying newsletter subscription has been substantially undermined on wikis with existing newsletters. Multiple subscription lists for each newsletter, and multiple ways to go about subscribing to each newsletter, would be a bit messy.

Sorry to be the bearer of bad news. If you'd like me to game it out, I'll come back to it tomorrow. -Pete Forsyth (talk) 05:35, 9 January 2017 (UTC)

Yes, that is an earlier concept (2014) that Nick suggested. I personally want to test the hypothesis that posts in user talks pages are more a legacy of the past and something that some people are used to rather than an actual need when users can define Echo notifications (web or email).

"I personally want to test the hypothesis" -- if this is truly the case, I'd encourage you to reflect carefully on the relative merit of a personal research experiment vs. the impact it might have. There's a process for running research processes by review for a reason.

In case this comment came across as being harsh, I want to mention...I am personally also very curious about that hypothesis, I think it's a very good question to ask. I just think an experiment should be considered separately from a proposed change. I think a change should be driven by a legitimate/carefully considered belief that it will lead to a better outcome, and that consequences have been thoroughly evaluated. An experiment should be designed in a way that minimizes impact. They might overlap a bit in a case like this, but if they do, IMO an experiment should be designed and run first, and then a change made reflecting the outcomes of the experiment. -Pete Forsyth (talk) 20:49, 10 January 2017 (UTC)

I agree with Qgil-WMF. Talk page notifications are an awkward way of delivering issues, and one that was borne out of necessity. While it does constitute "free advertising" for talk page visitors (especially on the talk pages of formerly active editors who never turned their subscription off...), most users loathe the sprawl that weekly mail creates on their talk page.

Notifications are vastly more elegant, and I think that most active readers to switch to using them once they are made aware of their availability. From there, I think talk page delivery should eventually be discontinued, but that will depend on how well the feature is actually taken up by users, not on my presumptions thereof.

I don't think it's especially important what the three of us think, so I will not immediately dive into the relative merits of the systems. My concern is twofold:

1. What are the practical impacts if a substantial number of subscribers (note, I did not say "most") disagree?
2. What are the actual benefits and drawbacks of each system? This should be thoroughly explored, not just assumed or privately considered, before a big change is made.

On #1, my point is that if a substantial number of subscribers prefer the old method, we will end up with a pretty messy situation -- the newsletter subscription process for longstanding newsletters will become much more complicated, not much simpler, which I believe undermines the original intent. Resident Mario, you say that "most users loathe the sprawl" and "I think that most active readers to switch to using" notifications. I don't know what leads you to those conclusions, but let's take them at face value and assume they're true.

Let's say 60% of users who have a strong preference (because we should probably disregard those who don't care too much one way or the other) switch to the news system more or less immediately. Let's say of the remaining 40%, half of them along with it when after a period of time, we push for them to move over. It's been messy during that period of time, but if we're actually "getting somewhere" that might be a price we're all willing to pay. But what about the remaining 20% of the total? Suppose they actually like the old system better, and suppose their reasons are compelling, and persuasive to other Wikimedians (which is different from saying "valid", that's point #2.) What happens next?

On #2, I'll put together a table of what I consider pros and cons of each. You guys can add, remove, we can discuss. It seems rather late in the process to be doing all that, but better late than never. -Pete Forsyth (talk) 18:23, 9 January 2017 (UTC)

Table added, see Topic:Tit9gtsmop8qd2d8

I don't see what use their reasons being compelling to other Wikimedians would be; it would ultimately be in the hands of the editorial board and the EIC to determine what is to be done. Deprecation and eventual end-of-life of the "old way" of doing things is a standard aspect of how online communities work (though, yes, Wikipedians' resistance to this is uniquely pervasive).

The best cast scenario is that enough active subscribers will vote with their feet and move to Notifications for the Signpost to justify deprecating and eventually removing the old talkpage delivery process. At worst, if the old-timers are just too old and grumpy to do it, the new system will add a small amount of additional work (go to interface > fill out form > submit), whilst generating a lot of additional opportunities by way of systemization.

Certainly, it will be up to publishers to make a determination for each newsletter. With my own EIC hat on, though, I'll say that the most important factor in my decision, by far -- perhaps the only factor -- will be my assessment of the impact on the Signpost's subscribers and potential subscribers. I think if you were to poll every periodical publisher in the world -- for profit, non-profit, professional, volunteer, whatever -- you'd find they'd give a similar answer. So yes, the impact on subscribers who dislike the change -- independent of the logical analysis of their reasons -- is significant.

Do you have a compelling reason to believe that your "best case scenario" is how things will go? Or, alternately, a suggested way to handle it if things go otherwise? Suppose the "best case scenario" plays out with the Signpost and the Bugle, but not with a few smaller newsletters that are important to specific WikiProjects. Now we have a nominally "central" page that purports to offer users subscriptions to "all" newsletters, and yet some newsletters don't appear. What's to be done? Just lean harder on the smaller pubs to comply? What if they resist?

Above all, PLEASE understand, I strongly believe that overall, this is a worthy project. But some adjustments in the plan might avoid significant pain across a number of wikis in the future. If we don't explore the potential consequences dispassionately, we won't be able to identify possible adjustments.

The Newsletter extension is a project run by very busy volunteers. At the end it all goes down to where do these volunteers believe that it is worth focusing their limited time. Implementing support for posts in Talk pages is a complex feature. I can think of at least two complex features that would beat Talk pages support in our backlog:

1. Interwiki support. Imagine the possibility of having all registered newsletters from all Wikimedia projects listed in one place.
2. Notifications to social media services.

If someone else wants to work on support for Talk pages in the Newsletter extension, great. I just don't see the current team working on this any time soon.

I think the decision of using or not the distribution to Talk pages via MassMessages belongs to the publishers. Newsletter and MassMessage extensions can be used together. We provide publishers with a tool to migrate their existing MassMessage subscribers to a registered Newsletter. We are adding these choices without removing any existing option.

Please, Qgil-WMF, consider who you're talking to here. Very busy volunteers, you say? Am I not a very busy volunteer? Are newsletter publishers and subscribers not "very busy volunteers"? Of course it's being built by very busy volunteers. Volunteers who, I believe, want the outcomes of their work to have a good impact. No? What's your point with that comment, exactly? -Pete Forsyth (talk) 20:54, 10 January 2017 (UTC)

For now, MassMessage and this extension can live side-by-side, a talk page delivery mechanism isn't necessary for the first release. A beta should be done, and then some measure of uptake taken, before scope creep is deemed necessary; if in time it becomes apparent that talk page delivery is a necessary feature, it can be added then.

Maybe I should keep repeating this part until somebody believes that I mean it:

"I strongly believe that overall, this is a worthy project."

Until then, keep on bashing your straw man who insists this has to have a specific feature added. Whoever that is, I fully agree that their view doesn't deserve much attention -- since it comes in the absence of the kind of consideration I've been urging.

When you figure out who that straw man is, maybe somebody will let me know. It sure isn't me. -Pete Forsyth (talk) 23:31, 10 January 2017 (UTC)

I think this could be a much more elegant solution than MassMessage. I'm not a huge fan of the way MassMessage adds a new section to my talk page, and I think being able to send out Echo notifications to the users subscribed to a Newsletter, WikiProject, etc, would be far better than the current Talk page system, especially since Flow will eventually render the MassMessage system unusable.

As a manager of a small WikiProject task force, the ability to provide something like monthly updates on the progress of the project would be greatly appreciated. I'm sure the writers of The Signpost and other newsletters would be similarly appreciative of such functionality, not to mention the ability to easily get feedback on new features (such as Flow or VisualEditor) from interested parties.

I also think creating an official system to join/subscribe to things like a Newsletter or WikiProject that doesn't require editing a page and has a singular central hub for managing subscriptions/membership would be absolutely fantastic for the productivity of all users and projects.

The extension is in active use and is feature complete for its use case, but it was never designed to do anything you have in mind. Its only purpose is to make a list of users who want to receive a newsletter; the emails are then delivered by other methods, specifically by mailman on translatewiki.net.

I haven't abandoned the idea, but not being a developer myself there is only so much I can do. I looked for a technical mentor, hoping that we could start a prototype as a Google Summer of Code 2014 project, but I haven't found any (see my last attempt).

Note that this extension here is NOT the extension used in trasnlatewiki.net. It is a copy of the specific code that does that in some other extension (Translate? can't recall). Siebrand and I agreed to spin it off with the hope to see some development in the direction of a complete extension for handling newsletters, but this hasn't happened so far.

I'll keep trying and lobbying whenever I have a chance, but so far this is just a personal goal.

This post was posted by Qgil-WMF, but signed as Qgil.

Quick note: Developing an API that bots can use is part of Flow's ongoing (in-progress) work. The dev of MassMessage is even working on Flow part-time. :) Bots are a definite part of our future.

Nemo_bis, can you point to an example of where it's in use, so I can get a better sense of what it does? -Pete Forsyth (talk) 20:34, 29 December 2016 (UTC)

@Peteforsyth if you are asking about the Newsletter extension today, it can be tested at http://newsletter-test.wmflabs.org/

Very helpful, thank you! A few bits of feedback:

• "Create a newsletter" was a stumbling block to me understanding what's envisioned. I'm trying to think of a better phrase. The problem is, I would understand "create a newsletter" to do something like offering a wizard style interface that creates a page or set of pages, preloaded with suggested formatting based on a template or transclusion...but I think what is intended is more like "adding an existing newsletter to the extension's system." If I wanted to (say) create a newsletter for an existing WikiProject, there's a lot of stuff I'd have to do that isn't included in what this extension is intended to help with.
• In the test instance, when I click "Subscribe," there's a popup notification with some text, but it goes away very quickly. This is frustrating if you want to absorb the information but can't read quickly enough. Any way to have it stay?
• In the popup notification, it tells you that you'll be notified, but it doesn't tell you how. User talk page? Email? Echo notification?
• I wanted to try the "create a newsletter" option. But when I clicked the link, I learned that I had to be autoconfirmed to even get to that screen. Any way to lower the autoconfirmed requirements for this test wiki? (Once I got past that, the "create" and "manage" options seemed quite sensible!)
• It's interesting that subscriptions are no longer publicly viewable. This doesn't strike me as a problem, but it is a substantial change from how it's worked in the past, and should probably be clearly explained on the main page.

-Pete Forsyth (talk) 06:13, 4 January 2017 (UTC)

I have created tasks for the first three points: T154761, T154763, T154770.

@01tonythomas handles the configuration of the test wiki. I guess it makes sense to allow all users to create newsletters, not just autoconfirmed.

I am not sure I understand your comment about "subscriptions are no longer publicly viewable". I guess you mean that it is public in MassMessage but not in Newsletter? These are different products that can (and will) coexist. I think Internet users generally expect subscriptions to be "quite private" (accessible for admins and publishers, not for the rest), which is the behavior that this extension follows.

Oh oh. So we are not limiting the `newsletter-create` right. We had https://phabricator.wikimedia.org/T154534 which would make the default newsletter-create restricted to sysop. Do you want me to kill that patch, or add that feature only to the testing wiki at http://newsletter-test.wmflabs.org/ ?

This is only about the test wiki instance. For the Extension itself we keep going for sysop only by default, following the advice from steward MarcoAurelio.

Right. thought so. I just merged in the patch for making the extension work out exactly that, and removed the limits manually for the test instance.

Once it has been created, it can be *managed* without special rights, yes? I hope so -- many newsletters are created by non-sysops.

@Peteforsyth please check the brand new Help:Extension:Newsletter. It should answer your questions as potential subscriber, publisher, administrator. A Google Code-in student wrote it! Feedback and edits are welcome there.

In the current labs instance, yes. With the standard Newsletter package, only owners, sysops and users with 'newsletter-manage' right would be able to do that.

Alright. So have enabled newsletter-create,manage,delete right to '*' in http://newsletter-test.wmflabs.org/ There would be no more worries testing!

Just an attempt to draft some specs:

For newsletter authors

• Creating a newsletter.
• Drafting and publishing a new edition of the newsletter.
• Send a notification to subscribers when a new edition is ready.
• Check who / how many people is subscribed to the news letter.

For newsletter readers

• A page with newsletters available, with a possibility to subscribe / unsubscribe.
• Possibility to receive the notification of a new edition via email / talk page / Echo.
• Web notifications contain link to the source page.
• Email notifications contain link and full text (optional? plain text and HTML?)

This post was posted by Qgil-WMF, but signed as Qgil.

Would it be a good idea to write the additions as stories?

The only currently implanted narrative is "As a user I can subscribe to newsletters, so that I can indicate i want to receive newsletters." This was implemented as a preference in the email presences section, and the preference will only be visible if a user has a confirmed email address.

I tried to write something in between at Extension:Newsletter. I'm not a big fan of stories in first person but if you or someone wants o take over I won't object to anything as long as the work gets done.  :)

This post was posted by Qgil-WMF, but signed as Qgil.

The anonymous editor makes a good suggestion.

Otherwise, thanks Quim. These stories look good to me.

See phab:M12 for this mockup on phabricator.

A mockup

A mockup of how I understand the "Newsletter reader" part to work.

This is tremendously helpful in understanding what's envisioned. Thanks Quiddity! I had previously thought the intent was to provide a richer set of tools for composing and formatting a newsletter, but now I understand -- this is simply focused on simplifying the subscription process, and adding Echo and email subscription options. Thanks, and sorry I didn't spot this the first time around :) -Pete Forsyth (talk) 05:43, 4 January 2017 (UTC)

We are expecting to post a better description and screenshots to the Extension page (as part of a Google Code-in task proposed). If not, I'll find the time to do it in my volunteering time.  :)