We have three problems related to calendars that need to be resolved, which are related but perhaps may be fixed separately, even at different points in time:
- Introducing calendar data. Now we are doing this in 1001 places. Ideally it would be just one place. The assumption of this task is that the one place would be Phabricator's calendar (today a prototype), but other candidates should be considered.
- Pulling calendar data in other supports, mainly wiki pages. While we could start linking from wiki pages to Phabricator calendar queries, the desired scenario would be a way for editors to embed calendars based on queries in wiki pages. This probably implies a Calendar API to query data (which is missing) and a MediaWiki extension allowing to embed those queried calendars in wiki pages (which we don't have). Maybe this is just too much, and at least the tech-inclined Wikimedians would be fine clicking a Phabricator link.
- Integrating calendar data with other systems (mainly Google Calendar). "Future work" upstream, no plans today.
As we can see, deciding on Phabricator Calendar as the one place to introduce data would not provide a quick path to use that data out of Phabricator. However, what would be the alternatives? Other than defaulting to Google Calendar (which I think would be wrong as a matter of Wikimedia principles), I don't see a shortcut but others may have better ideas.
Phabricator Calendar in a nutshell
After playing a bit with https://phabricator.wikimedia.org/calendar/, I think the most practical option is to focus on having that calendar up to date, and then link to it from the right places in mediawiki.org.
- Entering events is simpler. The usual you can expect in a calendar application. There is no need to archive past events, since this is done automatically.
- Users can RSVP, getting notifications about the event and letting others know that they are attending.
- The calendars shown are the result of queries allowing for multiple parameters, including month view vs list, show only upcoming events, etc. These queries have static URLs.
- Events can be assigned to projects, which means that
- We could have projects for i.e. Tech Talks, Technical Office Hours, etc, people could subscribe to these projects and receive notifications when a new event is filed.
- By adding an event to existing related projects (i.e. Web-APIs-Hub, Google-Summer-of-Code (2015)), users following that project would receive notifications as well.
- Queries can be fine tuned to show a specific set of events.
If we agree on this, the implementation would be relatively simple, since (at least in Wikimedia tech) a few people create most of the events. Redirecting from the current calendar pages to their equivalent Phabricator calendar queries should be enough to tell current users about these calendars about the new way to create new events.
Basic review of existing MediaWiki extensions
I went through https://www.mediawiki.org/wiki/Extension:Calendar (a linkhub for the ~12 different extensions or methods of integrating calendars with MediaWiki). There was no extension surviving a basic check against our needs. In fact, most of them are more than abandoned, and in general they focus on presentation, not on easy input, even less on semantic data (except the SemanticMediaWiki one, perhaps). SimpleCalendar looks like the only candidate if we would ever want to start from this point.
The reason for a lack of a proper MediaWiki Calendar extension may well be that MediaWiki was not designed to input calendar data, subscribe to events, etc.
After this short investigation, I still think that it is better to start from something other than MediaWiki, and the main candidate keeps being Phabricator. Then work separately in a way to import Phabricator Calendar data and present it in MediaWiki pages.
Background / previous description
https://www.mediawiki.org/wiki/Project:Calendar has a lot of room for improvement. Creating tasks is not trivial, and although the calendar can be watched and the entries appear in the mediawiki.org homepage, it doesn't have any of the features expected nowadays in an online calendar, i.e. integration with the calendar apps people use to organize their lives.
Also, for some low hanging fruit, a reporter explains in an email:
the whole project:calendar page hierarchy is confusing - I would avoid subpages at more than one level deep
It's not clear to me why this page is in the Project: namespace to begin with
https://www.mediawiki.org/wiki/Project:Namespaces seems to suggest the Project: namespace is for "organization of mediawiki.org", which does not describe this page
see https://meta.wikimedia.org/wiki/Tech for a better way to provide consistent navigation/page structure across a set of dispersed pages without use of subpages you asked :)