Topic on Extension talk:Newsletter/Archive 1

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.