Page MenuHomePhabricator

Consolidate the many tech events calendars in Phabricator's calendar
Closed, DeclinedPublic

Description

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 :)

Related Objects

Event Timeline

There are a very large number of changes, so older changes are hidden. Show Older Changes
Qgil added a comment.May 15 2016, 9:23 AM

After a first wave of feedback it is clear that we have two different discussions that need solving:

  1. If we use WMF Technical Collaboration budget for Phabricator improvements, should we invest it the Calendar application? This is a well framed discussion with a clear deadline for decisions (very soon, or our FY2015-16 budget will be gone). I have created a task to discuss this specifically: T135327: Decide Phabricator improvements to be funded by WMF Technical Collaboration
  2. If we want to improve the announcement and promotion of Wikimedia tech events, is the best first step to improve Phabricator Calendar? This is a complex discussion with many ramifications that we can keep discussing here.
Qgil added a comment.EditedMay 15 2016, 10:19 AM

Thank you for the quick and diverse feedback provided so far. Some thoughts:

Sure, the perfect solution would be a MediaWiki extension deployed in Wikimedia and available for 3rd parties, but let me share why I think this is not possible within the scope of this exercise:

  • The Technical Collaboration team has some budget available for FY2015-16, to be used by the end of June. What can be achieved within this timeline? Certainly not anything in the form of a new extension in the Wikimedia cluster. In comparison, the Phabricator Calendar improvements could be developed and deployed in Wikimedia within that timeframe.
  • Who is going to develop that extension? After agreeing on a plan for a MediaWiki extension, we need to define who will work on it as paid work, which also takes time. In comparison, funding Phacility Inc for Phabricator upstream improvements is a straightforward and quick decision.
  • Who is going to maintain that extension? The Technical Collaboration team doesn't have the skills to maintain it, and the Community Engagement department has a known problem of mid term sustainability plans of the software we commission and own. While other CE teams are trying to reduce and resolve this problem, TC cannot just start the development of a new extension without a maintenance plan. In comparison, the Phabricator improvements funded would be maintained by the Phabricator maintainers.

When it comes to the technical plan, things are anything but clear:
The first requirement is Introducing calendar data, something that plain MediaWiki was not designed for.

  • SemanticMediaWiki is designed for semantic input, but I think it is safe to assume that Wikimedia is not going to increase its dependency on SMW when the trend on wikitech.wikimedia.org / Labs is the opposite.
  • Recent efforts on developing extensions focusing on input of structured data via forms (limiting wiki editing in its purest sense) are being met by a small but perseverant current of criticism. Would this project conflict with that view? (I don't agree with such view, and I wouldn't want to be a participant in such discussion)
  • In previous discussions about something new, Wikidata was mentioned as part of the solution, and then the Wikidata team disagreed for reasons that I found convincing. Is this another of these cases? In any case, that would not solve the input problem immediately either.
  • In comparison, Phabricator Calendar provides a way to input data designed for events, it is based on free software, and it is already deployed in Wikimedia servers.

I think that starting this effort by requiring native calendar input data in MediaWiki is not the best tactic. Once the calendar data is introduced and available somewhere via .ics, a MediaWiki extension could focus on its presentation in MediaWiki pages. That would probably solve better the 3rd use case, since I can imagine many MediaWiki users needing calendar data in their wikis to have that data already in Google Calendar, Facebook Events, or elsewhere able to export data via .ics.

I also want to note that output in MediaWiki pages is not the only destination of calendar data, and I would even contest the idea that it is the most important. I believe that most of our users would use this data integrated in their own calendars, importing Wikimedia events/calendars and following their updates from their calendar apps. That is also a reason why I am not obsessed with having MediaWiki output first, or as a requirement for any first step.

For all these reasons, I still think that improving Phabricator Calendar is the best first step solving our problems with calendars. A step that would solve most of the Wikimedia tech problems, and a step that would be in a direction compatible with solving the problem for the rest of Wikimedia, and other MediaWiki users.

The MediaWiki extension able to read .ics data and embed it in MediaWiki pages could be a good candidate for an Individual Engagement Grant. That program is well suited to evaluate movement priorities, feasibility of plans, and funding specific contributors, all done under a community review process.

If we solve the Phabricator Calendar piece in the next 2-3 months, and the MediaWiki extension piece in the next IEG round, we could have a good enough solution for everybody by the end of the year or so.

Qgil wrote:

SemanticMediaWiki is designed for semantic input, but I think it is safe to assume that Wikimedia is not going to increase its dependency on SMW when the trend on wikitech.wikimedia.org / Labs is the opposite.

If anyone's wondering, I assume he's referring to this ticket: T53642. To summarize that discussion: three of the DevOps people want to replace SMW on their system with dedicated DevOps tools. How relevant that is to this discussion is a matter of personal opinion.

I hate to sound like a broken record here, but SMW is already in successful use on hundreds of wikis, including probably dozens where it's used specifically to manage calendar and event data. It provides all the functionality that people are talking about here, as far as I can tell: data entry, standard calendars, customized views/queries, data export. Cargo is a newer extension (first released in 2015), so it hasn't gotten as much use so far, but it does essentially all the same stuff as SMW.

One important reason for WM-ES to install Owncloud was precisely so we could use its calendar features.
Storing calendars in external platforms like Google of Facebook is far from ideal. Even if people really had it in one of those unfree platforms{{citation needed}}, the problem is not just showing the ics calendar, but also editing it.
If it's stored in the wiki, that would be relatively straightforward, compare that to finding out it is included from a Facebook calendar, which requires you to create a Facebook account, then ask for permission to someone else (which may not even be too active now) for changing the calendar, just to enter your local event.
And all of these duplicating the existing organization at a parallel site.

Storing the calendars in phabricator may work for the Wikimedia technical community, but doesn't solve the problem for the second group.

In T1035#2295517, @Qgil wrote:

Sure, the perfect solution would be a MediaWiki extension deployed in Wikimedia and available for 3rd parties, but let me share why I think this is not possible within the scope of this exercise:

Should we spend budget in a suboptimal solution because of time constraints for expenditure in the TC team?
It may be worth it for the interim benefit. And while I prefer to spend money that way than developer hours, it's still a tough decision.

I agree that just because there is a budget and a time constraint doesn't mean that's the best approach -- especially because a bandaid and/or short-term solution may not provide what is needed in the long-term.

The google calendar and folks using Facebook event pages seems to be working right now. Is it ideal? No.

The lowest technical barrier on the end users and organizers is my biggest concern. Not sure any of these options is an improvement -- or needs to be a focus of this discussion. But wanted to mention it just in case.

Erika
User:BrillLyle

Should we spend budget in a suboptimal solution because of time constraints for expenditure in the TC team?
It may be worth it for the interim benefit. And while I prefer to spend money that way than developer hours, it's still a tough decision.

Qgil added a comment.EditedMay 15 2016, 4:47 PM

A solution that would work for the Wikimedia Tech community is not a suboptimal solution, is a valid solution for a specific problem (which doesn't conflict with potential solutions for the non-tech Wikimedia communities).

As for the general problem...

@Platonides, can you show the use of calendar by Wikimedia Spain? Installing OwnCloud on your own server looks like a much more technical and involved task than just using Phabricator Calendar for your org/project. For what is worth, every time there are more chapters and non-tech groups that are using Phabricator as a project management tool.

@BrillLyle, have you tried Phabricator Calendar? I think it is quite low barrier as soon as users don't make the mental connection "Phabricator == technical, not for me", but I would be very interested in discussing the details.

I am not proposing to rely on Google, Facebook on anything at Wikimedia, so we can take this topic out of this discussion.

Anyone can request funding to develop a MediaWiki extension that allows native input of calendar data. It's just that such funding request will need to come from grants, because (for the bureaucratic-sounding but very real reasons I have explained) the budget that our team has right now will not be available on July 1.

By the way, I just rewrote this page, to be clearer and more up-to-date:

https://www.mediawiki.org/wiki/Extension:Calendar

@Qgil -- Hi Yes I have looked at the Phabricator Calendar. It seems fine but there are some significant things missing that would mean loss of functionality. (i.e., time zone support, color coding, ability to select and maintain different calendars, ability to copy to events to personal calendar, etc.). It also requires end users sign in using OAuth and have a Phabricator account, correct? We have problems getting participants onboarded to the en-Wiki so this is another thing that I'm just thinking of. Unless this solution was fully integrated with Wikipedia where it would not require logging in to another system to easily copy/export events, I am concerned this is a big issue.

The fact of the matter is that the current reliance on Google and Facebook is a reality for most end users and organizers. So I think that while the focus of this solution is on Phabricator and MediaWiki options, it would be a bit "head in the sand" to ignore the reality of what is going on. These popular external calendars need to be able to be integrated -- either in export or import -- somehow with existing systems. They are sort of the only game in town calendar-wise, and it's not just because of market share, but because of functionality and the integratedness of the two options.

Sorry, I don't mean to be demanding (but I am) or discouraging (yeah that too).

– Erika
User:BrillLyle

In T1035#2295877, @Qgil wrote:

@BrillLyle, have you tried Phabricator Calendar? I think it is quite low barrier as soon as users don't make the mental connection "Phabricator == technical, not for me", but I would be very interested in discussing the details.
I am not proposing to rely on Google, Facebook on anything at Wikimedia, so we can take this topic out of this discussion.
Anyone can request funding to develop a MediaWiki extension that allows native input of calendar data. It's just that such funding request will need to come from grants, because (for the bureaucratic-sounding but very real reasons I have explained) the budget that our team has right now will not be available on July 1.

Dzahn removed a subscriber: Dzahn.May 16 2016, 2:48 PM

@Qgil Wouldn't that require that each of our members created an account here? (Not that this was available until recently, so it's no wonder it hadn't been brought up as anoption). It may be worth trying, though.

And installing a local phabricator instance… no, thanks.

Qgil added a comment.EditedMay 17 2016, 6:02 AM

Wikimedia groups like WMES don't need to install their own Phabricator instance. They can use Wikimedia Phabricator instead.

Only the users willing to introduce and manage calendar data would need to create an account here (which they can do with their Wikimedia accounts). Users only needing to access that data can visit the URLs of the calendars they are interested about, and according to this proposal they will be able to import Wikimedia Phabricator calendar data to their own calendars importing the iCalendar files (.ics)

Users with a Phabricator account are able to RSVP, comment, and associate events to other projects (promoting activities to the users following those projects).

@BrillLyle, we are not trying to compete with Google Calendar, but I think we can aim to provide the basic functionality that most people may need for Wikimedia activities. From your list:

  • Time zone support. Events are created with the timezone of the event creator, and that timezone can be defined in the user profile. As of today, events cannot be created in a different timezone, but this is a problem with a simple workaround (find out the time in your own timezone). Not a blocker.
  • Color coding. Missing indeed. Icons can be defined for events, and if this is considered important then perhaps colors could be defined as well, just like it is possible to define icons and color for projects. This looks like an improvement simple to implement that would provide basic color cues in calendars.
  • Ability to select and maintain different calendars. This is possible, by associating events to projects (i.e. ArchCom meetings, Tech Talks, Wikimania Hackathon 2016...) and by querying events in a pretty advanced way (i.e. IRC Office Hours about VisualEditor during 2015, displayed in month view). These queries provide static URLs that can be shared with users.
  • Ability to copy to events to personal calendar. Phabricator users can RSVP already now, and this will make events appear in their personal Phabricator calendar. According to this proposal, they will be able to import the .ics data as well, which will integrate such data in their calendar apps.
Qgil lowered the priority of this task from High to Normal.Jun 1 2016, 2:23 PM

Just a reminder that if, say, Cargo and Semantic Forms were installed on mediawiki.org today, there would be functioning event-entry forms and event calendars on the site, probably by the end of the day. (And at no cost.)

Just to chip in my $.02, I would encourage us to look for a solution that can be used on-wiki. There's something about investing time/money/energy in on-wiki solutions that sits better with me. Maybe it has to do with an on-wiki solution being more inviting. People without or only entry level development skills will find the information easier than here in phabricator, where super dev skills are the norm. :)

I understand that SMW was declined many years ago. What were the reasons for the declination? It's not clear to me if those still stand today. Could those be addressed?

@Yaron_Koren You're far more savvy with this than I, but does SMW meet these requirements? https://wikitech.wikimedia.org/wiki/Writing_an_extension_for_deployment

My personal bias aside, SMW seems like a present solution that is free, on-wiki, adaptable, and within our own MediaWiki community. Much different than spending money on a one-time development of a feature from an outside vendor. Ok, that was totally biased.

@CKoerner_WMF - as I noted earlier, Semantic MediaWiki was declined for use on Wikipedia, in favor of Wikidata. (Which was the right choice.) I don't believe it has ever been reviewed for use on, say, mediawiki.org.

And - though I'm repeating myself - Cargo is, in my opinion, the better option. But either one would work.

Danny_B added a subscriber: Danny_B.Jul 3 2016, 8:12 PM

Punting to Oct-Dec for Dev-Rel.
Not to happen this quarter as long as T136213 isn't resolved which is external.

Qgil added a comment.Sep 27 2016, 1:05 PM

Initial support for ICS export is available in Phabricator HEAD, and the work is continuing as we speak -- see https://secure.phabricator.com/T10747

I am counting on this ICS support for this proposal: T146749: Consider using Phabricator Calendar events to schedule Wikimedia Developer Summit sessions

@Qgil: That will land in our phabricator tomorrow night (midnight UTC) when I deploy #phab-2016-09-28

(Aforementioned deployment postponed due to Ops offsite)

Qgil added a comment.EditedOct 7 2016, 8:28 AM

I just

  1. created E329: Quim on vacation (Phabricator export ics test)
  2. clicked "Export as .ics", and an .ics file was downloaded to my laptop
  3. imported the .ics file to my Google Calendar

The event is now visible in my calendar. Progress!

Qgil added a comment.Oct 7 2016, 1:40 PM

There is more coming (just landing in Phabricator HEAD, not stable yet):

https://secure.phabricator.com/book/phabricator/article/calendar_exports/

In T1035#2698874, @Qgil wrote:

I just

  1. created E329: Quim on vacation (Phabricator export ics test)
  2. clicked "Export as .ics", and an .ics file was downloaded to my laptop
  3. imported the .ics file to my Google Calendar

The event is now visible in my calendar. Progress!

So as in mine. I don't know if it was the expected result. ;)

Qgil added a comment.Oct 27 2016, 2:02 PM

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

Re DevSummit: Hmm, I'm not convinced. "Dealing with calendar data in the Wikimedia movement"?

Qgil removed Qgil as the assignee of this task.Jan 17 2017, 8:26 AM

We can use Developer-Wishlist (2017) to check how much interest there is for this idea.

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Dvorapa added a subscriber: Dvorapa.Feb 6 2017, 9:50 AM

Status update of related upstream tasks:

The first item is likely still a blocker (Google Calendar being popular) for this very downstream task T1035, while I think the second might not be that crucial for us?

Removed parent task T136213 as the technical side seems to be done.

Dvorapa removed a subscriber: Dvorapa.May 10 2017, 10:32 AM
Tgr added a subscriber: Tgr.May 30 2017, 12:55 PM

Pretty useless though in its current form as there is no stable export URL (the "export" link just takes you to a web page that initiates download of the actual file via JS) so you cannot plug an URL into your calendar client and get changes to the event automatically synced.

Declined, actually (upstream uses task statuses in weird ways), except for Google Calendar integration, which has not been done yet.

I realize this is well-underway but I recently came across this public events calendar and really liked the format and the code is up on GitHub so I thought I would share as a stickie in case there are future revisions planned down the road.

(I also realize this could be a totally annoying update given the status of the project so if it's irrelevant, please ignore and forget this message ever existed. :))

Qgil added a project: Goal.Oct 4 2017, 7:45 AM
Qgil moved this task from Backlog to Ready to Go on the Developer-Advocacy (Oct-Dec 2017) board.

This task is now a Goal. I need to update the description.

Qgil removed Qgil as the assignee of this task.Feb 27 2018, 12:39 PM
Qgil lowered the priority of this task from Normal to Low.

I keep not having time to even start thinking seriously on this task, and I believe it is better to reflect reality.

[See Also] Similar task for (non-technical) Education events, wondering where they should put such a potential calendar: T111968: Open an EDU event calendar

Tgr added a comment.Jun 5 2018, 10:40 AM

Meanwhile, Meta seems to be moving to a wiki-based calendar: https://meta.wikimedia.org/wiki/Template:Events_calendar

I'd propose to revert 2015's T1035#1579199 and go back to the original task scope.

We can use Developer-Wishlist (2017) to check how much interest there is for this idea.

#66 out of 76, for the records.

Quiddity mentioned this in Unknown Object (Task).Jul 6 2018, 5:29 PM
Aklapper lowered the priority of this task from Low to Lowest.Feb 1 2019, 9:59 PM
Aklapper closed this task as Declined.Jul 18 2019, 4:13 PM
Qgil added a comment.Jul 22 2019, 2:54 PM

Yes, agreed.