Page MenuHomePhabricator

[Request for Comment] New "Event" and "Event Talk" namespaces
Open, Needs TriagePublic

Description

What?

  • The Campaigns team would like to build a designated place in the wikis for pages that are for events.

What does the future look like if this is achieved?

  • The Campaigns team is proposing that we create two new namespaces in MediaWiki, which will be called “Event” and “Event Talk.” There are currently multiple namespaces in the wikis (for example, there are 28 in English Wikipedia, and there are 36 on Meta-Wiki).
    • Implementation task (blocked pending outreach/review): T296280
  • The new namespace will be the default place for event pages. We want a way to easily determine what is an ‘event’ page, so that we can:
    • Add registration to event pages (and avoid adding it to inappropriate pages, such as article pages).
    • Display all events in an event calendar in the future.
    • Efficiently determine how many events are going on in the movement.
    • Note: Some of these items can also be achieved with some kind of opt-in process which transforms a page into an event page, but this is out-of-scope for the MVP.
  • We want to make it easier for everyone to know what is an event page vs. another kind of page in the movement, since right now event pages often look the same as article pages.
  • We want to highlight the fact that event engagement (whether it’s organizing events, participating in events, promoting events, etc) is a form of movement activity, and that someone can be an impactful Wikimedian in more ways than just contributing to the wikis.

What happens if we do nothing?

  • Without a designated namespace for events:
    • There would be no mechanism to stop contributors from adding our event registration tools to inappropriate pages, such as article pages.
    • Creating an event page would require an additional step to transform it into an actual event page recognized by our extension.
    • It would be more difficult to find and display all events in an event calendar in the future.
    • It would be more difficult to determine how many events are going on in the movement.
    • It would be more difficult for everyone to know what is an event page vs. another kind of page in the movement, since right now event pages often look the same as article pages.

Why?

User Value/Organization Value AND Objective it supports and How

  1. Grow in Underserved Communities (T-GUC): New Contributors in underserved communities will feel welcomed and successful and continue to contribute over time.
    1. Team Objective 1 (Q3 21-22): The team begins developing an event platform, so that organizers can have simplified workflows and create more impactful events.
      1. K1: Engineers have determined the short-term architectural approach for MVP and have started to build V0.

Why are you bringing this decision to the Technical Forum?

  • While adding new namespaces isn't necessarily a cross-cutting change to mediawiki, the Campaigns team is conducting technical, product, and Wikimedia community outreach to ensure that our plan is a good one and that there are no major issues or concerns.

Event Timeline

ldelench_wmf renamed this task from New "Event" and "Event Talk" namespaces to [Request for Comment] New "Event" and "Event Talk" namespaces.Feb 17 2022, 10:45 PM

The OpenStreetMap wiki could use this. Right now we have a pretty jank off-site event/calendar solution that interfaces with the wiki.

This is an exciting proposal! I'd be interested in any research or planned research that can be made public, about the types of event that we would need to support. I can imagine a wide variety:

  • one-time, online or in-person event
  • recurring event
  • multi-day event such as a conference
  • long-running event such as a Wiki Loves Earth campaign.
  • multi-stage event with related but distinct phases such as elections, with a call for candidacies, discussion, and voting.

Location seems important as well, for example to find the relevant entries in a long list of regional gatherings. Generally, I see that the problem statement is currently written from the perspective of the Campaigns team, but I suspect that end-user needs will be more about filtering and prioritizing the information, rather than getting an overview of everything.

Ideally we don't have to reinvent the calendar, maybe we should be targeting a standard CalDAV endpoint and bidirectional integration with external tools such as NextCloud, or embedded rendering supplied by a dedicated component?

I would question how much of the event's content needs to be segregated into a new namespace—one alternative would be that the bare event metadata (time, place, etc.) is stored in this Event namespace as metadata, but the event is still described on an article page which links to this metadata similar to how a Wikidata item can be linked. (Or kept in a multi-content revision slot.)

Update: The ticket has been withdrawn from the process because we had a meeting with the technical decision forum, and they confirmed that they had no problem/concern with us creating new namespaces for 'event' and 'event talk.'

@awight Thank you so much for the comment and the token! It was great to read your comment, and the Campaigns team is very happy to know that you find the creation of an 'event' and 'event talk' namespace to be useful for the movement. We completely agree that that the namespace could be applicable to more than just campaign events (such as Wiki Loves Earth, WikiGap, etc). It could apply to all of the event types you mentioned, such as conferences or meetups that may be online or in-person and that may be one day, multi-day, or recurring. We hope that people can use the namespace in ways that works best for them, and that it can be open and flexible rather than restricted to one specific event type. We identified this need by initially looking through the campaign events lens, but it certainly extends beyond campaigns.

Regarding your technical questions, I will ping @Daimona, an engineer on our team, who can respond better than I can.

Finally, if you would like to learn more about our work, you can check out the project page for our first project to build an on-wiki registration solution. We shared our proposal for the two new namespaces in our recent March status update. We invite you to share any feedback on the project on the talk page. You can also subscribe to our notification list to get periodic updates on our work. As for the events calendar feature, we haven't started working on it yet, but when we do, we'll announce it to our subscription list (and we'll revisit your comment that you shared on it).

Thank you again!

I would question how much of the event's content needs to be segregated into a new namespace—one alternative would be that the bare event metadata (time, place, etc.) is stored in this Event namespace as metadata, but the event is still described on an article page which links to this metadata similar to how a Wikidata item can be linked. (Or kept in a multi-content revision slot.)

Thanks for the feedback! The issue is not about storing the event metadata (which is always going to be stored in an extension DB table); instead, it's about making event pages a "special kind of pages" (i.e. pages that represent an event and can have an associated event registration). We need certain things to happen on the event description page itself: for instance, we want to show some buttons or modals that would prompt the user into adding event metadata. The thing is, we need to know on which pages those things should be shown, and a namespace seemed the best (although not perfect) way to do that.

An MCR-based solution would be nice, and we considered that. However, integrating that with EditPage would be more complex, and T209044 should also be fixed first.

An MCR-based solution would be nice, and we considered that. However, integrating that with EditPage would be more complex, and T209044 should also be fixed first.

Just to check on on that - what's your current plan for integration with the edit page?

Full structured storage per T209044 is only needed if you need old versions of the data to be queriable. If you only need the current version to be queriable, just do what we already do for all content: store a blob for "archival", and extract queriable data from the current version and store it in whatever form is best for your use case. The blob store is really only for the archive of old revisions, we never use if for any operation on the current revision.

Of course, if you don't need "wiki-ness" for the event data (integration with page history, watch, revert, deletion, protection, renames, etc), then storing the data elsewhere is easier.

An MCR-based solution would be nice, and we considered that. However, integrating that with EditPage would be more complex, and T209044 should also be fixed first.

Just to check on on that - what's your current plan for integration with the edit page?

None, unfortunately. We determined that working on that integration would take too long. I would still like to revisit that idea after T20654, T174033, and T204112 are done.

Full structured storage per T209044 is only needed if you need old versions of the data to be queriable. If you only need the current version to be queriable, just do what we already do for all content: store a blob for "archival", and extract queriable data from the current version and store it in whatever form is best for your use case. The blob store is really only for the archive of old revisions, we never use if for any operation on the current revision.

Yeah, that would work and I don't think we care about old revisions. However, I was concerned by the duplication of data (in our store and in ES). I know this is not too important, but it would still be great to avoid that.

Of course, if you don't need "wiki-ness" for the event data (integration with page history, watch, revert, deletion, protection, renames, etc), then storing the data elsewhere is easier.

They're not critical features, but some of those could be nice to have, hence we explored MCR.

Just to check on on that - what's your current plan for integration with the edit page?

None, unfortunately. We determined that working on that integration would take too long. I would still like to revisit that idea after T20654, T174033, and T204112 are done.

If you are going for a dedicated special page and/or API, you are free to choose whatever storage mechanism suits you best. MCR or something else.

For the record: I don't know if MCR is the best choice for your use case. If your content doesn't need wiki style curation and history support, you probably don't want it. I just want to make sure that you are not avoiding it for the wrong reasons.

Yeah, that would work and I don't think we care about old revisions. However, I was concerned by the duplication of data (in our store and in ES). I know this is not too important, but it would still be great to avoid that.

Don't worry about that, unless you are expecting to have megabytes of data or thousands of edits per hour. Bytes are (comparatively) cheap. We duplicate data all the time to optimize access speed (caches, database indexesm etc). You can think of it the other way around: you are using compac storage for historical data.

When you say you don't care about old revisions, do you mean you don't need to be able to query them, or do you mean you don't need the data at all? If you don't need history/diffs/reverts etc, then it's not wiki content, and you don't need MCR.

Of course, if you don't need "wiki-ness" for the event data (integration with page history, watch, revert, deletion, protection, renames, etc), then storing the data elsewhere is easier.

They're not critical features, but some of those could be nice to have, hence we explored MCR.

MCR gives you these (nearly) for free. But if you really don't need them, you don't need MCR. On the other hand, if you *do* need them, you really should use MCR (or separate pages). re-implementing "wiki-ness" would cause a lot of trouble (point in case: Flow).

Yeah, that would work and I don't think we care about old revisions. However, I was concerned by the duplication of data (in our store and in ES). I know this is not too important, but it would still be great to avoid that.

Don't worry about that, unless you are expecting to have megabytes of data or thousands of edits per hour. Bytes are (comparatively) cheap. We duplicate data all the time to optimize access speed (caches, database indexesm etc). You can think of it the other way around: you are using compac storage for historical data.

Consistency, and not redundancy, is what concerns me. If we duplicate the data, we also need to ensure that the two storages do not drift. For instance, if we make it possible to edit slots other than the main one from action=edit, we would need to ensure that it also updates our storage. All of this is possible, of course, and as I said, duplicating the data is certainly not the main issue, and most likely just a secondary one.

When you say you don't care about old revisions, do you mean you don't need to be able to query them, or do you mean you don't need the data at all? If you don't need history/diffs/reverts etc, then it's not wiki content, and you don't need MCR.

Just querying, I think. Everything else is not necessary (at least at this stage), but I think it would be nice to have it. I don't think we know for sure how useful these features would be though.

At any rate, I assume we may revisit the MCR idea at some point.

Consistency, and not redundancy, is what concerns me. If we duplicate the data, we also need to ensure that the two storages do not drift. For instance, if we make it possible to edit slots other than the main one from action=edit, we would need to ensure that it also updates our storage. All of this is possible, of course, and as I said, duplicating the data is certainly not the main issue, and most likely just a secondary one.

Yea, that's indeed a concern. The DataUpdate mechanism should help with keeping things consistent, core relies on it for links tables and other derived data. But every now and then, things can get out of sync though some bug, and derived data needs to be regenerated. Typically, a null-edit would do it.