Page MenuHomePhabricator

MediaWiki extension to embed Phabricator content in wiki pages
Closed, DeclinedPublic

Description

As the adoption of Phabricator for Wikimedia project planning groes, the likeliness of users willing to see Phabricator generated data in wiki pages will grow. The main use case is lists of tasks based on predefined queries (i.e. open tasks of project X). There might be also an interest in transclusing the content of a task (title, description, metadata) in a wiki page.

We had pursued a similar goal with Bugzilla, see T29001: Bugzilla integration extension (for filing bug reports). And see also T58287: Allow embedding RSS feeds from Phabricator into mediawiki.org.

See also

Event Timeline

Qgil created this task.Feb 23 2015, 12:36 PM
Qgil updated the task description. (Show Details)
Qgil raised the priority of this task from to Needs Triage.
Qgil added a subscriber: Qgil.
Restricted Application added a subscriber: Aklapper. · View Herald TranscriptFeb 23 2015, 12:36 PM
jayvdb added a subscriber: jayvdb.Feb 23 2015, 1:34 PM

@mmodell, @chasemp, any idea about how complex would this be (at least the Phabricator part)?

@guillom, in relation to T88468: Create Phabricator project to track noteworthy changes, imagine how nice would be if i.e. the mediawiki.org homepage would display automatically the last tasks tagged with Notice*

I'm not sure how people want this to be done. using the api? or generating something periodically from phab? or?

Sylvain_WMFr removed a subscriber: Sylvain_WMFr.
Qgil added a comment.Mar 3 2015, 7:06 AM

I have no idea about the technical solution, but the expected behavior is that users get information up to date every time they land in a page. If we have to compromise a few minutes of delay for caching purpose, that would be fine too.

For what is worth, when I was using https://www.mediawiki.org/wiki/Extension:Bugzilla in other wikis, the results were satisfactory. No idea whether that solution would scale to Wikimedia dimensions, though.

I have no idea about the technical solution, but the expected behavior is that users get information up to date every time they land in a page. If we have to compromise a few minutes of delay for caching purpose, that would be fine too.

For what is worth, when I was using https://www.mediawiki.org/wiki/Extension:Bugzilla in other wikis, the results were satisfactory. No idea whether that solution would scale to Wikimedia dimensions, though.

Ah now I understand. So it looks like this would be a good hackathon project (to me) if people are interested in such as a thing. The extension isn't too complex, but would require a bunch of testing. The API for phab while not guaranteed stable is pretty much that in practice.

It seems like whatever is being done with @phabricator-bug-status-bot would fit naturally into this, but this isn't something I'm prepared or have the time for now. My instinct is based on the existing code a few days of hacking at an offsite would come up with something though.

For reference:

chasemp removed a subscriber: chasemp.Mar 3 2015, 7:47 PM
Qgil added a subscriber: chasemp.

It looks like we are closer than I thought on this, so maybe this is not a good Possible-Tech-Projects geared toward GSoC / Outreachy? I mean, not a project that would take @mmodell or @chasemp 2-3 weeks of full-time work.

chasemp triaged this task as Normal priority.Mar 11 2015, 8:51 PM
chasemp set Security to None.
Tarrow added a subscriber: Tarrow.Mar 29 2015, 5:15 PM
scfc added a subscriber: scfc.Apr 8 2015, 12:03 PM
scfc added a comment.Apr 8 2015, 12:18 PM

While developing an extension that connects to Phabricator feels like the obvious (and proven) way to solve this, I would be interested in whether something with Wikidata would be another feasible approach, i. e. replicate Phabricator data as items & Co. to Wikidata and then use general Wikidata functions in wikis. This would have the advantage that the display functions would be general, distributing the burden of review and maintenance on more shoulders, and pave the way for other information nice-to-have on wiki because you no longer need to develop a full-blown extension with security and performance questions arising every time anew, but can just jot down a small data pipe for each information source you want to display on wiki.

mmodell added a comment.EditedApr 10 2015, 7:12 AM

While developing an extension that connects to Phabricator feels like the obvious (and proven) way to solve this, I would be interested in whether something with Wikidata would be another feasible approach, i. e. replicate Phabricator data as items & Co. to Wikidata and then use general Wikidata functions in wikis. This would have the advantage that the display functions would be general, distributing the burden of review and maintenance on more shoulders, and pave the way for other information nice-to-have on wiki because you no longer need to develop a full-blown extension with security and performance questions arising every time anew, but can just jot down a small data pipe for each information source you want to display on wiki.

I'm not very familiar with wikidata but this sounds like it might be a good approach in many ways. Keep in mind, though, maniphest is a large dataset to replicate. I'm not sure the phabricator servers are prepared to handle queries for their entire dataset and the data would need to be keep up to date somehow...

Does wikidata have the ability to plug in raw data sources to be queried or must the entire data set be copied in order to make that work

Right now I think replicating the data over to Wikidata would be a bit pointless :/ There is nothing that cant be done in a small extension that could be done with mirroring the data on Wikidata.
But mirroring the data on Wikidata will require lots more effort, maintenance of 90k items? etc.

scfc added a comment.EditedApr 10 2015, 11:13 AM

Just to clarify: I didn't want to suggest that 90000 tasks are mirrored manually, or that I think this data can be dumped into Wikidata according to current rules. But the purpose of Wikidata is "collecting structured data", and IMHO Phabricator tasks fit that description. As said, MediaWiki extensions are a proven solution for the problem "display something in a wiki", but for each data source it also requires rethinking: "How many requests/s leave server kittens alive? How long is data cached and how is it stored? How is cached data purged? Etc." That's the appeal of an approach like Extension:RSS's that can connect to various data sources with just a single code base. But the nice thing about software is that someone can write a Phabricator MediaWiki extension today without barring someone else from writing a Phabricator Wikidata data pipe tomorrow :-).

@scfc: it's an interesting idea for sure. If there was a way to simply proxy and cache the data rather than dumping/importing then that would seem a lot more practical. The RSS solution sounds closer to on target to me.

Qgil added a comment.Apr 14 2015, 8:56 AM

Like @Addshore and Sylvain, I agree that Wikidata is not the right tool for this -- and I venture to say that Lydia and the Wikidata team will share this opinion. some time ago, I proposed to use Wikidata to handle MediaWiki's catalog of extensions (same idea, each extension would e a Wikidata entry), and the team replied in the same terms as Addshore and Sylvain.

Another thing would be to use the WikiBase extension to basically create a specific Wikidata repository (and open the way to Wikidata federation one day). :) But then I look back at the request of this task and I think... do we really need all this to embed lists of Phabricator objects in wiki pages? Or maybe even the description of a task. Isn't the Conduit API good enough?

Qgil added a comment.May 18 2015, 11:12 AM

It is time to promote Wikimedia-Hackathon-2015 activities in the program (training sessions and meetings) and main wiki page (hacking projects and other ongoing activities). Follow the instructions, please. If you have questions, about this message, ask here.

I cannot drive this alone in Lyon, so I removed the tag.

(I will not participate in Wikimania, but I'm leaving the tag with the hope that someone else is interested in taking over.)

((In fact, I will add Possible-Tech-Projects just in case.))

Qgil added a comment.Jul 3 2015, 10:26 AM

Please confirm and promote this activity by assigning it to its owner, listing it or scheduling it at the Hackathon wiki page and by placing it in the right column at #Wikimania-Hackathon-2015. Thank you!

Qgil added a comment.Jul 7 2015, 1:43 PM

(I will not participate in Wikimania, but I'm leaving the tag with the hope that someone else is interested in taking over.)

It doesn't seem to be the case. Removing the tag.

mmodell moved this task from To Triage to Misc on the Phabricator board.Jul 7 2015, 2:47 PM
Aklapper lowered the priority of this task from Normal to Low.Jul 24 2015, 12:08 PM
Aklapper lowered the priority of this task from Low to Lowest.Aug 29 2015, 10:58 AM
Qgil added a comment.Sep 23 2015, 9:06 AM

This is a message posted to all tasks under "Need Discussion" at Possible-Tech-Projects. Outreachy-Round-11 is around the corner. If you want to propose this task as a featured project idea, we need a clear plan with community support, and two mentors willing to support it.

Qgil added a comment.Sep 23 2015, 9:35 AM

This is a message sent to all Possible-Tech-Projects. The new round of Wikimedia Individual Engagement Grants is open until 29 Sep. For the first time, technical projects are within scope, thanks to the feedback received at Wikimania 2015, before, and after (T105414). If someone is interested in obtaining funds to push this task, this might be a good way.

Hello!
I would like to know more about this project. I think I would like to work on it as a part of @Outreachy11 , once I get an idea of what is expected .
Thanks

@Haritha28: Thanks for your interest! The expectation is covered by the description and comments in this task. :)
Do you have specific questions? As you'd like to "know more", what is unclear and which specific aspects require more information?

Thanks @Aklapper. What all data from the Phabricator should be seen on the wiki pages?

What all data from the Phabricator should be seen on the wiki pages?

That's yet to define I guess... The task description currently says:

lists of tasks based on predefined queries (i.e. open tasks of project X). There might be also an interest in transcluding the content of a task (title, description, metadata) in a wiki page.

I'd recommend looking at an existing extension for a different issue tracking system called "Bugzilla" to get some impression (maybe maybe some code could be reused but I'm not in a position to judge). Though note that Bugzilla has some fields or criteria (like "Severity" or "Version") which do not exist in Phabricator. Bugzilla's "product", "component" and "keywords" are all just "projects" in Phabricator.
However, a task in Phabricator also has an ID, priority, summary/title, assignee, status.

Any such future extension should use Phabricator's Conduit API to query Phabricator I'd say.

Haritha28 added a comment.EditedOct 2 2015, 4:30 AM

Thanks @Aklapper . I would like know who are the mentors for this particular project.

I would like know who are the mentors for this particular project.

I'm afraid that I don't know if there are any. I looked at https://www.mediawiki.org/wiki/Outreachy/Round_11#Possible_mentors but apart from asking in a task it does not has any recommendations. You could ask on IRC in #mediawiki-dev or on the wikitech-l mailing list if anyone could imagine mentoring.

Qgil added a comment.Oct 2 2015, 10:21 AM

The main use cases would be

  • Queries of Maniphest tasks to be inserted in wiki pages of projects or other technical spaces to inform editors.
  • Queries of Calendar entries to replace our cumbersome on-wiki calendars (T1035)

About mentors, this project probably requires a mentor familiar with MediaWiki extensions, more than a mentor familiar with Phabricator. We don't have any yet...

Qgil updated the task description. (Show Details)Oct 7 2015, 7:48 PM
ZaBien added a subscriber: ZaBien.Nov 3 2015, 10:31 PM
ZaBien removed a subscriber: ZaBien.Nov 18 2015, 1:09 PM
Kc5vcx added a subscriber: Kc5vcx.Feb 22 2016, 2:21 AM
Sumit added a subscriber: Sumit.Mar 1 2016, 5:37 PM
IMPORTANT: This is a message posted to all tasks under "Need Discussion" at Possible-Tech-Projects. Wikimedia has been accepted as a mentor organization for GSoC '16. If you want to propose this task as a featured project idea, we need a clear plan with community support, and two mentors willing to support it.
Qgil added a comment.Mar 2 2016, 10:28 AM

As the person to proposed this task back in the day, I wonder whether there is enough interest. I'm tempted of removing the Possible-Tech-Projects tag for now.

(The idea of including lists of tasks in wiki pages feels a tad archaïc to me nowadays, given the existence of workboards.)

Qgil closed this task as Declined.Mar 2 2016, 11:07 AM

OK, I think more people could agree on this. There might be a point about better integration of Calendar data, but this is quite far fetched as of today and it would need first a decision on T1035: Consolidate the many tech events calendars in Phabricator's calendar.

Declining. If someone has ideas and the energy, feel free to reopen.