We are working on a WebApp here which should address this: https://phabricator.wikimedia.org/T388248

I think its in the Android and IOS apps @JTannerWMF is the PM.

Another user story from reports

• From an on-wiki or online community perspective, I would like to be able to get a sense of which events have been most productive and least productive against their stated goals in a window of time. One of the challenges that organizers have with communicating their work to the international movement (and one of the challenges), is that the online community selectively sees the inneffective events they have a conflict with, instead of the swarm of effective silent events that are quitely doing good work on the wikis.

@ifried asked for feedback on these questions, I will write some initial user stories:
Where do we expect data on collaborative contributions to live on the wikis in the future (i.e., which pages/which experiences)?

@Sneha I would put the abbreviations in parenthesis personally to distinguish it from the, and code it as an untranslatable string

DerHexer is a long-trusted Steward that wants access to some of the data that is available through Central Notice, he has an existing NDA with the Foundation.

@Aafi you are correct, sorry I was writing it quickly, and had the wrong user group in mind -- fixed

Following up on my previous comment, I am going to say that the emerging consensus is: add both Meta Admins and Translate Admins groups to the allowlist for publishing Central Notice translations.

@nettrom_WMF -- just got back from sabbatical --- this is wonderful and finally gets us a source of truth for some of the data.

In T341414#9112530, @Frostly wrote:

I think that there are four distinct and actionable tasks here:

• Encourage the use of plain wikitext instead of HTML by default in banners
• Make the interface for approving banner translations simpler and more intuitive
• Allow translation administrators to approve banner translations
• Provide banner requesters with temporary, limited translation adminship (similar to limited adminship)

@gonyeahialam I like the recommendations -- one of the things that has always stood out to me is that we should be using more of the Newcomer Growth tools to gather data that influences the offerings for the newcomers.

I actually think that is a good idea @ifried that would allow us to provide a judging architecture in the future. If yes, I would also ask a question about how they plan to evaluate the results

@gonyeahialam Thanks for the great design ideas. One observation: the words added metrics introduces a lot of complexity, because of how different languages hand words and word length-- it might require further investigation if we have metrics like that that are standard in the wikis.

@ifried The only strategy for going back and tagging edits that didn't get a hashtag the first time, is to make another edit so that minimally

On the moderating content question: I think describing it as a "backlog drive or collaboration on a moderation workflow" is going to be better understood by organizers and parts of the community that "moderation". For the most part, the other ones makes sense. Do we need something different for Wikidata/Data like we have with photos? I am wondering if @Rmaung has any opinions on what we would want to see in terms of types!

It would be nice if the tool allowed you to travel to something like https://pageviews.wmcloud.org/massviews/ where you could do further analysis on the list of articles being viewed. One of the opportunities here is to expose more editors to the fact that impact data (i.e. pageviews) is relatively easy to come by if you have a question that you want to ask.

In T371515#10054258, @Ainali wrote:

A thought I had when talking to Alex at Wikimania: It would probably be useful if these lists had Wikidata items, and that the inclusion of the topics were made through the Wikidata property "on focus list for WikiProject (P5008)". It fits really well, as this is a focus list by definition. It would also enable other ways to use the knowledge that this is a prioritized topic.

This would be useful for any kind of work related to extensions and evaluating the relative "presence" of content types on different wikis. For example, I had a question related to WikiProjects, wanting to understand a) how many namespaces had a seperate WikiProject namespace, and b) if we could evaluate that content.

@ifried I want to endorse the idea of sharing the event list afterwards, this would be a consistent way in which folks who have participated in community in some way (or expressed interest) could be reengaged without a significant amount of organizer-centered responsibility (i.e. retention or introduction to a future movement activity should be our shared responsibility, not the individual organizer).

There are handful of types of situations like this:

• In person events where attendees may not be editing alot
• Webinars where both online registration and participation, that may be hard for the organizer to keep track of the participants
• Events that are part of a series of events, where attendees are expecting to join one but not all of the activities.

Sorry didn't respond to the earlier question: yes, I think putting it near notifications is sensible, it starts to create a space in the area where we are going to be doing other kinds of communication eventually.

I would also include a link to where the user can request turning it on -- until it gets turned on in Event Registration -- the tendency of organizers is not to always know how to triage these kinds of problems, so a link to either Community Configuration discussion (eventually) or in the short term a phabricator ticket for requesting to turn on the tools for the language might be helpful.

In T362897#9827993, @ifried wrote:

Here are some of my early responses/ideas, but I would also love feedback from @Astinson, @Udehb-WMF, and @EUwandu-WMF on these questions regarding how we handle the worklists that are shared by organizers in order to generate their invitation lists:

Do we want organizers to be able to edit a worklist?

Yes. I think we can expect that some organizers will create a worklist, submit it to generate an invitation list, and then look at the invitation list and think, "This list is too short. I should add more articles to my worklist and try again" or "This list has lots of people who I would not invite. Maybe I should pick articles on more specific topics and try again." However, I think the most important thing is that they should be able to try again, whether it's using a new, updated worklist or editing an existing one. I think it's preferable to simply edit an existing worklist (rather than creating a new one), since a) we're not storing multiple worklists that are very similar, and b) we're not encouraging the organizer to generate a ton of different invitation lists per event (but, rather, to edit and improve one main invitation list).

So in theory you could do this with Javascript using: https://www.mediawiki.org/wiki/Template_gadgets, but you have this competing use case of things like Diff Calendar-- Transcludable with parameters I think would be a partial solution (and maybe a little quicker to allow) but wouldn't allow as much customization of context. However, a transcludable widget might allow us to do other things (like embed in other pages like the NewComer Homepage). I would love to weigh the different options here.

www.wikifunctions.org, wikisource.org, species.wikimedia.org, meta.wikimedia.org and commons.wikimedia.org alongside Wikidata.

@Miriam yep exactly the Q2 discussions should be part of 1.1.3, and some Q1 awareness building and WikiProject identification are covered in 1.1.2. The idea is that these consultations/outreach processes feed into eachother in a way that keeps us from doing too many parallel outreach moments for different related things (from the perspective of organizers/editors).

As a brief followup note to @Isaac above: I am currently reviewing the data collected by Isaac, and comparing it with the reported use of WikiProjects and other topical collaborations in community reporting areas such as Diff and This Month in GLAM -- to be better understand the topical networks that would most be prepared for having the conversation identified in the "history/society" and other topics like climate/biodiversity/sustianability identifed by Isaac. I currently have a sketched timeframe for targeted data modeling discussions about the rebuild in Q2 of FY24-25.

@Miriam Sounds good! Yeah, we have two layers of work that I think need to happen: first examining the topic areas that we have signal from the Grants space and seeing if we can build for those(which @Rmaung has the most recent data on) and then thinking about how we can gain the most insight from the communities we do have to improve the overall data model to reflect on and offwiki organizing beyond enwiki. I am going to work with Isaac next week to figure out how complex some of the methodologies might be, and propose a timeline or process.

In a 24 hour period: 40 configuration interactions from the organizer? 6-10 registration actions from the editor? It should be just enough to get them to cool down what they are doing, without being too restrictive -- and create enough space for them to make mistakes are being indecisive.

I would consider doing something, like putting rate limits in a short window of time (i.e. x number of interactions in a 24 or 48 hour period). The thing you want to do is prevent a short term accidental misuse that effects others, rather than actually having someone who is having a bunch of tweaks to the tool right?

After discussions with @Isaac and @Pginer-WMF So one feature that I don't think we are paying attention to yet is to "relative importance" of the article in the domains that its related to. We use a lot of shortcuts (such as pageviews, and interrellated links), but there is a lot of curated information on the wikis already about editor evaluation of importance that we could be using.

@M0tty exactly: the Event List and Registration are focused on the participant finding and registering for an event, but the Event Center and the Dashboard are for the organizer to create ways to register participants (Event Center) and track activity (Dashboard) -- for a "contribute" button focused on random user wanting to find an activity: searching through the Dashboard is not very helpful -- especially if most of the events don't have any description or readable information in your own language (remember we are supporting 300 languages, 600+ wikis), whereas the Event List T355666 will be meant to provide a one place, with translatable and searchable interface for finding events with features like sorting by the language you plan to contribute in, finding events for your geography, etc.

@M0tty I recommend strongly against surfacing the dashboard: especially for non-English speakers, and for new-to-the-Wikimedia-movement participants, the interface of the dashboard is overwhelming (we have repeatedly encountered this in user feedback). I think what happened in the last ticket is that it focuses on the Organizer facing tool (Event center) which would not be relevant to most folks clicking on Contribute where you probably want the participant facing tool at: https://phabricator.wikimedia.org/T355666

+1 this is super painful - it should be a floating button. There should be a sort to handle redlinks and redirects as well -- so you can focus on different types of content to remove from the list

This becomes more important as we try to roll out to Wiki Loves Campaigns on Commons as well.

@Iflorez +1 to everything you said -- make sense to me.

@Lectrician1 I think the problem, is that this becomes the _main_ link in focus now on the notification, so encourages a behavior that is mostly useful for power users (i.e. people with way too much on their watchlist/content creation history). I would recommend that it not take most of 2/3s of the visible space on the page, consisder how smooth the design of the other notifications is.

As for starting registration for events: 56 days is super generous. I can't think of a situation where folks are registering more than 30 days out (you have to remember most of the "actions" that organizers want people to do are easy to forget about if you don't do it in a timely manner).

We may want to include "which languages do you plan to contribute in?" in that its both technically easy to do (use the language lists from the projects) and will improve the signals that Irene and the P&E dashboard can create in terms of metrics (one of the problems right now is that most of the tracking tools in the movement require prior knowledge of the language someone plans to contribute in). This is unlikely to be common in small events, but international writing contests this is key for tracking.

A good example of this is that there are emerging communities of practice on both Human Rights and Sustainability topic areas which are impossible to map to the ORES models, and don't make sense for WikiProjects as a 1:1 especially as we get into broader multi-community activities.

@ldelench_wmf topic of interest should come later once we start picking topic domains for events themselves -- we need the topic areas to be configurable in a flexible way -- the ORES taxonomy and the WikiProjects are both highly inaccurate and not useful for newcomers, especially when trying to form multilingual, multicultural cross community activities.

So one thing to think about is that most of the new accounts will be created before an event, potentially immediately before registering (won't be the same workflow).

I believe that the standard to include "male, female, non-binary, and other" with an option not to be able to participate. @JStephenson may have more insight on how its being used now.

@ifried am not worried about the edits not coming from those countries: we know that the organizers are there, and they are running events -- especially in DRC, Uganda and Rwanda -- the challenge is often seeing their contributions -- of organized activity in general -- and then also we know that the organizers have some serious efficacy gaps in editing events in SSA (its hard to identify productive & persistent audiences, retaining those audiences is challenging, and leveling them up to the right skills is also challenging). We are also missing some of the most important campaigns for the region so far, WikiLoves Africa, Wiki Loves Women and WikiGap (at least according to the checklist).

Appears to be driving traffic on English now as well: https://pageviews.toolforge.org/?project=en.wikipedia.org&platform=all-access&agent=user&redirects=0&range=all-time&pages=Cleopatra

@kzimmerman my partner set up her voice search for her new android phone -- I suspect it has all of the vowels that are common in spanish.

Personally, I would just exclude a few of the namespaces or fork them into a seperate percentage (i.e. % used on Project and User pages): Project space (which is 4?) and user space (which is 2?) Neither of them is supposed to be used for "content" in the browsable sense -- for the GLAM tools, its less of a big deal that they track these secondary uses because the high level metric that most of them want to report is pageviews - but in this case, the usage rate is way more important because of the metric is an indicator of organizing success.

So I am on the Beta app, and it stopped doing this in the most recent update.