This page is a translated version of the page Phabricator/Code and the translation is 59% complete.
Outdated translations are marked like this.

本文档描述了维基媒体的Phabricator实例的开发过程。Phabricator是用PHP,编写的,就像MediaWiki一样,它应该有助于入手开发。 在本文档中,我们将首先了解维基媒体如何使用Phabricator,以及在开发过程中会发生什么。 之后,有一些关于如何开始实际开发的注意事项。


维基媒体使用上游的变化很小的Phabricator实例。这样做的是因为上游开发人员的高速开发使得维护本地补丁非常麻烦。 对此的例外是扩展,它们位于单独的存储库中,因此不需要定期合并。 因此,任何其他变化都必须通过上游。这听起来像是一个主要障碍,但在实践中,上游维护人员非常迅速地回应建议。

维基媒体Phabricator bug工作流程

在完成其中一项任务之前,了解错误的生命周期很有帮助。这里有两个项目: #phabricator用于WMF特定的错误和 #phabricator-upstream用于一般的Phabricator错误。软件错误和增强请求通常属于第二类。


  • 积压:这是新任务默认登陆的地方。 停滞的任务也可以在这里找到。
  • 需要讨论:有时一项任务将受益于讨论,确保更多的维基媒体贡献者在同一页面上,并且报告或提案都有充分论证。
  • 准备就绪:此列中的任务正在等待某人将其复制到错误跟踪器
  • Upstreamed: this column is where tasks are moved as soon as they have been reported upstream.
  • 维基媒体请求:上游报告的一些请求是以维基媒体名称制作的,并标有#wikimedia标记,因为我们认为它们具有更高的相关性。

一旦任务被分发到上流,上游开发人员就会对他们的评估做出回应,并就如何实施该功能提出建议。 此时,开发人员可以开始部署。

在某些情况下,上游开发人员将决定某项功能不适合他们的计划。 在这种情况下,Wikimedia Phabricator中的任务从#phabricator-upstream项目转移到#phabricator项目,最终回到讨论阶段:这个功能是否足以维护本地补丁? 一旦确定,补丁将转移到“准备就绪”,并且可以开始部署。


How fast a task is reported upstream may depend of how uncontroversial is (going through the Need Discussion column) and how high is its priority, but it ultimately depends on who takes the time to report it upstream. This is an opt-in process aimed to check the appropriateness and relevance of a task before being created upstream. Anyone with permissions in upstream can create tasks upstream bypassing this process, however, before submitting an upstream task, please read Introduction to contributing to Phabricator, Arcanist and libphutil.


As mentioned in the previous section, we try to keep local patches to a minimum. There are limited resources available to maintain patches, and to merge them with changes from upstream. Any local patches therefore have to be discussed within the #phabricator project. It's significantly less work to maintain a phabricator extension, as long as care is taken in avoiding the use of particularly new / unstable APIs from phabricator's core. Although extensions don't require merging and potential code conflicts, they do require testing each time we pull in upstream changes. Phabricator does not have any frozen APIs which are deemed safe to depend on. At this time we have virtually no modifications to the phabricator core, except for changing the favicon.ico to use Wikimedia colors.

The current code of the Wikimedia Phabricator instance itself:



Most of the configuration is set through the web interface. Defaults (shared between and e.g. are set using the puppet maniphest.


The easiest way to get set up is by using MediaWiki-Vagrant using the 'phabricator' role. Follow the steps on MediaWiki-Vagrant to install MediaWiki-Vagrant, then enable the phabricator role using

vagrant roles enable phabricator --provision
  • Access the Phabricator instance at URL:

  • The Phabricator install is located in `/srv/phabricator/` (?) on the VM. To edit and submit a patch:
cd /srv/phabricator/
# 编辑你任何你想编辑的

# 然后,如果您准备提交补丁:
git config --global ...
git config --global ...
git commit all the things
arc diff # 并按照说明进行操作,包括安装arc证书


使用Labs VM

If you know how to spin up a VM on Cloud VPS, and have the rights to do so, you can create an instance with the `phabricator::labs` role. This should give you a basic setup with the same configuration as

Migration code from Bugzilla, RT, Mingle, Trello to Phabricator

The scripts that Wikimedia used for migrating its Bugzilla and RT data to Phabricator are available. Note that the migration code is not bug-free and that it was only written and used for the specific configurations of Wikimedia's tools. Also note other migration scripts, e.g. the GStreamer project used a phill script by Emanuele Aina to import their data from Bugzilla into Phabricator in 2015.

Data was migrated from Mingle to Phabricator via a script available in phab:P129.

The scripts to migrate data from Trello to Phabricator are available. 有关更多信息,请参阅phab:T821