Page MenuHomePhabricator

Build a bot that pushes Phabricator updates to Google Chat
Closed, DeclinedPublic

Description

Now that the WMF has Google Chat (their answer to Slack and their evolution of Hangouts) we should consider building a bot that pushed updates from Phabricator tickets (scoped to project/tag) to Chat. This would be much like the wikibugs bot in IRC.

Since everything in Google Chat is a thread, a task should get it's own thread (if one doesn't exist) and then a new message for each "action" under that thread.

The bot should work with any instance of Phabricator (via configuration)

It might also be helpful if the Phabricator bot could accept certain commands (like creating a new task, etc.)


Links

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptMar 9 2018, 5:14 PM

Not sure if the projects I added are accurate, Andre. :)

dbarratt updated the task description. (Show Details)Mar 9 2018, 5:16 PM
dbarratt updated the task description. (Show Details)Mar 9 2018, 5:18 PM
Aklapper triaged this task as Lowest priority.Mar 9 2018, 9:56 PM

Heh. :)
Removing Phabricator-Bot-Requests as per its scope described on https://www.mediawiki.org/wiki/Phabricator/Bots linked from the project description - this is not about creating a bot account in Phabricator itself.

This might be something to work on outside of Wikimedia (or "upstream"), as it sounds like an idea not specifically related to Wikimedia.

Links to Google Chat API references welcome, I guess.

Legoktm added a subscriber: Legoktm.Mar 9 2018, 9:59 PM

Why do we want to push Phabricator updates to a closed-source, proprietary chat system?

Team productivity.

Seeing how quickly proprietary projects can decide to disable team productivity features (like Slack disabling their IRC and XMPP gateways) I don't see why interacting with random isolated data silos that are potentially only used by some WMF internal teams should be tracked in Wikimedia's (emphasis by me) issue tracker.
Of course I can't stop anybody from writing whatever code they are interested in in their free time though. :)

Just a note : according to https://wikitech.wikimedia.org/wiki/Mail, lots of @wikimedia.org mail address are forwarded to Google's servers. So the independence of our movement against proprietary projects... :)

Of course I can't stop anybody from writing whatever code they are interested in in their free time though. :)

Right, it just sounded like a request to make wikibugs also push updates to Google Chat.

dbarratt claimed this task.Mar 15 2018, 6:08 PM
dbarratt updated the task description. (Show Details)
Joe added a subscriber: Joe.EditedMar 15 2018, 10:31 PM

Just a note : according to https://wikitech.wikimedia.org/wiki/Mail, lots of @wikimedia.org mail address are forwarded to Google's servers. So the independence of our movement against proprietary projects... :)

There is a profound difference between using a commercial service for accessing a free, federated protocol like email or IRC are, and locking yourself in the proprietary, non-federated/interoperable world of Google Chat/Slack.

We could move wikimedia's emails off of google servers to any other commercial service, or maintain one ourselves, without any loss of functionality. We would not be able to do so if we lock ourselves in further with google closed-source tools.

Tgr added a subscriber: Tgr.Mar 15 2018, 11:34 PM

Seeing how quickly proprietary projects can decide to disable team productivity features (like Slack disabling their IRC and XMPP gateways) I don't see why interacting with random isolated data silos that are potentially only used by some WMF internal teams should be tracked in Wikimedia's (emphasis by me) issue tracker.

I don't see how a team working on Wikimedia software tracking tasks related to their tooling in Wikimedia's issue tracker could possibly be controversial. If someone thinks WMF teams should not be allowed to use proprietary communication tools (beyond Google Apps and IRCCloud I guess) that's one thing (as long as you are ready to accept when consensus is not on your side); but trying to prevent it from being tracked in Phabricator is a completely unreasonable way to go about it.

Meanwhile if you want to do something useful for moving towards a FLOSS work infrastructure, T186061: Evaluate Matrix / Riot.im could use more people looking at it. (Thanks @Aklapper for having done so!)

The proprietary nature of Google Chat isn't just a philosophical issue with regards to using the service. It also means that the features (in this case notifications) developed for Google Chat won't be available to developers not directly contracted by WMF.

dbarratt updated the task description. (Show Details)Mar 16 2018, 3:19 PM
dbarratt added a comment.EditedApr 17 2018, 6:21 PM

Isn't the software that is run on telecom's servers that handles SMS messages and Phone Calls proprietary software? If so, should the foundation cease the use and promotion of SMS?

I'm genuinely curious. I understand the conviction, I just am curious how far it goes (also, someone more familiar with software at telecoms might know more than I do about this).

Tgr added a comment.Apr 17 2018, 10:45 PM

We only support TOTP as a second factor, not SMS tokens.

We only support TOTP as a second factor, not SMS tokens.

I saw that and edited my comment. thanks!

Tgr added a comment.Apr 17 2018, 11:05 PM

The SMS service we use (used? not sure if it is still up) is opensource AFAIK.

In reply to T189313#4137191 by @dbarratt:

I'd see a small difference here. In an ideal world, WMF's Guiding Principles apply. While we cannot directly influence which software is used by telecom companies on their servers, I'd say that we do have more direct influence which tools we ourselves use, somewhere between ideals, convenience, and compromises.

As an organization, we strive to use open source tools over proprietary ones, although we use proprietary or closed tools (such as software, operating systems, etc.) where there is currently no open-source tool that will effectively meet our needs.

That seems really subjective (perhaps intentionally?). Thanks for sharing, I don't think I'd ever read that.

dbarratt removed dbarratt as the assignee of this task.May 7 2018, 4:54 PM
Aklapper closed this task as Declined.May 8 2018, 10:50 AM

As the last edit implies that nobody plans to work on this I'm going to boldly decline this task for the time being.