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 raised the priority of this task from to Needs Triage.
Qgil updated the task description. (Show Details)
Qgil subscribed.

@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?

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:

mwbzdash.jpg (383×672 px, 116 KB)

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 set Security to None.

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.

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.

Just to clarify: I didn't want to suggest that 95000 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.

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?

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

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!

(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.

Aklapper lowered the priority of this task from Medium 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

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.

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.

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.

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...

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.

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

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.

Just Fyi. I found myself wanting to embed a phabricator search in a wiki page too.