Meta:Babel

Subscribe to the This Month in Education newsletter - learn from others and share your stories ==

Dear community members,

Greetings from the EWOC Newsletter team and the education team at Wikimedia Foundation. We are very excited to share that we on tenth years of Education Newsletter (This Month in Education) invite you to join us by subscribing to the newsletter on your talk page or by sharing your activities in the upcoming newsletters. The Wikimedia Education newsletter is a monthly newsletter that collects articles written by community members using Wikimedia projects in education around the world, and it is published by the EWOC Newsletter team in collaboration with the Education team. These stories can bring you new ideas to try, valuable insights about the success and challenges of our community members in running education programs in their context.

If your affiliate/language project is developing its own education initiatives, please remember to take advantage of this newsletter to publish your stories with the wider movement that shares your passion for education. You can submit newsletter articles in your own language or submit bilingual articles for the education newsletter. For the month of January the deadline to submit articles is on the 20th January. We look forward to reading your stories.

Older versions of this newsletter can be found in the complete archive.

More information about the newsletter can be found at Education/Newsletter/About.

For more information, please contact spatnaikwikimedia.org.

About This Month in Education · Subscribe/Unsubscribe · Global message delivery · For the team: ZI Jony ^(Talk), Wednesday 23:23, 23 November 2022 (UTC)Reply[reply]

"Minor" project's Village Pumps are completely bloated with mass messages, leaving no room for project discussion[edit]

A comparison between the bloat of mass messages and actual project discussions.

I have the feeling that this is incrementally worse. Every team wants every message to be delivered to every project's chat. This mass messages creates 0 engagement, and it's causing actual discussions to be buried. Any thoughts? Ignacio Rodríguez (talk) 15:28, 11 August 2022 (UTC)Reply[reply]

@Ignacio Rodríguez projects can direct those things elsewhere if they want. They are almost always delivered to a list, so a project can make a special pump for "annoucements", or redirect things like technical notices to a technical pump (like how these 74 projects have a technical pump: wikidata:Q4582194). — xaosflux ^Talk 15:33, 11 August 2022 (UTC)Reply[reply]

Not every community, specially the smaller ones, has the knowledge or time to make those adjustments. There must be a better way instead of mindlessly flooding every pump with bloat Ignacio Rodríguez (talk) 16:19, 11 August 2022 (UTC)Reply[reply]

I'm sensitive to this concern: in my previous role as a Movement Strategy and Governance (MSG) facilitator, I sent out a fair number of these mass messages to the places listed at Distribution list/Global message delivery. I noticed they did tend to pile up on the venues, and did fear this might discourage local users from creating other threads (or drown out threads) specific to those projects with sheer volume. I'm wondering how you've reached the conclusion that they create zero engagement though. How can you be sure no one is reading, clicking through, engaging here on Meta-Wiki, signing up for the events, voting on the topics, etc.? As a counter-point: most of the messages sent by MSG invite readers with a link to translate the original message into their language ({{int:please-translate}}), and there are a non-zero number of additional translations later submitted as a result. To me, this is at least a minor indicator that engagement is being generated, even if there's not many responses made directly on the village pumps. Xeno (WMF) (talk) 17:38, 11 August 2022 (UTC)Reply[reply]

I'm sorry if I offended you. The 0 part is definitively an exaggeration. What I meant is that the "project village pump" purpose is to discuss issues pertaining the project, and the mass messages doesn't (mostly) contribute to that. Ignacio Rodríguez (talk) 15:31, 13 August 2022 (UTC)Reply[reply]

No offense taken! I'm glad that folks are thinking about this. Xeno (WMF) (talk) 19:24, 13 August 2022 (UTC)Reply[reply]

I have become concerned about this as well (as I have found entire small projects missing from GMD and have been adding them). However I don't have any easy answers to offer. Certain things like elections and major policy changes need to be sent out. Perhaps we need to encourage more selective use of the GMD function, as well as some automated archiving of old messages. (Also see phab:T313672 which I suspect is related). --Rs chen 7754 18:05, 11 August 2022 (UTC)Reply[reply]

I too feel like this is a problem. On Incubator I have created a separate page for such messages years ago, incubator:Incubator:Wikimedia news, distinct from the Community Portal which hosts discussions. I think this works well and I can only encourage every community that prefers to keep things separate to do so in this way. It's not like the global messages are irrelevant, just that local discussions tend to disappear, especially when they are "low volume" due to the community being small. --MF-W 14:36, 1 September 2022 (UTC)Reply[reply]

Comment If anyone is interested: we have decided to move all global message to a subpage within our main pump. s:es:Wikisource:Café/Noticias_Wikimedia. It seems to be a fair compromise. Maybe it can be the default way to treat small projects :) Ignacio Rodríguez (talk) 20:04, 27 September 2022 (UTC)Reply[reply]

Support ban on mass messaging Having a ban communicates that the messaging is inappropriate, and that mass messages should be exceptional and not routine. The effect of mass messages is the death of community discussion. Mass messages have spoiled the public commons and community space for marginal benefits mostly to the funded interests of the Wikimedia Foundation. For any community member to be heard, they have to compete against paid staff and paid projects for attention. The discussion boards were established for and by community, but this is not how they are currently used in 90% of community forums. It makes no sense to have 1000 local conversations of 10 people each to decide what to do when the problem originates at the top. Turning off the tap of mass messaging would prevent the flood. Almost everyone who is sending mass messages is engaged in unethical behavior to the detriment of the Wikimedia Movement. All can be forgiven for ignorance, but more awareness is needed for the problem.

A potential solution: the Wikimedia Foundation funds a project to establish messaging rules. We set a limit on how many messages go out per year, allocate quotas to different groups, then that is the limit on messages. Meta Wiki is not a social media platform, it cannot host messages without limit, and the current system unfairly favors anyone with money to post more messages. Bluerasberry (talk) 14:37, 28 September 2022 (UTC)Reply[reply]

The "MassMessage graveyards" are a serious problem, choking out any possibility of local discussions, which has been even pushing projects to offwiki forums to escape them. I think that each village pump should be checked for what percentage of sections are MassMessages, and for each one where local posts make up the minority of sections, the following actions should be taken:
- The page should be removed from the distribution list.
- An edit should be made to the page, removing or archiving all MassMessages (excluding those with responses). The removal edit would, in the edit summary, link to a page on Meta describing the situation, and explaining how to re-add the page to the distribution lists if desired, and how to set up a separate page on the project specifically for receiving MassMessages.
- Further use of the MassMessage tool on the remaining fora should be restricted to particular cases, subject to review on Meta, and given a distinct "budget" (or at least, an aspirational goal for how low the level should be kept) for the various kinds of messages needed.
--Yair rand (talk) 22:16, 6 October 2022 (UTC)Reply[reply]
- But on the other side, cutting off projects from hearing about important global policy proposals is problematic. --Rs chen 7754 01:03, 7 October 2022 (UTC)Reply[reply]
  Could the global policy changes be limited to once per year? Wakelamp (talk) 14:08, 7 October 2022 (UTC)Reply[reply]
  @Wakelamp, do you really think people will prefer a single 100-page-long announcement to 200 smaller ones scattered throughout the year? At least with the shorter ones, it's easy to glance at it and decide whether you're personally interested. Also, you won't discover that you need to reply to 50 proposals in a single month, and have no information in the other 11 months.
  
  You can read about some prior discussions along these lines in phab:T130602. The specific task is closed, but the subject is still open for discussion. Whatamidoing (WMF) (talk) 21:00, 10 October 2022 (UTC)Reply[reply]
  Thank-you for the link Doh I thought they were talking about WMF created notices.
  
  "you won't discover that you need to reply to 50 proposals in a single month, and have no information in the other 11 months" You should see my full list (when it is done!)
  
  I have been looking at a few smaller wikis; there is little discussion or their pumps (so WMF are proposals are unlikely to be read), few articles are being created (sports, political leaders, local tv shows,entertainers,...) except by autotranslation (old versions of en articles that were auto translated, that have never been manually edited), few active editors,
  
  (And I am here because of my interest in mass messages , but also because of my interest in the affect of autotranslation on connectivity and community) Wakelamp (talk) 16:56, 11 October 2022 (UTC)Reply[reply]
  A good deal of MassMessage postings are from the WMF. See, e.g., VisualEditor/Newsletter/2022/August for the last one that I caused to be inflicted on about a thousand pages. Qgil-WMF and his team have been encouraging the use of very short announcements, and I have been trying out that style. I think it helps reduce the amount of space taken up by announcements, but it doesn't address the problem of local people not using the wikis for communication. Whatamidoing (WMF) (talk) 20:19, 11 October 2022 (UTC)Reply[reply]
  I like the idea of short comms. (Can you send unexpanded mass messages?)
  
  With local people not using wiki for comms, are they communicating but not on on wiki? Non-wiki comms is becoming common on en wiki. I am not sure whether it is because of privacy/revealing of true identity/more features than talk
  
  Your comment " caused to be inflicted on about a thousand pages" made me realize thatyou really really don't like spam :-). Although my friend J , may dislike spam just a smidgin more than you. He became very very annoyed by spam on day ..... it was 1982 and he was receiving one piece a day ..so he did his PhD on using Bayesian filters for spam id, and he has spent his whole career on spam. Wakelamp (talk) 16:09, 12 November 2022 (UTC)Reply[reply]
  Off-wiki communications seem to be driven partly by the difficulty of communicating on wiki (see mw:Talk pages consultation 2019; some of it's technical and some of it's not), plus that's where people already are. If you learn that "anyone can edit" on Facebook, or in a Whatsapp discussion with your friends from school, or on Slack at work, then you're likely to go back to that place to ask your questions. I live on the wikis, so this seems weird to me, but for someone who lives on Facebook, it probably seems like the most natural thing in the world.
  
  By the way, most of the English Wikipedia's early decisions were made off wiki, too. The idea that only on-wiki discussions "counted" took more than five years to take hold, and some of those original off-wiki discussion forums are still active today. Whatamidoing (WMF) (talk) 07:54, 13 November 2022 (UTC)Reply[reply]

Village pumps, or a selected alternate forum, are there for the exact purpose of receiving the communications of the broader Wikimedia. If those forums are getting too long, then how about we look to bot archive the respective forums, so we are simply clean up after ourselves. — billinghurst sDrewth 10:14, 11 October 2022 (UTC)Reply[reply]
@Billinghurst, a bot is nice, but it's pretty significant overhead to maintain. I have wondered whether a sort of fake "auto-archiving" system would work better. Can redirects be combined with parser functions? Imagine that the page is currently titled Project:Village pump now, and I want it to become Project:Village pump 2022, to be followed by Project:Village pump 2023, etc. Could the undated page title be redirected to something like #REDIRECT[[Project:Village pump {{CURRENTYEAR}}]]?

(Imagine if we'd done something like this to w:en:WP:ANI years ago. It wouldn't have accumulated 1.2 million edits, and instead we'd "only" have 75,000 per year – something that various stats tools can realistically process.) Whatamidoing (WMF) (talk) 20:27, 11 October 2022 (UTC)Reply[reply]

The problem isn't the lack of an archive procedure. The problem is that the small amount of actual on-wiki discussion is buried within mass messages. Ignacio Rodríguez (talk) 17:42, 14 October 2022 (UTC)Reply[reply]
@Ignacio Rodríguez: The small number of edits is due to the small number of participants, not the number of posts on a page. Keeping the pages active, the posts relevant, and the pages readable (short enough) is about meeting the balance. We still want small communities to know what is happening and to participate. — billinghurst sDrewth 12:53, 15 October 2022 (UTC)Reply[reply]
You're not thinking with the perspective of a small wiki participant. Many people contribute every couple of weeks and check the village pump rarely. We may have one or two discussion every month, and months can go by without anyone posting anything there. Every time they enter there they only see the weekly tech newsletter intercalated with miscellaneous Wikimedia stuff (half of the time in English and not their native language), and buried within there's the real talk (e.g. my screenshot above). That's not a welcoming environment and it's not encouraging discussion and engagement. Ignacio Rodríguez (talk) 23:13, 15 October 2022 (UTC) PS: my preferred solution is what we did at esWS, to have a separate pump for "interwiki" mass messages. Of course if someone is decent enough to write to us directly they can use our main pump.Reply[reply]
I am participate in a range of wikis small to large, and I don't think that this is a single, simple issue. It appears evident that there are too many messages being poked to VPs and remaining in VPs, so overwhelming local conversation. I do not agree that by default they are the wrong place to be, as soon as you put them somewhere non-evident they become absolutely pointless in being delivered as no one will see them at a local wiki. So a better screening process by WMF of what they distribute, and can they relook at criteria used, allwikis, all langauges, sisterwikis, etc., a means to clean up, clear instruction on how a community can intervene. — billinghurst sDrewth 08:35, 21 October 2022 (UTC)Reply[reply]
I agree that an intermediate solution can be that MassMessages come with a default "auto archive date" that's shorter than the default. And messages that involve dates should auto archive shortly past that date. Ignacio Rodríguez (talk) 14:53, 21 October 2022 (UTC)Reply[reply]
You can't auto-archive if there's no archive bot, which is the case for nearly all of the wikis, except for the very biggest ones. Whatamidoing (WMF) (talk) 19:31, 24 October 2022 (UTC)Reply[reply]
@Whatamidoing (WMF) Given that archiving is a very necessary component of Village Pumps, and not every (minor) community have the technical knowledge to implement an archive bot, the WMF should offer archive bot for every project. this works very well, and it's easy to setup. Ignacio Rodríguez (talk) 20:18, 24 October 2022 (UTC)Reply[reply]
Have you ever looked at the French Wikipedia's main village pump? I suggest clicking the edit button and looking at the code. Basically, they have a separate village pump page for each day. The result is that it is auto-archiving, without needing anyone to set up or maintain a bot.

I think that having a separate page for every day would be overkill on small wikis, but a separate page for each month or year would be very easy. Whatamidoing (WMF) (talk) 05:33, 25 October 2022 (UTC)Reply[reply]

Another thing: MassMessages should include a direct link to the distribution list used to reach the community, so we can setup more accurately where should we organize those messages. Ignacio Rodríguez (talk) 15:20, 17 October 2022 (UTC)Reply[reply]
Definitely agree about the clear reference to understanding about the message, though I think that there is a better means than to the distribution list, it would be better to have an informed landing page that gives full information about the purpose of what is being attempted AND then how to push to another page. — billinghurst sDrewth 08:35, 21 October 2022 (UTC)Reply[reply]
@Ignacio Rodríguez, every section posted by Special:MassMessage has an automatic and mandatory link to the distribution hidden at the end. If you click the [edit] button for the section, you'll see a line at the end that says something like

There might additionally be a visible link to the distribution list (e.g., VisualEditor/Newsletter), but you can always find the distribution list. Whatamidoing (WMF) (talk) 19:31, 24 October 2022 (UTC)Reply[reply]
Overall, it sounds like we have identified two separate problems:
1. The pages get too big, so nobody wants to read them.
2. The pages are full of announcements, so nobody wants to use them for anything else.
The first problem can be solved by bot (archive when the page gets too big) or by using different pages for different years (the page will be empty in January and big in December, but never as big as many are now). If we wanted to take the bot approach, then an update to the Global bot policy would help.

The second problem could be solved by having two different pages for the two different purposes, e.g., Village pump (announcements) and Village pump (discussion). Some wikis already do this.

@Sj, I recall that you were interested in small wikis. Do you have any advice or other options you think worth considering? Whatamidoing (WMF) (talk) 19:40, 24 October 2022 (UTC)Reply[reply]
Hi WhatareUdoing I'd definitely go with a separate announcements page! And a single "announcements summary" section in the general VP that gets a single line per announcement and is archived each ~year (Serving as a sort of "announcements calendar" since people do like to quickly scan past announcements) –SJ talk 03:21, 25 October 2022 (UTC)Reply[reply]
Sj, having a one-line summary would require people to remember to write that extra line, unless the ==Section heading== is used. But I think the rest is feasible. There's just a certain amount of work needed to make it happen (translate the title, update the typical distribution lists, add local links...) Whatamidoing (WMF) (talk) 05:35, 25 October 2022 (UTC)Reply[reply]

Any community having this issue can already just do this today by changing their subscription page...what am I missing here? — xaosflux ^Talk 14:03, 13 November 2022 (UTC)Reply[reply]
@Xaosflux 1. There is no straightforward way to do it. There are several distribution lists, and not every community has the same technical skills, or even discussions (it can be an issue to those communities even if they don't talk about it). 2. It is a problem that can be adressed at the community level, but also at a central level. 3. You are not missing anything. The purpose of this thread was to gather thoughts about this problem. Ignacio Rodríguez (talk) 17:54, 13 November 2022 (UTC)Reply[reply]

Translator signup – what does it actually do?[edit]

I just received this week’s Tech News at my home wiki, and it’s in English, even though I never got any notifications about Tech News needing translation.

Not that I’d be a good person to do Tech News, but I’m wondering if this suggests a bug somewhere since my prefs are set to receive notifications whenever anything needs to be translated and Tech News definitively would have needed translation. Al12si (talk) 22:56, 24 October 2022 (UTC)Reply[reply]

Notifications are only sent if someone goes through Special:NotifyTranslators, which Tech/News probably doesn't do more than about once a year. Tech/News/Next is normally finalized on Friday of each week and delivered on Monday. You can pretty much count on it needing to be done even if you don't get any sort of notification. Whatamidoing (WMF) (talk) 05:16, 25 October 2022 (UTC)Reply[reply]

@Al12si Adding on to what Whatamidoing wrote above... Tech News has historically not used that feature, I believe because it was considered over-reaching for a weekly newsletter. (The Signup/Notify feature sends notifications to over 1,000 editors (via talkpage or email), and I've seen some complaints when it gets used too often).

Instead, Tech News primarily uses the translators-l@ mailing-list to send weekly reminders, and we also try to stick to a very predictable/regular schedule so that anyone can translate between known times - I.e. By late in the day (UTC) on Fridays, it has been frozen for translation, and then it is sent on Mondays late in the day (UTC). The times vary slightly depending on who is responsible for it each week (usually me, in UTC-7/8 Western Canada; but sometimes Johan or Trizek in UTC+1/2). More details are in Tech/News/For contributors#When is the work done? and below. I hope that info helps. Quiddity (WMF) (talk) 18:44, 25 October 2022 (UTC)Reply[reply]

Thank you. I think this suggests a gap in the communication, probably on the signup form. I actually signed up through Tech News, so I was quite surprised I was never notified. Al12si (talk) 18:49, 25 October 2022 (UTC)Reply[reply]

Edit splitted in two in crono[edit]

I have done an edit in Translation of the week/Translation candidates.

After saving I found myself with two changes (Special:Diff/23994362 and Special:Diff/23994360) instead of one, could someone explain to me why this has happened? ZandDev (talk) 03:32, 30 October 2022 (UTC)Reply[reply]

Translatability and searchability of strings[edit]

Two questions:

Is there a way to find, for example, only UI strings? The “All translations” page lists so many items my browser actually thought the site died (and asked if I wanted to kill the tab), and when it’s fully loaded I couldn’t find anything that looked like UI strings. I can’t even fix the localized label for “All translations” (currently localized as “Translate”) because I have no idea where to find it.
Related: suppose I landed on “Common messages” and tried to translate the strings in it. But I can’t, because there’s absolutely no context. And context is everything in translation, so without context hardly any string can be translated. So the backlog grows bigger and bigger, and things get harder and harder to find.

Has this been reported before? If it has, is there some (non-obvious) menu item that will bring us to a sanitized subset of translatable strings so we can start reducing the backlog? Thanks much. — Al12si (talk) 01:05, 31 October 2022 (UTC)Reply[reply]

Hey again @Al12si! For (A) The UI strings are shared between all wikis (including non-Wikimedia wikis) and are translated at a different website (and is not part of SUL (single user login), so a new account is needed). Details about that are at the page Translatewiki.net.

Re: How to find strings, the mw:qqx trick might help. E.g. https://meta.wikimedia.org/wiki/Meta:Babel?uselang=qqx - the strings that it shows, are the names in translatewiki.

For (B), I think you might be asking about the page Meta:Common messages, and if so I'd suggest asking on the talkpage there.

Hope that helps. Quiddity (WMF) (talk) 23:10, 4 November 2022 (UTC)Reply[reply]

Usability of the CAT interface here[edit]

On this wiki, translations are primarily done through some sort of a CAT (computer-aided translation) interface, which currently does some checks (for example, on bracket matching) in such a way that impedes usability. I wonder if this can be remedied.

The main issue here is that when you, for example cannot quickly close some bracket (within an unreasonably short amount of time, especially when a non-Latin language is involved, or when the user is experiencing disability), a warning message will be inserted into the panel, between the current segment and the text field for the commit message, shifting the commit field, the Publish and Skip buttons down. If the translator then resolves the warning (e.g., closes the bracket) then proceeds to write a commit message, they can instead inadvertently push the Publish button instead, without a commit message. In other words, the current UI design actually causes user errors.

I’d like to propose that a blank row be always reserved for status and warnings messages, so that warning messages will never change the position of the Publish or Skip buttons on the screen. Alternatively, the status message should be shown below the buttons, so that the display or removal of the warning message will not shift any important UI elements.

I believe fixing this is important, as this is actually an accessibility issue. — Al12si (talk) 07:31, 1 November 2022 (UTC)Reply[reply]

@Al12si I see a closely-related task at phab:T164306, but that was about changing the timing. I like your suggestion of a reserved space in the UI. I suggest filing a short feature request, or I can help if you'd prefer. :) Quiddity (WMF) (talk) 23:36, 4 November 2022 (UTC)Reply[reply]

@Quiddity (WMF) If you’re interested, I’ve opened phab:T322801. I don’t think it’s going to get us anywhere (if you asked me I’d say our devs are ableist and culturally insensitive, but judging from what I see on FB or LI I’m not surprised) but if you want to chime in... Al12si (talk) 22:07, 12 November 2022 (UTC)Reply[reply]

“Suggestions” in CAT interface: Strange algorithm?[edit]

I’m asking because when translating Tech News, the CAT interface often behaves very strangely, most often not offering any suggestions even when there’re segments in the translation memory that are perfect matches; also, it seems to prefer very old matches over recent corrections. In both cases the translator is forced to find a recent translation, then manually copy the correct translations over from a recent article.

Is this the right place to raise this, or is there a more appropriate forum? Thanks. Al12si (talk) 22:42, 4 November 2022 (UTC)Reply[reply]

@Al12si Re: your last question: Per the box at the top, this page "is primarily for discussion of Meta policies and guidelines" - and - "For notices and discussions related to multilingualism and translation, see Meta:Babylon and its discussion page". So that page's talkpage would be better for most of your questions here.

Re: problems with the translation memory - Ideally, software bugs can be filed directly in Phabricator, the software bug/feature/task tracking tool used for most of our software. If you want to do that, and aren't already familiar with how to write an effective (for the devs!) task, see mw:How to report a bug. -- Alternatively, you could describe it on the talkpage of mw:Extension:Translate. (I tried 2 very brief keyword searches within the extension's workboard, but I couldn't quickly see an existing task about this.) Hope that helps! Quiddity (WMF) (talk) 23:27, 4 November 2022 (UTC)Reply[reply]

The CampaignEvents extension will be enabled on Meta-wiki soon[edit]

SUMMARY: For your awareness, we’re sharing that a new feature is being enabled soon on Meta-wiki, which is associated with a new namespace pair. It will only be available in Meta-wiki at first. Usage is optional, and no workflows are expected to change.

Hello Meta-Wiki community members,

The Campaigns Product Team is planning to enable the CampaignEvents Extension on Meta-wiki soon, with a target release date in late November. This extension features Event Registration as its first tool, with a new namespace pair: Event and Event Talk namespaces. You can visit the project release page for the latest details on the release schedule, and you can visit this link to learn about how this project has been shared with Wikimedia communities.

Event Registration is an optional tool that enables on-wiki event registration. With this tool, event participants can click on a "Register" button to sign up for events. Meanwhile, event organizers can easily enable event registration on their event pages.

In the future, the CampaignEvents extension will be expanded to include an Event Center. The Event Center will be an optional platform for organizing and managing campaign events, along with other event types, on the wikis.

In July 2022, the Campaigns team released an early version of the event registration tool, known as V0. It is available for testing on testwiki, test2wiki, and the beta cluster. You can visit our project page, read the user guide for the tool, check out our live demo and office hour recording on the tool, and read the summary of the V0 release community feedback to learn more.

The team is currently working on building V1 of the event registration tool, which is the version we plan to release to Meta-wiki. For V1, the organizer side will only be made available to a pre-screened list of organizers. This list will be screened and compiled by the Campaigns team. If you would like to be an early test organizer, please reach out to the team (see bottom section on how to contact us). The participant side will be available to any Meta-wiki users with a registered Wikimedia account.

We welcome any feedback, questions, or ideas you may have on our plans. To contact us, you can share your feedback on our project talk page, directly contact any team members, join our subscription list, or join our upcoming community office hours.

Thank you!

Sincerely,

The Campaigns Product Team IFried (WMF) (talk) 14:01, 8 November 2022 (UTC)Reply[reply]

@IFried (WMF) is there a list of open issues on this (primary phab tag maybe)? I posted a question at Talk:Campaigns/Foundation Product Team/Registration already. — xaosflux ^Talk 14:26, 8 November 2022 (UTC)Reply[reply]

Hello @Xaosfluxǃ Yes, the tag for the event registration project in Phabricator is Campaign-Registration. The tag for Event Center work is Campaign-Events The tag for all of our team's projects is Campaign-Tools. To see what the team is currently working on, you can check out our sprint board. Also, I have answered your question on our project talk page and look forward to your response. Thank youǃ IFried (WMF) (talk) 14:51, 8 November 2022 (UTC)Reply[reply]

Creation of EventːSandbox to test CampaignEvents extension[edit]

Helloǃ As previously posted, the Campaigns Product Team is planning to enable the CampaignEvents Extension on Meta-Wiki soon. For this reason, we are proposing that we create a page on Meta-Wiki called EventːSandbox after the release (see Phabricator ticket T323299 for details). This page would allow users to test out the tool, which would be done by creating "test" event pages as subpages within Event:Sandbox. We would add documentation, such as a basic "how to use this sandbox" guide, on the Event:Sandbox main page. So, we would like to knowː What do people think of this proposal? Do they have any major concerns or alternative suggestions? Do they think the EventːSandbox page would be useful to theɱ? Thank you in advanceǃ IFried (WMF) (talk) 18:44, 21 November 2022 (UTC)Reply[reply]