Phabricator/Code/pt-br

Este documento descreve o processo de desenvolvimento para a instância do Phabricator da Wikimedia. O Phabricator é escrito em PHP, exatamente como o MediaWiki, o que pode ajudar na iniciação ao desenvolvimento. Neste documento, primeiramente veremos como a Wikimedia está usando o Phabricator e o que esperar durante o desenvolvimento. Em seguida, há algumas notas sobre como começar com o desenvolvimento real.

Phabricator no Wikimedia
A Wikimedia usa uma instância do Phabricator com alterações mínimas da versão do autor. A razão para isso é o ritmo alto de desenvolvimento dos desenvolvedores originais – a manutenção de correções locais é complicado. As exceções são as extensões, que ficam em um diretório separado e, portanto, não precisam de fusões regulares. Quaisquer outras alterações, assim, têm de passar pela versão do autor. Isso soa como um grande obstáculo, mas, na prática, os mantenedores estão prontos para responder a sugestões.

Fluxo de trabalho de bugs no Wikimedia Phabricator
É útil para entender o ciclo de vida de um bug antes de assumir uma das tarefas. Existem dois projetos: #phabricator para bugs específicos da Wikimedia Foundation e #phabricator-upstream para bugs gerais do Phabricator. Bugs de software e pedidos de melhorias normalmente recaem nesta segunda categoria.

The Phabricator-upstream workboard shows the process that tasks go through before being created upstream:


 * Backlog: this is where new tasks land by default. Stalled tasks can also be found here.
 * Need discussion: sometimes a task will benefit from a discussion, making sure that more Wikimedia contributors are on the same page and the report or the proposal are well argumented.
 * Ready to go: tasks in this column are waiting for someone to copy them to the upstream bug tracker.
 * Upstreamed: this column is where tasks are moved as soon as they have been reported upstream.
 * Wikimedia requests: a few requests reported upstream are made in the name of Wikimedia and get marked with the #wikimedia tag, because we consider that they have a higher relevance.


 * Solved upstream: ???.

Once a task has been upstreamed, upstream developers respond with their assessment, and suggestions for how the feature should be implemented. At this point a developer can start with the implementation.

In some cases, the upstream developers will decide a feature does not fit into their plans. In this case, the task in Wikimedia Phabricator is moved from the #phabricator-upstream project to the #phabricator project, and ends up back into the discussion stage: is this feature important enough to maintain local patches? Once this has been decided, the patch will move to 'Ready to go', and one can start with the implementation.

To prevent disappointment, please do not start with the implementation until it's clear either upstream or the WMF maintainers will accept your patch.

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. You can also do it!

This is an opt-in process aimed to check the appropriateness and relevance of a task before being created upstream. Anyone can create tasks upstream bypassing this process, however, before submitting an upstream task, please read Introduction to contributing to Phabricator, Arcanist and libphutil.

Mudanças locais
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 is a very fast moving project and they don't have any frozen APIs which are deemed safe to depend on. At this time we have virtually no modifications to the phabricator core, with the exception of changing the favicon.ico to use Wikimedia colors.

The current locally-maintained extensions are:
 * The MediaWiki OAuth extension (Not upstreamed; see the Differential revisions and commits at https://secure.phabricator.com/T5096).
 * Security extension (Wikimedia's specific development while upstream implements their solution for private projects).
 * MediaWiki Userpage field
 * Sprint extension

There is also a set of custom scripts to generate Phabricator-derived visual reports. They are not part of the Wikimedia Phabricator production codebase and maintained by the Team Practices Group. See Phlogiston for more information.

Configuração do site
Most of the configuration is set through the web interface. Defaults (shared between https://phabricator.wikimedia.org and e.g. https://phab.wmflabs.org) are set using the puppet maniphest.

Configurando
A maneira mais fácil de se configurar é usando o Vagrant. Seguir esses passos deve ajudá-lo a começar:


 * The Phabricator install is located in `/srv/phabricator/` (?) on the VM. To edit and submit a patch:

Parabéns, você enviou sua primeira correção!

Usando uma máquina virtual do Labs
If you know how to spin up a VM on Labs, 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 https://phab.wmflabs.org.

Código de migração do Bugzilla/RT para o Phabricator
Os scripts que a Wikimedia utilizou para migrar os dados do Bugzilla e do RT estão disponíveis. Note que o código de migração não está livre de bugs e que foi escrito e utilizado apenas para as configurações específicas das ferramentas da Wikimedia.

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

The scripts to migrate data from Trello to Phabricator are available. See T821 for more information.