Talk:Campaigns/Foundation Product Team/Registration/March 2022

The following thread is closed. Visit Project Talk Page for current discussions .

Discussion on Status Updates
← August 2021 | October 2021 | March 2022 | October 2022 | November 2022→

Event and Event Talk Namespaces [subscribe]

Through our analysis, we concluded that we still think it makes the most sense to create an event and event_talk namespace. Hopefully, our rationale below can provide greater clarity on what we envision for the event pages. However, we’re always open to new ideas, so we are really curious to hear what you think. Here’s our thought process

1. Requirement: We need a way to easily identify what is an event page in the wikis. This is because we want event pages to have certain features in the future, such as: a link for the organizer to enable registration, a link for the organizer to add a worklist (e.g., articles to create or improve), and more. You can see an example of how our designer is currently thinking about the process to enable registration on the event page in T304713. In other words, we’re not just interested in grouping the event pages, but also in making event pages "different" (i.e., augmenting them with some features). To give an example, <templatedata> works only in the Template namespace. We aim to do something similar with event pages. These features will be an option (not a requirement) for event organizers, but we think they will be very useful to some organizers (especially new and junior organizers), based on our research and community outreach.
2. The current behavior: It appears that the vast majority of event pages are currently created in the main namespace (especially if they are on Meta-Wiki) or in the project namespace.
3. Why we believe the project namespace isn’t sufficient:
   1. This proposal may sort-of work for Wikipedia, but it’s not very applicable to other projects. For example, many event pages are on Meta-Wiki (for example, see: WikiGap, Wiki for Human Rights, and 1Lib1Ref). This means every event page on Meta-Wiki would start with the word “Meta.” This is confusing and nonsensical for many users, especially wiki newcomers. Also, people may mistakenly assume that “Meta” refers to the large corporation. As you may note, most event pages on Meta-Wiki are currently in the main namespace. If organizers would have wanted to use the project namespace in Meta-Wiki, we would probably see that behavior more often.
   2. We conducted user testing that showed that some people don’t know how to identify an event page on the wikis (since they often look like article pages). If a page simply starts with “Wikipedia” or “Meta,” this does not solve this problem, but rather perpetuates this confusion.
   3. There are already many other types of pages in the project namespace, such as administrative and policy pages. How do we know which pages are event pages? We could potentially have them marked by a category, but this is not a great user experience for new users and there are problems with categories (see below).
4. Why we believe categories aren’t sufficient:
   1. Semantically, categories tend to be for content rather than page types. This is why pages in the Events category on English Wikipedia, for example, cover topics like the Olympics or a Carnival parade (rather than an edit-a-thon).
   2. Categories are added manually, anyone can edit them, and they vary by wiki (rather than being standardized across wikis). This means that they can be easily manipulated, so it would be challenging to use them as an event page standard.
   3. Categories can be difficult to understand for new users. If we rely on them, this could undermine our goal of helping new organizers effectively engage with event participants.
   4. From a technical standpoint, categorization updates can be slow. MediaWiki does them via the job queue, and it may take some time for a category to be populated, especially if the categorization happens via a template (which we would have no way to prevent).
5. Why we believe the event namespace is best:
   1. The proposal to create an “event” and “event_talk” namespace simply fulfills our needs the best. This way, we can easily identify an event page, which we can augment to support organizer needs. We are certainly open to other suggestions for how to do this, but we haven't found a better alternative yet.
   2. It’s an easy user experience for organizers. For someone to create an event page, they simply add “Event:” in the title. We have learned from our research that many organizers, especially those who are newer to the movement, crave greater simplicity in their workflows.
   3. It’s an improved user experience for participants. As previously mentioned, we have learned that it is hard for some people to identify an event page or know that they can easily join an event. One way to improve this is to explicitly include “Event” in the title. View full discussion

Is this work part of a larger event platform? If yes, be explicit and don’t be shy about it.

Yes, we plan to build an event platform. Apologies, for any confusion; we didn’t think that we were being shy about it. We’ve given presentations about our plans at  Wikimania, Wikiconference North America, WikiIndaba, WikiArabia, the CEE Conference, and in community office hours (in English, French, Arabic, and Swahili). You can view some recorded presentations here and here. We have shared our plans on our team page, and we have a notification list (which we invite you to join). We have also updated the project page to make this more clear. Thanks for pointing this out.

Will WMF keep up commitments long enough to realize their potential? This has a risk of being abandoned by the WMF – and then what?

As a team, we deeply believe in our work, and we don’t want to go anywhere. However, one thing we would like to point out is that, even if we had the plug pulled on our team after this project, we still think we would be delivering value. The registration solution and event namespace would provide easier ways for organizers to identify event pages and register participants on-wiki. With all that being said, we don’t expect this to happen. We want to be around for the long-haul and build out robust, long-lasting support.

Will the event namespace create a 2-tiered system in the eyes of the WMF? For example, would event pages, like Wiki Loves Monuments or Wiki Loves Earth, need to be moved to the event namespace?

No, we have no plans to force campaigns to use the event namespace. It will be the choice of campaign organizers. Overall, it sounds like there's some concern from you that, if we build tools that aren't useful or appropriate for campaigns like WLM, organizers of these campaigns will be forced to use them anyway, since WMF may deprioritize or look down on events that don't use the new tools. This is the last thing we want to do. It would be completely foolish to force successful, highly impactful campaigns like WLM to change how they operate. Instead, we want to help organizers who are struggling now and who have explicitly requested improvements to their tools and workflows. Of course, for mature campaigns (like WLM), the organizers may or may not want to use our tools (and that’s their choice). Ultimately, our goal is to help campaign organizers by providing more options—not by taking options away.

Will these tools be for all events, rather than just campaign events?

As a team, we first began analyzing the needs of campaign events. However, when we began talking to movement organizers, we heard that the tools we planned to build would be useful for many other events they manage (such as meetups, office hours, training sessions, educational programs, and more). They didn’t want to see us create something so narrow that tools (for event creation, event registration, communication with participants, etc) would be confined to campaign events only. We completely agreed. For this reason, we believe our tools are useful for many event types.

What if a wiki wants to use your tools, but they don’t want to have the event namespace?

There are two options. First, we can create an allowlist of permitted namespaces (such as the project namespace) for event pages. Second, we can make it so that the CampaignEvents extension is enabled on a wiki but the event namespace is disabled for that wiki. Either solution is technically possible, but it would require extra time and effort (and it’s much less straightforward than the namespace solution). So, we would like to start with the namespace solution first and then, depending on the user feedback we get in the testing phase, we’ll see what further modifications may be necessary for various wiki communities, if any.

Won’t it be confusing if some events are in the event namespace and some are not?

We already have a confusing system. If we at least start narrowing down the format under which our events are displayed (for example, either in the event namespace or project namespace), then we can bring greater clarity.

Are the mockups/design plans something we can just do with templates (rather than the event namespace)?

It may be technically possible, but we think it's semantically wrong. Templates are used to transclude other pages—not to alter the interface. This is similar to using categories, except that we think that templates make even less sense.

Why can’t we make the feature available for a superset of pages, rather than creating a new namespace?

How would this superset of pages be determined? That's the crux of the issue, and it's what we're trying to solve with the namespace.

Can we have event pages in subpages (such as Project:Events/whatever) rather than the event namespace. Then, communities could consider whether they want a new namespace, since this would allow more gradual adoption. Is this a possible alternative?

How can we know that a certain subpage is an event page? Subpages have many applications, many of which have nothing to do with events.

I don’t think the confusion with the project namespace naming for Meta is a very big deal, since pages can be enhanced by nice formatting and visuals.

Having “Meta” in the title may not be a big deal to you, but it may be very confusing to other people. For example, our user testing found that some people struggle to even identify an event page and they confuse the word “Meta” with the tech company that operates Facebook.

According to your logic, are you saying that all page types should have their own namespace (such as policy pages)?

No. Policy pages are not a different type of page. Event pages are a different type of page because they will have additional elements in the interface, like the registration header, the "enable registration" button/popup, and possibly a different content model in the future. None of these apply to policy pages, as far as we know.

Can you provide more details on the category update lag concern?

Here's a response from one of our engineers: This comes mostly from my experience as an editor; it happened to me recently as well. However, I'm not sure if there's a specific help page or something that we can link to. Note that the slow categorization is only a concern if the category is added by a template, and you change the template so that it adds a different category. This is probably not common, and is not a primary argument against using categories. It's perhaps more of an example of how things may go wrong if the identification system (i.e. categories, as opposed to the new namespace) is too flexible and "customizable."

Can events be added manually? Edited and renamed? What does the wikitext of event pages look like?

Yes, event pages can be added manually, edited, and renamed. Anyone can create an event page in the event namespace by simply searching for “Event:[page title]” and creating the page. You can create or edit event pages just like any other wiki pages. You can use the wikitext editor or the VisualEditor. Refer to our prototypes (see our last response) for an example.

Where will the event data be stored?

Data for the event platform will be stored in the X1 database. To learn more about X1, you can visit the MariaDB documentation on Wikitech. The content of the event page itself is stored just like the content of any other wiki page. For the exact definition of our schema, please view this Gerrit link.

How are event pages merged, split, deleted, and moved to other namespaces?

We are still trying to figure out how this should be managed and we want community feedback on this. For this reason, we’ve just posted a status update that asks for feedback on these specific questions. We have also pinged you in the talk page section for this status update. Do you have any suggestions?

Would this be for any MediaWiki installation? Could this be a single global events interface rather than a 1000 projects interface?

We’re not totally sure what you mean here, but in response: The extension we're building is not Wikimedia-specific, so anyone can use it. For Wikimedia projects, we're going to use a single database, so events can be shared across all projects. Of course, we won’t be storing events created on non-Wikimedia wikis.

Would this be primarily a way to generate and visualize structured overview data, which might have API/module calls to generate summary data that would appear on other wiki pages?

This question isn’t super clear. What is "this"? We do have a few API endpoints that users can use to do whatever they want with the event data.

Can you provide links to the prototypes?

Yes! We have shared the prototype links in our most recent status update. Please check it out and share your feedback on the talk page.

Full Thread

FR : (Feedback sur la mise à jour de mars 2022)

@Din-nani1, Bobbyshabangu, Gilbert Ndihokubwayo, Alhassan Mohammed Awal, Owula kpakpo, Eric Luth (WMSE), White Orchid27, Kaffzz, Tochiprecious, Ruby D-Brown, Bachounda, T Cells, Nemo bis, Econterms, Lea Lacroix (WMDE), Esam Idris, Owula kpakpo, Ariel Cetrone (WMDC), Hogü-456, Kunokuno, OtuNwachinemere, Raggachampiongirl, Olaniyan Olushola, and Pablísima:

Hello! The Campaigns team at the Wikimedia Foundation has posted a status update, which includes: 1) our proposal to create new namespaces for 'event' and 'event talk,' and 2) updates on project work related to engineering, design, and our new ambassador hires. We invite you to read the update and share your feedback below. Thank you in advance! --IFried (WMF) (talk) 16:24, 4 March 2022 (UTC)

Do you think it would be useful to you (or other Wikimedians) to create two new namespaces for Event and Event talk? Why or why not?

FR : (Pensez-vous qu'il serait utile pour vous (ou pour d'autres Wikimédiens) de créer deux nouveaux espaces de noms pour événement et discussion sur l'événement? Pourquoi ou pourquoi pas ?)

• I like Wikipages and also if they are used for registration or to inform about events. I prefer a registration to events with a minimum of information from participants used for it. So from my point of view it is enough to offer a public sign in option and additional a E-Mailaddress to what E-Mails can be send to if people do not want to register in the public. There are templates in use for example a calendar who shows events and in the German Wikipedia it is used a lot. So I think that the namespace is not neeeded. From my point of view it is not useful to invest money into such a solution. There are outside of Mediawiki good solution like Pretix. I like forms and I think if it will be easier to create forms this can be helpful and also the authorizations are a interesting thing that is needed for a event platform in the backend and so there is the chance to extend the functions of Mediawiki in that areas. So I support your work but think it is for other things helpful as events. A goal of Wikifunctions is after my understanding to show that programming is possible also with not so much expierence and so there it can be helpful to have a possibilty to create appllications without deeper programming knowledge.--Hogü-456 (talk) 20:15, 4 March 2022 (UTC)

@Hogü-456 Thank you for sharing your feedback, and apologies for the late reply. In summary, I read from your comment that: 1) You like Wikipages for event pages/event registration, 2) You prefer registration systems that require minimal information of participants, and 3) You recommend that we use existing on-wiki solutions or external software solutions for registration. I will respond to all three points. First, regarding when you say you like Wikipages, can you elaborate on what you mean by this? Are you saying that you like the current process of people adding their signature to sign up for events on wiki pages? We discussed this in our team office hour, so it may be redundant to repeat it here (but just so everyone can read the response): The user flow of someone clicking 'edit' and then knowing how to add a wiki signature, and having them understand that a signature signifies registration, and then not having any confirmation email or extra support after registration is both confusing to wiki newcomers and very different from how contemporary, digital event platforms handle registration. We want to make a more user-friendly experience, so that newcomers and junior editors can easily join events and have a positive first impression of the event. As for why we are not using an external tool, we want to build an event platform (not just one tool), which brings more organizing activity onto the wikis. This means that, if we keep on using external solutions, we repeat the same problem of not having reliable event infrastructure on the wikis. Finally, some organizers may want to collect minimal information on participants, but some may want to know more. For example, if an organizer is hoping to encourage more editors from a certain region or with a certain skill set/interest area, or if they want to know more about why people are joining their events or how to support them, this is information that participants could optionally share when they register. This information could help organizers know if they are making the impact that they hope to have or if they are prepared to support participants in the upcoming event. Overall, we don't want to force every event type and every organizer to use our tools, but rather we want to provide tools that can simplify the workflows for many organizers while simultaneously improving the experience for participants. So, with all that being said, we are curious to hear what you meant by Wikipages and would love to hear back from you on your thoughts regarding our vision. Thank you again! IFried (WMF) (talk) 17:18, 8 April 2022 (UTC)

• It's absolutely reasonable to create the two main spaces but please make the registration space hassle free. No much time consuming questions. I wouldn't want to make people lose interest in my event because of the difficulty encountered while registering. It would also make ones events kind of more popular as one can go to the event space to find events to register for.

Also, the event discussion page would be another good place to either share feedback about an event, learn from others on how to host one or even network to get more guide from others. I support it 💯. You all have done great. --Tochiprecious (talk) 20:54, 6 March 2022 (UTC)

Thank you so much for your reply and supportive words, @Tochiprecious! We completely agree that registration should be an easy process for participants, and this is one of the main reasons we are offering a simple 'register' button rather than the current standard of often requiring people register via signature. Also, we agree that an event calendar in the future would help more people learn about and register for events. Finally, your point on the event discussion page is also great. It can be another way for people to connect on the other event. Much appreciated! IFried (WMF) (talk) 17:23, 8 April 2022 (UTC)

You're welcome. Tochiprecious (talk) 08:20, 10 April 2022 (UTC)

• It feels like new namespaces would be overkill unless perhaps if you have specific alternative content designs in mind (i.e. something beyond what the Project namespace offers). It sounds like rather than a new namespace, you're looking for some type of structured data?

A lot of your benefits assume that people will actually use your system for all 'events' while your tool only aims to serve a small subset of events (Those that meet your type of registration). This seems a fundamental clash. This likely means that people will try to either squeeze events that are not a good match to your system into the Events namespace, in order to 'count' in the eyes of WMF and get onto the calendar - or you're getting a warped view of reality. Either way, it would break a lot of the benefits and/or assumptions underpinning this namespace structure. I think a more flexible approach is warranted for this, with categories under a specified category, with templates or with a list that contains a whitelist of all pages that can be used for this events registration tool. Effeietsanders (talk) 02:50, 13 March 2022 (UTC)

• Agreed w/ Effe -- it also seems like it would be more useful to build tools for the larger universe of lightweight events, with extremely simple registration. And build from there, with a shared community of practice and shared language around events, to adding more structured data and layout templates. My rule of thumb is that new namespaces have a high, persistent cost in fragmented discovery, cognitive load, and confusion; most namespaces are rarely used and fail to capture most of the work that takes place on the new namespace's 'topic' in the main namespaces. –SJ talk  04:37, 14 March 2022 (UTC)

  @Effeietsanders and @Sj, thanks for your feedback, and apologies for the late reply. I have 3 follow-up questions: 1) Can you clarify what you mean by "specific alternative content designs?" 2) Would you still be concerned about the creation of an "event" and "event talk" namespaces if we later create a whitelist of other pages types that can be considered event pages (and therefore have access to tools built by the team)?, and 3) How does your opinion on this topic change if we later develop a tool that allows people to easily create event pages in the event namespace (which seems to align with SJ's comment on "tools for the larger universe of lightweight events... shared community of practice and shared language around events")? To clarify, we are not proposing to create the "event" and "event talk" namespaces to force everyone into a narrow box, but rather for a practical reason: so we that can easily identify which pages are event pages. For example, we don't want to create a tool that allows people to add registration to a Wikipedia article or someone's user page. This is why we need to know what are event pages. Of course, we could approach this in an incredibly broad way, but we decided to start small and to reduce scope & complexity. This way, we could work incrementally, release something earlier, and collect community feedback earlier on in the project. As a result, we came up with the solution of creating the two new namespaces. Now, if this is not adequate for community members, we can certainly consider a larger "whitelist" of acceptable page types in the future as well. This is something we have already discussed internally as a team, and we know it may be a possible request from wiki communities. We just need to start with something small, so we can incrementally build over time. Meanwhile, we would also like to launch another project in the future that allows organizers to easily create event pages (in the event namespace) without complex formatting or template work on their part. This would be optional for organizers, but the tool could improve organizer workflows and processes. I am curious to hear your thoughts on the 3 questions we shared, along with anything else. Your feedback is deeply appreciated! IFried (WMF) (talk) 17:48, 8 April 2022 (UTC)

  IFried (WMF) Thanks for the response. 1) Let me bounce back that first question: what would you like to do on these pages content-wise, that you would be technically unable to do in the Project: namespace currently? That would be the alternative content design. The File: namespace on Wikimedia Commons is a good example of such alternative content design, but also the current Talk: features with liquid threads etc. We have used the Project: namespaces for a long time for events, so I'm curious as to what is different now. 2) If you're creating already a whitelist, I'm probably missing why a new namespace would be beneficial. If you're creating a new Event: namespace, you will likely always have a mismatch in terminology, if this set of tools is the reason for creating it. (note that if you use a whitelist instead, communities could still decide that in their specific circumstances a namespace does make sense - I'm mostly having issues with it being a blanked 'solution') 3) Such a tool may be helpful, but I again don't see a clear vision as to why this has to be a different namespace. You could do the same for the Project: namespace? (this already happens in various pipelines, after all) If you do plan to build something that will require certain new features for the namespace (e.g. structured data), then creating a namespace prematurely may actually make it harder, rather than easier to implement? Effeietsanders (talk) 20:27, 8 April 2022 (UTC)

  Hello User:IFried (WMF), I appreciate the reply. 2) yes, I would still be concerned. On further thought, I think new namespaces would be bad / confusing overall. It would hide pages from searches, and would add to an already-fragmented network of event pages. Better would be an Events category, and a standard events template, which could also be retroactively added to existing pages. You could have all of the same tools, designed to work with that category (or to pages within that category that have the expected template). This would allow things like Project:WikiProjectX/EventA and User:X/PhotoWalks/Spring2022 to use those tools. Note that we already have a range of widely used tools that, for instance, let you have a search box for searching all subpages of WikiprojectX, which would not work across namespaces. 3) I don't think you need to make an "allowlist" of acceptable page types, just look at everything in the appropriate category or categories. Starting with a new namespace isn't small; it's one of the few irreversible things you can do in the wikiverse, as these are almost never deleted and create permanent bloat in the namespace table, advanced search UIs, &c. Thanks again for working to make events better. :) Warmly, –SJ talk  22:08, 8 April 2022 (UTC)

  @Sj & @Effeietsanders Hello! Apologies for the slow response, but we (the Campaigns team) wanted to deeply consider your feedback & whether categories or the project namespace was a better fit. Through our analysis, we concluded that we still think it makes the most sense to create an event and event_talk namespace. Hopefully, our rationale below can provide greater clarity on what we envision for the event pages. However, we’re always open to new ideas, so we are really curious to hear what you think. Here’s our thought process

  1. Requirement: We need a way to easily identify what is an event page in the wikis. This is because we want event pages to have certain features in the future, such as: a link for the organizer to enable registration, a link for the organizer to add a worklist (e.g., articles to create or improve), and more. You can see an example of how our designer is currently thinking about the process to enable registration on the event page in T304713. In other words, we’re not just interested in grouping the event pages, but also in making event pages "different" (i.e., augmenting them with some features). To give an example, <templatedata> works only in the Template namespace. We aim to do something similar with event pages. These features will be an option (not a requirement) for event organizers, but we think they will be very useful to some organizers (especially new and junior organizers), based on our research and community outreach.
  2. The current behavior: It appears that the vast majority of event pages are currently created in the main namespace (especially if they are on Meta-Wiki) or in the project namespace.
  3. Why we believe the project namespace isn’t sufficient:
     1. This proposal may sort-of work for Wikipedia, but it’s not very applicable to other projects. For example, many event pages are on Meta-Wiki (for example, see: WikiGap, Wiki for Human Rights, and 1Lib1Ref). This means every event page on Meta-Wiki would start with the word “Meta.” This is confusing and nonsensical for many users, especially wiki newcomers. Also, people may mistakenly assume that “Meta” refers to the large corporation. As you may note, most event pages on Meta-Wiki are currently in the main namespace. If organizers would have wanted to use the project namespace in Meta-Wiki, we would probably see that behavior more often.
     2. We conducted user testing that showed that some people don’t know how to identify an event page on the wikis (since they often look like article pages). If a page simply starts with “Wikipedia” or “Meta,” this does not solve this problem, but rather perpetuates this confusion.
     3. There are already many other types of pages in the project namespace, such as administrative and policy pages. How do we know which pages are event pages? We could potentially have them marked by a category, but this is not a great user experience for new users and there are problems with categories (see below).
  4. Why we believe categories aren’t sufficient:
     1. Semantically, categories tend to be for content rather than page types. This is why pages in the Events category on English Wikipedia, for example, cover topics like the Olympics or a Carnival parade (rather than an edit-a-thon).
     2. Categories are added manually, anyone can edit them, and they vary by wiki (rather than being standardized across wikis). This means that they can be easily manipulated, so it would be challenging to use them as an event page standard.
     3. Categories can be difficult to understand for new users. If we rely on them, this could undermine our goal of helping new organizers effectively engage with event participants.
     4. From a technical standpoint, categorization updates can be slow. MediaWiki does them via the job queue, and it may take some time for a category to be populated, especially if the categorization happens via a template (which we would have no way to prevent).
  5. Why we believe the event namespace is best:
     1. The proposal to create an “event” and “event_talk” namespace simply fulfills our needs the best. This way, we can easily identify an event page, which we can augment to support organizer needs. We are certainly open to other suggestions for how to do this, but we haven't found a better alternative yet.
     2. It’s an easy user experience for organizers. For someone to create an event page, they simply add “Event:” in the title. We have learned from our research that many organizers, especially those who are newer to the movement, crave greater simplicity in their workflows.
     3. It’s an improved user experience for participants. As previously mentioned, we have learned that it is hard for some people to identify an event page or know that they can easily join an event. One way to improve this is to explicitly include “Event” in the title.

  What do you think? Thank you for your feedback so far, and we really appreciate how you have helped us think through our decisions in greater depth. We look forward to your response! IFried (WMF) (talk) 13:54, 22 April 2022 (UTC)

User:IFried (WMF Thank you for considering feedback seriously. I still don't really see the requirement - most of the mockups sounds like something you should be able to do with templates too - but perhaps there are complications I'm not comprehending. But even if it would be necessary, you could maybe make the feature available for a superset of pages, rather than dedicate a new namespace?

I feel you have not really addressed my concern that you're designing your features for a very specific set of events, rather than for 'all' events. This confusion is for me the leading concern, and you risk damaging events that don't fit exactly in your framework. This concern would be even stronger in your prototyping phase, because you're starting with only very limited use cases (and to be honest, it's never sure whether WMF keeps their commitments going long enough to reach full potential).

Building in a dependency on having a new namespace would further limit the adoption of your tools, because it would prohibit communities to just try out the tooling without creating a whole new permanent namespace (like SJ pointed out). I'm not sure if I would recommend my community to try out something like this with such consequences.

This approach to create a new namespace doesn't seem to be very much in line with the incremental improvement principles that you otherwise seem to want to follow. It feels much more intuitive to create an approach that works on subpages of Project:Events/whatever and then consider whether the community wants to turn that into a new namespace. This would allow a much more gradual adoption approach.

As for some of your concerns with using existing namespaces: the name confusion will always be a thing, regardless of what structure you choose. Making pages stand out can be accomplished without a namespace, and is more a matter of layout and making an effort of picking descriptive page titles beyond the namespace. The confusion with the company 'Meta' will equally always exist, because it's still right there in the url. If we follow your logic for why the Project namespace is not correct, we would end up with countless namespaces (such as "Policy:", "Essay:", "Fancruft:" etc) which I'm sure all could make an argument that there are 'other types of pages in the namespace, that the user doesn't know how to identify that content, and that 'meta' is confusing.

As for the category reasoning: of course the 'events' category in Wikipedia would not be appropriate to use. I assume an appropriate category title would be more of the type 'Wikipedia:Events' or whatever nomenclature they use in specific languages to distinguish project pages from content pages. This will be true regardless of what namespace you use. Categories are of course widely used for non-content as well, I'm a bit confused about this argument. However, categories may not be your solution (based on what i read, it seems subpages seem a more natural approach that is also more in line with historic development), but if your solution depends on not being editable, I think we may have to rethink some more things. Namespaces are at least equally hard to understand for new users.

I'm sure that the exact use case you're designing for, may be best served with a new namespace. The same is true for many other use cases. But I am not convinced it's best for the broader set of events, and feel it may do more harm than good in the long run. I fear it will cause a two tiered system between events that fit the WMF definition, and events that don't fit the WMF definition. It will cause people to try to squeeze their events into such a definition (but don't fit it), and will be especially confusing to participants because some activities that may be covered in a language by the equivalent of 'event', may actually live in a different namespace - only increasing the confusion you're trying to solve for. Simpler workflows are great, but because you're limited in who you're able to serve, you may end up making workflows easier for some volunteers, and harder for others. Effeietsanders (talk) 00:20, 23 April 2022 (UTC)

┌─────────────┘
I see IFried (WMF) thanks for the link. Reading more closely it seems you do intend a large change in the end – A full event-organizer platform? :) Don't be shy about that, but lampshade it, noting that if successful this could replace a range of current solutions for individual facets of event organization. That (along with a commitment to seeing the project through) can be a reason to weather the transition. But we have a checkered record of estimating long-term integration and maintenance costs, so anything which asks people to stop their current process and try something Shiny and New, rather than enhancing and simplifying the current process -- or rather than directly replacing and improving on one of the current partial solutions -- may look good for a year and then become abandonware.

Comments in reply to your bullets:

It strikes me as important that events can be added manually and edited / renamed by anyone. What does the alternative look like?

Re: category update lag, I haven't encountered this + don't understand the issue. When are changes time sensitive? The major cat-vs-other distinction is that categories are non-exclusive, so you can be in cat:FOO while also being in any namespace, and can have multiple categories. This is well suited (as you note) to event templates.

Past namespace fun: 4 Gadget namespaces were created + left empty; unclear to a bug triager what the composite status is years later. Despite lack of use, these namespaces appear on all wikis, taunting us.

Other namespace-specific challenges: what does the wikitext of event pages look like? where is the registration data stored, keyed against what? how are pages merged, split, deleted, moved to other namespaces? what about events w/ many pages currently? Would the current wiki pages for, say, commons:Wiki Loves Earth 2022 be replaced by, refactored into, linked to a new Event page?

Other general questions: Is this ideally for any MediaWiki user/installation? Could this be a single global Events wiki/interface rather than 1000 language-project-namespaces? Would this be primarily a way to generate and visualize structured overview data which might have API/module calls to generate summary data that would appear on other wiki pages?

You can absolutely work through these issues, but it doesn't seem necessary to get a prototype out, and I can think of other plausible solutions depending on answers to Effe's + my Q's above. Please please prototype first, ns after. ♡! –SJ talk  22:34, 26 April 2022 (UTC)

@Sj & @Effeietsanders: Hello, and thank you for your responses! Just like last time, we took some time to deeply consider your questions, so there was a bit of a delay in response. We appreciate all of the great questions you bring up. Below, we have tried to record all of the questions you asked (in bold) and to provide responses to these questions. Apologies if we accidentally missed any questions. Please see below:

Is this work part of a larger event platform? If yes, be explicit and don’t be shy about it.

Yes, we plan to build an event platform. Apologies, for any confusion; we didn’t think that we were being shy about it. We’ve given presentations about our plans at  Wikimania, Wikiconference North America, WikiIndaba, WikiArabia, the CEE Conference, and in community office hours (in English, French, Arabic, and Swahili). You can view some recorded presentations here and here. We have shared our plans on our team page, and we have a notification list (which we invite you to join). We have also updated the project page to make this more clear. Thanks for pointing this out.

Will WMF keep up commitments long enough to realize their potential? This has a risk of being abandoned by the WMF – and then what?

As a team, we deeply believe in our work, and we don’t want to go anywhere. However, one thing we would like to point out is that, even if we had the plug pulled on our team after this project, we still think we would be delivering value. The registration solution and event namespace would provide easier ways for organizers to identify event pages and register participants on-wiki. With all that being said, we don’t expect this to happen. We want to be around for the long-haul and build out robust, long-lasting support.

Will the event namespace create a 2-tiered system in the eyes of the WMF? For example, would event pages, like Wiki Loves Monuments or Wiki Loves Earth, need to be moved to the event namespace?

No, we have no plans to force campaigns to use the event namespace. It will be the choice of campaign organizers. Overall, it sounds like there's some concern from you that, if we build tools that aren't useful or appropriate for campaigns like WLM, organizers of these campaigns will be forced to use them anyway, since WMF may deprioritize or look down on events that don't use the new tools. This is the last thing we want to do. It would be completely foolish to force successful, highly impactful campaigns like WLM to change how they operate. Instead, we want to help organizers who are struggling now and who have explicitly requested improvements to their tools and workflows. Of course, for mature campaigns (like WLM), the organizers may or may not want to use our tools (and that’s their choice). Ultimately, our goal is to help campaign organizers by providing more options—not by taking options away.

Will these tools be for all events, rather than just campaign events?

As a team, we first began analyzing the needs of campaign events. However, when we began talking to movement organizers, we heard that the tools we planned to build would be useful for many other events they manage (such as meetups, office hours, training sessions, educational programs, and more). They didn’t want to see us create something so narrow that tools (for event creation, event registration, communication with participants, etc) would be confined to campaign events only. We completely agreed. For this reason, we believe our tools are useful for many event types.

What if a wiki wants to use your tools, but they don’t want to have the event namespace?

There are two options. First, we can create an allowlist of permitted namespaces (such as the project namespace) for event pages. Second, we can make it so that the CampaignEvents extension is enabled on a wiki but the event namespace is disabled for that wiki. Either solution is technically possible, but it would require extra time and effort (and it’s much less straightforward than the namespace solution). So, we would like to start with the namespace solution first and then, depending on the user feedback we get in the testing phase, we’ll see what further modifications may be necessary for various wiki communities, if any.

Won’t it be confusing if some events are in the event namespace and some are not?

We already have a confusing system. If we at least start narrowing down the format under which our events are displayed (for example, either in the event namespace or project namespace), then we can bring greater clarity.

Are the mockups/design plans something we can just do with templates (rather than the event namespace)?

It may be technically possible, but we think it's semantically wrong. Templates are used to transclude other pages—not to alter the interface. This is similar to using categories, except that we think that templates make even less sense.

Why can’t we make the feature available for a superset of pages, rather than creating a new namespace?

How would this superset of pages be determined? That's the crux of the issue, and it's what we're trying to solve with the namespace.

Can we have event pages in subpages (such as Project:Events/whatever) rather than the event namespace. Then, communities could consider whether they want a new namespace, since this would allow more gradual adoption. Is this a possible alternative?

How can we know that a certain subpage is an event page? Subpages have many applications, many of which have nothing to do with events.

I don’t think the confusion with the project namespace naming for Meta is a very big deal, since pages can be enhanced by nice formatting and visuals.

Having “Meta” in the title may not be a big deal to you, but it may be very confusing to other people. For example, our user testing found that some people struggle to even identify an event page and they confuse the word “Meta” with the tech company that operates Facebook.

According to your logic, are you saying that all page types should have their own namespace (such as policy pages)?

No. Policy pages are not a different type of page. Event pages are a different type of page because they will have additional elements in the interface, like the registration header, the "enable registration" button/popup, and possibly a different content model in the future. None of these apply to policy pages, as far as we know.

Can you provide more details on the category update lag concern?

Here's a response from one of our engineers: This comes mostly from my experience as an editor; it happened to me recently as well. However, I'm not sure if there's a specific help page or something that we can link to. Note that the slow categorization is only a concern if the category is added by a template, and you change the template so that it adds a different category. This is probably not common, and is not a primary argument against using categories. It's perhaps more of an example of how things may go wrong if the identification system (i.e. categories, as opposed to the new namespace) is too flexible and "customizable."

Can events be added manually? Edited and renamed? What does the wikitext of event pages look like?

Yes, event pages can be added manually, edited, and renamed. Anyone can create an event page in the event namespace by simply searching for “Event:[page title]” and creating the page. You can create or edit event pages just like any other wiki pages. You can use the wikitext editor or the VisualEditor. Refer to our prototypes (see our last response) for an example.

Where will the event data be stored?

Data for the event platform will be stored in the X1 database. To learn more about X1, you can visit the MariaDB documentation on Wikitech. The content of the event page itself is stored just like the content of any other wiki page. For the exact definition of our schema, please view this Gerrit link.

How are event pages merged, split, deleted, and moved to other namespaces?

We are still trying to figure out how this should be managed and we want community feedback on this. For this reason, we’ve just posted a status update that asks for feedback on these specific questions. We have also pinged you in the talk page section for this status update. Do you have any suggestions?

Would this be for any MediaWiki installation? Could this be a single global events interface rather than a 1000 projects interface?

We’re not totally sure what you mean here, but in response: The extension we're building is not Wikimedia-specific, so anyone can use it. For Wikimedia projects, we're going to use a single database, so events can be shared across all projects. Of course, we won’t be storing events created on non-Wikimedia wikis.

Would this be primarily a way to generate and visualize structured overview data, which might have API/module calls to generate summary data that would appear on other wiki pages?

This question isn’t super clear. What is "this"? We do have a few API endpoints that users can use to do whatever they want with the event data.

Can you provide links to the prototypes?

Yes! We have shared the prototype links in our most recent status update. Please check it out and share your feedback on the talk page.

Thank you! IFried (WMF) (talk) 19:35, 23 May 2022 (UTC)

Ah, thanks for this long update. A few minor comments, + new ones for the May update below:

- Thanks for adding clarity around the goal of creating an Event Center. Everyone who cares about events should be keen to learn about this. It's good to know it will not be WM-specific, worth considering how this could eventually fit into MediaWiki core.

- I doubt many event organizers worry about how the WMF views their event. I believe the earlier comment about a "two-tier" system was simply noting that, if there is a cool Event Center w/ new event tools [like a calendar] people will try to make their initiatives fit the mold to use those tools -- including duplicating existing pages if necessary -- even if the E.C. is designed fairly narrowly for only a subset of events.

- There is quite a range of templates! most by number I think are used for flexible + structured layout + interface elements. (e.g. banners, citations, footnotes, "stop" buttons on bot userpages, custom headers or sidebars for structured data on other pages. :) Which is what I reckon Lodewijk meant.

- "Would this be primarily a way..." --> would the Event Center [EC] primarily be a way to gather data that is presented in infoboxes on non-EC pages? or would EC pages be 'destination pages', intended to be the standard description + landing page for events? Showcasing how this would work with an existing event that has multiple pages about it (only one of which touching on registration) would make this clearer.

Warmly, –SJ talk  00:27, 24 May 2022 (UTC)

What questions or concerns do you have about creating these new namespaces?

FR : (Quelles questions ou préoccupations avez-vous concernant la création de ces nouveaux espaces de noms ?)

Is there anything else you would like to share about the status update or project in general?

FR : (Y a-t-il autre chose que vous aimeriez partager au sujet de la mise à jour du statut ou du projet en général ?)

• As I see these proposals take shape, I have some concerns about privacy. New users especially, may arrive at these forms with the expectation that it will only go to the event organizers. From what I understand, that is not necessarily the case. Because of how this system seems to work (I don't fully understand it - so may be wrong) our usual tools for suppressing information may not match easily. You may want to give some special attention to making it obvious to registrants what information will be public, and who has access to the rest (is there a rest? The actual registration form does not seem to appear yet). This would of course also limit the functionality (e.g. for real life events, real life information is needed sometimes. This means that anything with a real life component probably can't use this tool if the goal is to keep everything on-wiki) but I assume that is something you're accepting already. Effeietsanders (talk) 02:58, 13 March 2022 (UTC)
  • @Effeietsanders: Thanks for sharing this feedback, and we also share your concerns around privacy. For this reason, the first version of the registration solution will collect no personally identifiable information (just the participant's username). There is no registration form, but rather a simple button to click "Register." Once the user clicks on the button, they are automatically registered (if logged in). If they are not logged in, they will be asked to to login/create an account first. Overall, this means that the same information will be shared publicly on the event page (i.e., the list of users registered for the event) as the one that is shared with the organizer. Over time, we do hope to allow organizers to optionally ask additional questions to participants during the registration process, such as their gender, location, wiki editing level, or the reason they are joining the event. This kind of information may only be viewable to other organizers of the event or in aggregate reporting (we don't know the details yet, since we haven't investigated and made a determination). However, this will require more complex decision-making, so we're not rushing this work and we don't plan for it to be in the first release at all. Also, I should add that we want to include privacy policy information (such as a link to the privacy policy) in the user flow when people register. It wasn't included in the basic wireframes that were shared in the early project update, but we're looking into it (so, thanks for bringing it up!). Finally, I have some follow-up questions for you: Can you provide some background/context on what you meant when you said "...our usual tools for suppressing information may not match easily"? Apologies, I don't fully understand. And, given what I just shared about the first version of the feature, what do you recommend or think is best, regarding privacy needs? Thanks in advance! --IFried (WMF) (talk) 17:52, 15 April 2022 (UTC)
• Ma question est de savoir, si tout les participants s'inscrivaient via cet outil d'inscription, leurs user names seront-ils ajouter aussi automatiquement sur le tableau de bord ? sinon, prière d'y penser à ça lors de la prochaine mis à jour.--VALENTIN NVJ (talk) 13:31, 13 March 2022 (UTC)

  @VALENTIN NVJ Merci pour votre question! La réponse est oui. Nous prévoyons d'avoir une intégration avec le tableau de bord, de sorte que si quelqu'un enregistre son nom d'utilisateur est automatiquement ajouté au tableau de bord. Nous prévoyons de publier l'outil d'enregistrement en 3 cycles (version 1, 2 et 3). L'intégration du tableau de bord sera dans la version 2, très probablement. Merci! IFried (WMF) (talk) IFried (WMF) (talk) 18:10, 15 April 2022 (UTC)

• Are you sure this is GDPR compliant? Is it possible to aggregate / analyze (even public) user data without specific consent? --2804:7F0:A084:AB:24B8:B6A4:A8F1:8A52 23:11, 13 March 2022 (UTC)

  Thanks for bringing this up! We are looking into this, and we can get back to you when we have more information. Also, I should note that we are planning to have the participant opt into a privacy policy, terms of use, and licensing agreement (most likely) when they register. This just wasn't included in the earlier version of the wireframe shared on the project page since we hadn't begun fleshing out that side of the project yet. IFried (WMF) (talk) IFried (WMF) (talk) 17:55, 15 April 2022 (UTC)

• Merci beaucoup pour votre travail, personnellement je n'ai pas beaucoup d'expérience dans l'édition ou l'organisation des campagnes même si je sais tenir des événements, et j'apprécie surtout l'idée d'évaluer ce nouveau projet qui va voir le jour d'ici fin 2022 et que nous pourrions soutenir et nous en servir car c'est presque exactement ce que bon nombre d'organisateurs ont voulu aussi pour faciliter les choses, j'espère que l'application demeurera conviviale pour tous, les nouveaux arrivants inclus. Je profite aussi pour demander s'il y aura possibilité de mettre au point un système de notification de suggestion ou d'orientation comme c'est le cas avec Facebook ou autres médias sociaux, pour prévenir ou avertir les participants que d'autres avec qui ils partagent soit la même communauté participent à un des évènements proches, je sais que le respect des informations privées priment mais ce n'est que mon humble avis...--CapitainAfrika (talk) 06:58, 21 March 2022 (UTC)

• Mais pour la création d'un compte je pense que, même si ce n'est qu'un début car nous allons commencer petit avec l'application et grandir après, sur la page d'inscription et de création de compte utilisateur qu'on mette un lien qui permet au nouvel utilisateur potentiel d'entrer en contact avec des créateurs des comptes au cas où il trouvera des difficultés, si ce sera possible pour lui de laisser un message au groupe des créateurs de compte afin qu'un des bénévoles lui vienne en aide après pour faciliter son inscription à l'univers Wiki CapitainAfrika (talk) 07:02, 21 March 2022 (UTC)

  @CapitainAfrika Merci pour votre commentaire! Oui, nous pensons que c'est une bonne idée d'avoir un moyen de contacter les organisateurs, surtout si les gens ont des difficultés à s'inscrire. C'est quelque chose que notre designer envisage maintenant, donc c'est super que vous en parliez. Nous voulons voir comment nous pouvons intégrer cette idée dans la fonctionnalité, mais cela pourrait arriver dans une version ultérieure. Merci encore! IFried (WMF) (talk) IFried (WMF) (talk) 18:13, 15 April 2022 (UTC)

• This tool will indeed be very useful for on-wiki organization. It can help chapters and usergroups measure the impact of their events, but also get closer to the online community. As many people have pointed before, it would keep all information under pseudonyms and make members of minority groups safer on wikis. It is wonderful if this new tool can help new comers register directly onto the wikimedia projects as well. I only have two questions ː the name spaces "projectː" and "wikipediaː" are already being used on many wikipedia versions for a purpose that's close to what these new name spaces would be. Would it be possible to make sure that all these namespaces are complementary and work together without overlapping ? My second question is ː is there a 5 year long programm (or longer) insuring that this new tool will be updated regularly by the Wikimedia Foundation ? This goes with a need for communication and change management regarding the practices of wikimedians. Thank you very much for taking the time to set up this feedback campaign ǃ Best --Adelaide Calais WMFr (talk) 18:00, 12 April 2022 (UTC)

  @Adélaïde Calais WMFr Thank you for your feedback! We are very pleased to read that you think the future registration tool will be helpful to chapters and user groups, as well as ensuring a safer registration experience. In response to your questions: 1) If I understand your question correctly, you are asking how we will plan to handle the fact that many event pages are already in the project namespace. In other words, will event pages in other namespaces (such as the project namespace) still be able to access the tools we build and be a part of the larger vision of the Campaigns team? If this is the question, the short answer is: Yes, we can probably work to make this possible. For the first version of the registration tool, we need to build something very simple and relatively quickly, so we can get feedback from organizers in a test environment. We're planning to have the first testable version ready by this summer, roughly speaking. For this version, the tool will allow users to enable registration on event pages in the event namespace. However, in later versions, we are planning to probably have a larger "whitelist" of namespaces where event pages may occur (such as in the project namespace) and ways for users to specify that pages in those namespaces are event pages. This way, they will still be able to access the features and tools that we build. This will take more work, but it is something we are seriously considering for the future. So, in that case, is that what you mean, and would our plan for a whitelist be suitable to you? and 2) Apologies, I don't fully understand this question. Are you asking if we have long-term plans at WMF to continue supporting and sustaining the team, so that the tools we build have long-term investment. If that is your question, I will say that our team deeply believes in our work and why we are doing it, and we are advocates for it both within WMF and the broader Wikimedia community. We want to be around for a long time, so we can continue to make improvements and to maintain the improvements we have made. Thank you, and we look forward to your response! IFried (WMF) (talk) 21:05, 25 April 2022 (UTC)

Maoni kutoka kundi la Wanawikimedia wa Tanzania

Kuhusu Event Registration System

Nadhani mfumo huu utarahisisha sana waandaaji wa matukio ya Wiki na wageni kujua matukio mbalimbali ambayo wanaweza kuhudhuria ili wajifunze zaidi kuhusu miradi ya WIkipedia.--Rwebogora (talk) 12:10, 30 April 2022 (UTC)

@Rwebogora Shukrani kwa ajili ya maoni haya! Tunafurahi kwamba unafikiri mfumo mpya tunaojenga utakuwa muhimu kwa waandaaji wa hafla na washiriki. IFried (WMF) (talk) 20:08, 3 May 2022 (UTC)

Mfumo ni mzuri na nadhani ni sahihi kuendana na malengo husika. Ila changamoto ninayoiona ni matumizi ya lugha ya Kiingereza katika jukwaa la Kiswahili la wikipedia.--AlphoAmbrosi (talk) 12:13, 30 April 2022 (UTC)

Itakuwa ni vizuri kama na mfumo utakuwa na lugha tofauti--Rutakolezibwa (talk) 12:26, 30 April 2022 (UTC)

@AlphoAmbrosi & @Rutakolezibwa Shukrani kwa ajili ya maoni haya! Ulikuwa na swali kuhusu msaada katika lugha ya Kiswahili. Hili ni swali kubwa sana. Tunapanga zana yetu kupatikana katika lugha yoyote ya wiki katika siku zijazo. Hivi ndivyo itakavyofanya kazi: Mara tu tutakapokuwa tayari, tutashiriki maandishi yote ambayo ni sehemu ya chombo kwenye Translationwiki. Kisha, watu wanaweza kutafsiri katika lugha tofauti, ikiwa ni pamoja na Kiswahili. Hivi ndivyo itakavyopatikana katika lugha tofauti. Shukrani kwa ajili ya maoni! IFried (WMF) (talk) 20:13, 3 May 2022 (UTC)

Kwa maoni yangu naona itasaidia pia kuongeza wigo kwa wachangiaji wa wikipedia haswa wachanga na wapya ili wazidi kujifunza zaidi.-- --Janeth Mosha (talk) 12:19, 30 April 2022

@Janeth Mosha Safi sana. Asante kwa maoni haya na msaada wako wa mradi huu! --IFried (WMF) (talk) 20:10, 11 May 2022 (UTC)

Mfumo uendelee kurahisishwa ili uwe rafiki kwa kila mtumiaji wazoefu na watumiaji wapya.--Evance Ajwang (talk) 12:28, 30 April 2022 (UTC)

@Evance Ajwang Shukrani kwa ajili ya maoni haya! Kwa kweli tunatarajia kurahisisha usajili kwa hafla za kampeni. IFried (WMF) (talk) 20:13, 11 May 2022 (UTC)

Mfumo utakuwa mzuri kuweka taarifa zote sehemu moja lakini itakuwa vizuri zaidi kama itahusisha kuendesha vikao moja kwa moja mtandaoni.--Killy95 (talk) 12:28, 30 April 2022 (UTC)

@Killy95 Shukrani kwa ajili ya maoni haya! Tunaanza na zana ya usajili, lakini tunapanga kujenga zana zaidi katika siku zijazo. Tunahitaji tu kufanya kazi polepole na kwa kuongezeka, na tunaendeleza miradi zaidi kwa muda. Katika siku zijazo, tungependa kujenga zana ambazo zinasaidia waandaaji wakati wa hafla hiyo. Shukrani kwa ajili ya maoni haya! IFried (WMF) (talk) 20:15, 11 May 2022 (UTC)

Nadhani mfumo huo utakuwa bora zaidi ukiwa katika lugha zote tunazotumia katika kuhariri makala --Briton James Mhitike (talk) 12:33, 30 April 2022 (UTC)

@Briton James Mhitike Samahani, nimechanganyikiwa kidogo na maoni haya. Je, unaweza kueleza? Asante! IFried (WMF) (talk) 20:15, 11 May 2022 (UTC)

Mfumo ni mzuri ila Naomba uboreshwe kidogo ili kurahisha maana umekuwa mgumu kwa wageni hasa wa masuala ya teknolojia.RMshaba (talk) 12:46, 30 April 2022 (UTC)

@RMshaba Shukrani kwa ajili ya maoni haya! Ni maboresho gani ungependa kwa wageni? Je, unaweza kushiriki maelezo? Tunatarajia majibu yako! IFried (WMF) (talk) 20:16, 11 May 2022 (UTC)

Mfumo huu ni nzuri ila waendelee kuufanya uwe rahisi kwa ajili ya kuwasaidia wale ambao ni wageni wa mfumo huu.VICTOR BARAKA (talk) 12:48, 30 April 2022 (UTC)

@VICTOR BARAKA Shukrani kwa ajili ya maoni haya! Je, una mapendekezo yoyote ya jinsi tunaweza labda mfumo rahisi kwa wageni? IFried (WMF) (talk) 20:24, 11 May 2022 (UTC)

Itakuwa vyema pia kama mfumo utakuwa na kalenda ya matukio yaliyopita pamoja na yanayokuja na kutoa notifications za mikutano ili kuwasaidia watumiaji kujisajili na kujiandaa mapema. Pia kuna haja ya kufanya tathmini ya mikutano yote kila baada ya muda (Periodic Assessment). Rekodi/ripoti za mikutano iliyopita zitawawezesha wanaWikiMedia kutoa maoni yao kama malengo ya mkutano husika yamefikiwa au la!--JAMES K. LAURENT (talk) 12:49, 30 April 2022 (UTC)

@JAMES K. LAURENT Shukrani kwa ajili ya maoni haya ya busara! Tunakubaliana kabisa. Kwanza tunajenga mfumo wa usajili. Hata hivyo, tuna mipango ya kufanya miradi mingine kwa ajili ya uzoefu wa kuandaa kampeni. Mipango hii ni pamoja na mapendekezo yote uliyotaja. Tunapanga kufanya mradi wa kalenda ya tukio katika siku zijazo, ili watu waweze kuona matukio yote ya kampeni yakiendelea katika harakati. Tunapanga kuboresha njia za kuboresha arifa, kama vile kuwaalika watu kwenye matukio na kuwakumbusha watu kuhusu matukio. Hatimaye, tunataka pia kuboresha zana za kufuatilia athari na kuripoti vipimo vya kampeni. Miradi hii itakuja katika siku zijazo, na itachukua muda kuendeleza, lakini ni dhahiri katika mipango yetu ya muda mrefu. Asante sana! IFried (WMF) (talk) 20:28, 11 May 2022 (UTC)

Mfumo ni mzuri sana kwani utarahisisha utendaji, lakin pia nashauri ufanywe kuwa rahisi kwa namna ya lugha, lakini pia kuonyesha dhamira za tukio kwa urahisi Yoramtohny (talk) 12:38, 1 May 2022 (UTC)

@Yoramtohny Shukrani kwa ajili ya maoni haya! Je, unaweza kutoa maelezo zaidi kuhusu kile unachomaanisha katika maoni kuhusu lugha? Kwa madhumuni ya tukio hilo, habari hii itajumuishwa katika maelezo ya ukurasa wa tukio badala ya maelezo ya usajili. Labda unaweza kutoa maelezo zaidi juu ya kushiriki kusudi la tukio pia. Asante! IFried (WMF) (talk) 20:30, 11 May 2022 (UTC)

Kuhusu Majina mawili ya Maeneo ya Wiki (2 new namespaces proposal)

Majina haya mawili yamenivutia sana. Watu wengi watapata wasaa mzuri wa kwenda moja kwa moja kwenye kitu anachokitaka iwe picha za matukio au makala na si kutumia muda mrefu kutafuta anachohitaji. --AlphoAmbrosi (talk) 12:15, 30 April 2022 (UTC)

@AlphoAmbrosi Nzuri sana kusikia! Shukrani kwa ajili ya maoni haya. IFried (WMF) (talk) 20:31, 11 May 2022 (UTC)

Hakuna shida yakiwa hayo lakini ningependa kupendeza jingine kama linaweza kukubalika. Jina lenyewe ni Event Corner --Rwebogora (talk) 12:23, 30 April 2022 (UTC)

@Rwebogora Shukrani kwa ajili ya mapendekezo haya! IFried (WMF) (talk) 21:22, 11 May 2022 (UTC)

Majina pendekezwa ni sahihi yanaendana na uhusika na yana tamkika kiurahisi.--Killy95 (talk) 12:30, 30 April 2022 (UTC)

@Killy95 Majina pendekezwa ni sahihi yanaendana na uhusika na yana tamkika kiurahisi. IFried (WMF) (talk) 21:22, 11 May 2022 (UTC)

Feedback from Swahili Community (Swahili Office Hour)