Requests for comment/Phabricator
| Phabricator | |
|---|---|
| Component | General |
| Creation date | 2014-03-28 |
| Author(s) | Andre Klapper, Guillaume Paumier |
| Document status | early draft |
 | This page is currently a draft. More information and discussion about changes to this draft on the talk page. |
Contents
Problem
The Wikimedia technical community is currently using plenty of different tools for tracking bugs / product management / project management / todo lists. Some are open-source and others are proprietary, some are self-hosted and others are hosted by third parties, and all in all the multitude of tools and channels makes it difficult for both staff and volunteers to keep track of what's happening. They also all have their own limitations, and the multitude of scattered tools involved in the development chain is cumbersome both for current and prospective contributors. Members of the development and user communities have expressed frustration due to the current state and wish to consolidate the development toolchain.
See the full email thread for more background.
Background
This is what has been done so far:
- People have shared their needs and workflows.
- Andre and Guillaume have summarized all of that into consolidated requirements.
- Andre and Guillaume have set up a list of options to solve our problem, based on what was mentioned during preliminary discussions.
- People hade discussed the options and eliminated some of them in preparation for the RfC.
- Besides the wiki, communication has happened mainly on the teampractices list, with updates also sent to wikitech-l.
- We're now drafting this RfC and welcoming edits on both the form and the content.
Proposals
The goal of this RfC is to come to an agreement as a community on a smaller set of tools that teams would agree upon, which would make collaboration and maintenance easier. Ideally, this would also be an opportunity to use tools that are better aligned with the values of our movement, and better integrated with each other. Because the goal is open-ended, the discussion will consist of several proposals. Each is flexible: the details can be discussed as well. If you add other proposals or sub-proposals, please number them consistently with the current scheme.
Proposal A: Keep the Status Quo
Proposal A0: Status Quo and Reevaluate in a Year
This option consists of changing nothing to the current situation. We'll still have a multitude of tools scattered along our development toolchain. The status quo is somewhat working at the moment, so if there isn't a better alternative we can decide to keep what we have now and reevaluate every year.
Proposal A1: Status Quo + Fulcrum
- There is no Fulcrum instance available for testing yet.
This option consists of adding one tool to the current situation. We'll keep Gerrit, Bugzilla, etc. but we'll also have a Fulcrum installation that will be the default platform for project management. It will have the same level of support and maintenance as other services like Bugzilla or Mailman. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Fulcrum will be the one supported by the WMF.
Proposal A2: Status Quo + Scrumbugz
- Wikimedia Deutschland uses a live version of Scrumbugz that you can look at. It is not a test instance so please look but don't touch.
This option consists of adding one tool to the current situation. We'll keep Gerrit, Bugzilla, etc. but we'll also have a Scrumbugz installation that will be the default platform for project management. It will have the same level of support and maintenance as other services like Bugzilla or Mailman. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Scrumbugz will be the one supported by the WMF. Scrumbugz provides a project management tool (agile reporting) that works on top of Bugzilla.
Proposal B: Move to Phabricator
- You can test Phabricator in Labs. This is an actual test instance so don't be afraid to break things
Proposal B0: Phabricator for All The Things
This option consists of replacing several of our tools by one consolidated tool. Phabricator will replace gitblit, Gerrit, Jenkins, Bugzilla, RT, Trello and Mingle. We should probably turn off Phriction, the Phabricator wiki, to avoid fragmenting with MediaWiki.org. Development teams will be free to use other tools (like Trello, Mingle, etc.) but Phabricator will be the one supported by the WMF.
Blockers
In order to complete a full migration to Phabricator, the following needs to happen:
- Set up repositories, projects, permissions, etc.
- Migrate all tickets from Bugzilla and set up redirects
- We are not aware of any precedents of importing Bugzilla tickets into Phabricator (upstream ticket). Phabricator has an API ("Conduit"); Bugzilla has XML and JSON interfaces.
- Migrate all tickets from RT and set up redirects
- Migrate code review data from Gerrit
The following is optional and depends on the needs of smaller teams:
- Migrate data from Mingle
- Migrate data from Trello
Known Functionality Regressions
- Phabricator does not offer a list of existing projects to users who file a ticket; currently only type-ahead guessing (upstream ticket) so triagers would have more work.
Proposal B1: Piecemeal Phabricator
Phabricator ships with many applications that can be configured and enabled independently. For example, it can use external Git repositories instead of managing those itself. If there's part of Phabricator we don't like, we can disable it. This means maintaining another tool, though, and possibly needing to keep another set of login credentials if the tool is user-facing.
Proposal C: Move to GitLab
- You can test GitLab on their demo server.
GitLab is an open-source GitHub clone that would replace gitblit, Gerrit, jenkins, Bugzilla and RT. It doesn't offer a project management tool and it is still left to sort out how agile tools (Trello, Mingle) would interact with GitLab.
General Migration, Tradeoffs, Timeframe
In case we decide to change the current setup:
- For any important functionality we miss in a new tool, Andre should make sure that upstream tickets are created to make upstream developers aware of our needs.
- Wikimedia's participation level: Should Wikimedia wait for somebody to develop the functionality we still miss, or will Wikimedia actively work on fixing it? The latter will require developer resources, either from WMF teams or a contractor.
Potential sequences of migration:
- M1: Speed: We could push to quickly have the new tool in place, given the limitations of our existing tools, and afterwards add missing functionality that we consider a requirement.
- M2: Functional completeness: We could first make the prefered new tool provide nearly all functionality we consider required, and then migrate to the new tool.
- M3: Later migration of tickets: We could start a fresh instance of the new tool with a higher number (100.000) to give us enough buffer to import Bugzilla and/or other tickets at a later date. We close existing infrastructure tools for ticket creation so new tickets are only handled in the new tool.
- In any case, we should not add yet another tool to the mix while keeping the current usage of all our existing tools.
Aspects to keep in mind for a migration of tickets: Tickets themselves, Attachments, Access restrictions, Priorities, Assignees, User accounts and their passwords. Mapping products, components, keywords.
