Topic on Extension talk:Newsletter/Archive 1

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)