An example: details about the deployment of New print to pdf feature for mobile web readers were announced in mailing lists, but not in its related project discussion page.

That would be my fault in this case. It's not wired into my brain to start with the talk page. Reflecting on this, doing so now would require me to write a slightly different message. As the message sent to the Village Pumps and mailing lists refers back to the product page on MediaWiki.org. Writing in that style on the referenced page itself seems a little weird.

Perhaps an alternative suggestion is to at least post a list of announcements on the product page? https://www.mediawiki.org/w/index.php?title=Reading/Web/Projects/Mobile_PDFs&diff=2617977&oldid=2617882

In T179659#3756964, @CKoerner_WMF wrote:

That would be my fault in this case. It's not wired into my brain to start with the talk page. Reflecting on this, doing so now would require me to write a slightly different message. As the message sent to the Village Pumps and mailing lists refers back to the product page on MediaWiki.org. Writing in that style on the referenced page itself seems a little weird.

Understandable feeling. It's awkward for sure.

Perhaps an alternative suggestion is to at least post a list of announcements on the product page? https://www.mediawiki.org/w/index.php?title=Reading/Web/Projects/Mobile_PDFs&diff=2617977&oldid=2617882

*nod* Best practice would be:

• Post announcements in various places.
• Post a summary of the announcement on the product page, and link to posts (as you suggest)
• Start a "Hey, wanna talk about this?" topic on the talk page to turn that red link blue

In my experience, I've found that posting the announcement on the talk page and letting it serve as the canonical host tends to stifle conversation. People are more likely to engage in conversation and feedback when the discussion is available piecemeal.

This kind of content would be useful in the simplified/step-by-step TCG companion piece. We'll discuss it in the near future.

A sensible piece of advice coming from @Jdforrester-WMF would be, creating a placeholder thread (I'm gonna use this as an example) and pointing to it from a related Tech News items. In several cases, we use TN to communicate about changes that have already happened, which means that the related conversation will end up either on the page where TN is published, or on the issue page on Meta, or on a task in Phabricator that's already resolved. A "Discuss" link should help centralise this kind of feedback. Curious what @Johan also thinks.

If there's a specific place for discussion or feedback, Tech News will often mention it as "You can discuss this on the [[project talk page]]" or something like that. There's no reason we couldn't do that every time, if there's always something to link to, and probably shorten it if there's something to add to every item.

If the feedback is wanted, it is possible to have an icon to highlight it.

Another example: https://lists.wikimedia.org/pipermail/analytics/2017-December/006083.html

The email announcement is very good imho, but then there is no single page where I can find all that information and links explain in such comprehensive way. Plus, in this case the screenshots would stand out in an announcement, but of course email is not the best media for that.

CCing @Nuria (hi, this is just FYI, we are discussing this topic for a while and your announcement today was a good example) :) Congratulations for the new dashboard!)

Another one: https://lists.wikimedia.org/pipermail/wikimedia-l/2017-December/089330.html

Same pattern: a very good announcement, but only sent to mailing lists. CCing @DannyH , see my comment to Nuria just above. :)

I believe this is the current orientation: have an onwiki main page (linked from i.e. Tech News), and designate (more or less explicitly) its talk as /the/ place for feedback
Recent examples, https://www.mediawiki.org/wiki/In-context_help_and_onboarding , https://www.mediawiki.org/wiki/2017_wikitext_editor_performance_improvements (if there's a need for updates, those will get them, while I'm not so sure that the update would /also/ be sent out in other ways).

If you use MassMessage, it should be simple to add a subscription to an on-wiki portal page or subpage, that can be seen by everyone, not required to subscribe the channel.

There's already an on-wiki category and main page for announcements and weekly newsletters. I made sure it contained the relevant subpages. The only maintenance will be to organise the main page of the index (which is still preliminary, but has not much content to display)

There may exist later the need to create an archive category for news that are no longer relevant or really outdated (but that could remain searchable). A possible model for that is the Technical newsletters (also hosted primarily in Meta-Wiki), and already delivered to other wikis via subscribed portals or dedicated portal subpages.

May be add support for an RSS feed?

Note: we should maximize the translatability of all these information:

• Beware when you create links and make sure you use "Special:MyLanguage/" in all of them (in international wikis) as much as possible (even if the pages are still not translated but could be once they are prepared for translation).
• Make sure you hide the technical syntax for links or complex templates (if these template are translatable, use {{TNT|templatename}} or {{{{TNTN|templatename}}|parameters}}, either inside a "tvar" (if this is is used in the middle of a statement) or place it ouside of the <translate></translate> sections.
• Split long lists of items into separate <translate></translate> translation units, you may/should hide the leading list item marks (*, #, or :) or the surrounding style applied to the whole paragraph (bold or italic). Don't bore translators with these details that can change with later change of the layout, or later expansion of the lists, without changing the existing content.
• Split long paragraphs at sentence boundary (never split in the middle of sentences). This also improves the performance of the translation memory to locate the related terminology or sentences and allows translations be more consistant.
• Avoid creating lists introduced in the middle of a sentence, except an introduction sentence before the list: the correct order may be different. You can rephrase it using introduction sentences with a normal separate verb and subject.
• Don't assume the English punctuation and word-separating whitespaces (not even the final stop or colon): these punctuation must be translatable as well, you if they are terminal you may use one of the helper templates.
• Make category pages also translatable: just a basic top description sentence inside <translate> tags is enough.
• Make sure you append {{translation:}} at end of the category link metadata, so that translations will not mix together in a long English category: categories must remain navigatable for every one, and the per-languages categories should be populated (and navigatable with their top languages bar). It will also allow comparing easily the state of translations or preparation between English and target languages.
• Actual translation work may occur at any time, as the users will discover these pages ans will want to complete them. Even if they are incomplete, they will all feature a top languages bar allowing to compare with the English source and other translators to complete or review the existing translations and fix ambiguities and typos.

With all this, you'll maximize the number of languages that can be used and extended at any time, by people that will need to reference to them. And this remains maintainable with little cost. No community will be excluded by being unable to locate the relevant topics in their own language: it's difficult for them to navigate in the English-only pages, we must assist them and not require them to learn English and understand it perfectly. This is especially important for newsletters, announcement of changes, votes and all decision processes and to make sure that what is mostly decided in English will consider the opinions and needs of other communities.

Preparing a page for translation, after it was first created, is not very complicate, but if you don't know how to do that, ask around with experienced translate admins that will complete the work and will test it by translating in at least one language (don't forget to ask for Bidi-aware translate admins that will fix your layout (beware of CSS using "left" or "right"): notify them so they'll complete and test its translatability or will inspect how it looks and lays out in Arabic or Hebrew (Hebrew is often easier to inspect even if you don't know that language, and you can just provide a few translation units that have 100% matches in the translation memory for small phrases, common headings, or frequent buttons; leave the rest untranslated and reload the generated target page to make sure all fits correctly.

Also prepare the embedded images so that they all contain a translable legend below them! Avoid images containing lot of text, or describe the image more completely in a relevant section beside the image. Translated images do not have any valid naming convention, even if they exist, as theor layout will frequently need to be adjusted. autotranslated SVG images are hard to design and stil ltoo difficult to translate; there's no "magic" way to guess an alternate image name for each relevant language unless you learn to use the {{LangSwitch}} template to get relevant fallbacks. For videos or PDFs, it's simply impossible to have autotranslated content: the audio part requires specific and complicate editing tools, embedded translated captions is simpler but still require technical skills: it's just simpler to add captions outside the media file, in the wiki text content (this also makes the wiki more accessible for death or blind people).

Also avoid making decisions in "live" sessions. The time scheduling of your community is not the same in other regions or for many people that can be online at the scheduled event. IRC-only is a very bad choice, as it stresses everyone to specific hours. IRC is only useful for temproary help, and nothing is kept. If you take an IRC session to decide something in urgence, please publish an archive of the session minutes, and properly index it in relevant categories.

(That's why other social networks are preferable, like Telegram, as they keep an history that remains reasable and allows sessions where people will contribute at different times). No long-term decision should be made on the minute, people should have the time to think about them, within at leat one week, and every past decision (made by few partciipants) may need to be reviewed and relauched later. Nothing is definitive, newcomers should also have a right (notably when these "newcomers" become aware of the decision long after, because some page describing the topic was translated very late, or it was listed in a large tak space speaking about many other unrelated things that they initially were not interested in).

Also email-only talks via mailing lists is not good for many people that are concerned by their privacy and don't want to publish an active mail address to a public archived list that anyone (including malwares or blackhats) can inspect.

Make sure you maintain an index on-wiki (including for archives or very old decisions that were not discussed since long), so that people can locate them by simple searches. The need to rediscuss something can occur at any time, even years after, and with many new users (the users that discussed it may no longer be active or interested on the topic, or have other many active works to do elsewhere).

Tagging open CommRel-Documentation tasks with MoveComms-Support as Community-Relations does not exist anymore per https://phabricator.wikimedia.org/project/profile/3448/ . Feel free to set the task status to declined or invalid if this task is not valid anymore and/or if the team moved from public Phabricator to internal WMF tools to plan or manage its work.

Marking as "declined" as this ticket was created at least two team restructures ago and it's not relevant to our current work. If I'm mistaken, go ahead and reopen.