We have been using Launchpad for several years for bug/feature request tracking and managing our translations. Separately, we have been using Gitolite and Gitweb to manage our Git repositories. However, some dissatisfaction has been building up over the years, and during the hackfest at the 2017 EIC, we decided to start exploring alternatives.

• Series and milestone targeting of bugs.
  • Particularly helpful for tracking whether a bugfix has been backported to a maintenance branch
• It's fairly easy for non-technical folks to create an account, create a bug, add a comment, or follow along with the comments.
• The ability to filter bug mail subscriptions by tag, importance or status is handy for those who don't want to subscribe to all bugs, but want to only subscribe to those that fit a certain criteria (e.g. documentation).
• The community has utilized the ability to tag fairly well, using it to organize the bugs into categories or use them to convey information about the need for tests, the need for release notes, etc. If we move to another system, we need to ensure all of that information isn't lost and that we can somehow migrate that information to the new system.

• UI supplies no way to batch-edit bugs
• The API is hard to use, particularly for command-line applications
• LP has timeout errors rather more often than one would like
• No direct links from the bugs to the commits fixing them (or viceversa, i.e a "fix bug 123" commit message links LP123 with that branch).
• Bug search is limited, even with advanced search. Most effective way to search is to start opening a new bug.
• There's no way to edit, delete, or suppress a comment, which is a problem if somebody has inadvertently left in patron or a description of a security exploit.
• There's no way to update a bug without triggering an email, which is a problem for batch updates.

• https://github.com/Kickball/awesome-selfhosted#project-management

• It is easy to control access to branches and directories
• The working repository contains nearly all submitted changes; no need to juggle a lot of remotes.

• Keys for new users must be added manually, adding a bit of friction to the process.
• Similarly, human intervention is required whenever a user has new or updated keys.
• No direct links from commits to the bugs describing them.

• Some (many? all?) translators find the UI easy to use.

• It requires bzr when nothing else in our workflow does.
• The promise of grabbing translations from other projects hosted on LP has not really panned out.

• Interface for reporting bugs should be easy for non-technical folks to use
• Can import bug history, including comments
• Can import existing PO and POT files

• Has the ability to host a private repo for the security team. (If not, we could keep using Gitolite for that)
• Ability to find and retrieve bugs by their old LP number
• Ability to migrate categorizations used in our tagging system to whatever categorization system is used in the replacement.

• Ability to report or comment on bugs without requiring a user account
• Better reporting of statistics than is currently available via Launchpad API

Options for transitioning from Launchpad to Github: https://lp2gh.readthedocs.io/en/latest/moving_issues.html?highlight=import

• Defacto standard site for many projects.
• Already being used by DIG for gists.
• "Everyone" has a GitHub account.
• We can create a nonprofit organization that allows us to have unlimited users and private repositories once our 501c3 status is finalized.

• Offers no integrated i18n/l10n tools
• Private repos are not free (as in beer).
• Not F/OSS itself, so we can't host it ourselves if desired.
• Antisocial Coding: My Year At GitHub
• Will necessitate changes in workflow, particularly as regards working repositories. (This could be a good thing!)
• GitHub starts blocking developers in countries facing US trade sanctions
• GitHub is social control
• SFC Gives Up on Github
• It is a "bad look" for a F/OSS project to use proprietary hosting solutions.

• We can host it ourselves or host at gitlab.com
• Includes GitLab CI so we could retire both buildbot + current live testing with full Docker-based CI
• Anyone can sign up without administrator intervention.
• Users can be in groups that can all access the same repos.
• Has lots of plugins and applications that could add some of the "missing features."
• Can integrate with LDAP for community sign-on.

• Offers no integrated i18n/l11n tools
• It won't accept a push of an Evergreen repo because of https://gitlab.com/gitlab-org/gitlab-ce/issues/22095
  • While annoying, this is due to inconsistencies within the Evergreen repo's git history, and can be mitigated: by editing the global git config on the GitLab server, you can change the detection of zero-padded file modes from a fatal error to a warning, or ignore them altogether. A method of ensuring that the that particular configuration setting was not overwritten at GitLab upgrade time might also be necessary. (The configuration change has remained in place through 2 upgrades on a test installation.)
• We don't have as much control over branch permissions as gitolite offers. This likely means we'll lose the working repository in favor of individual developer repositories. (Note: gitlab used to be based on gitolite but is no longer.)
• Recommends 2 cores and 4GB of RAM for up to 100 users. Dyrcona found this to be slow with less than 10 users in testing.
• Anyone with an account can create their own projects/repositories. We're gonna need a lot more disk space.
• To get many of the best features, we would need a license for the Enterprise Edition. (See https://about.gitlab.com/pricing/#self-managed). This would cost the community $6,000/year for 125 users. (That number is based on the number of user keys in the gitolite configuraiton.)
• A self-managed/self-hosted solution would still require some administrator overhead, perhaps as much as gitolite.
• Going with the community edition will necessitate work flow changes, particularly as regards working repositories. (This could be a good thing!)
• Using dual-licensed products with a full feature proprietary release and less powerful free release is a bad look for a F/OSS project.

• We could add what we want without fundamentally changing existing workflows on ourselves

• It would be a lot of work

https://gogs.io

• Ridiculously easy to set up
• GitHub-like features/interface

• May not be robust enough for bug tracking

Atlassian products are free for open-source use on application to them: https://www.atlassian.com/software/views/open-source-license-request This is used by FOLIO project

• Very feature rich, JIRA for bug tracking is an industry standard tool
• Can be self-hosted

• Not open-source

If we move to a bug tracking / repository tool that does not include translation support (and most alternatives do not), then we need to consider what we would like to do for translations.

https://poeditor.com/

• F/OSS: We can (must?) host it ourselves.
• Support XLIFF files – used by Angular2 native i18n

• Offers no integrated bug reporting and repository management tools

• F/OSS: We can host it ourselves, or use the free (for open source projects) hosted version

• "Zanata's command-line client is easily integrated into scripts and used in continuous integration. […] Zanata also has a REST API for scripting and integration with other tools." sounds promising for integration, but remains to be seen. For example http://docs.zanata.org/en/release/user-guide/documents/upload-documents/ looks painfully manual for uploading individual files for a given release, until you scroll to the end and see there is a CLI option: "See Zanata-Client push command for more information."
• Does anyone have any experience with this?

https://weblate.org/en/

• F/OSS: We can host it ourselves, use the free hosted version (for free software projects, requires discussion with hosts), or pay for a hosted version
• Support XLIFF files – used by Angular2 native i18n

• Does anyone have any experience with this?

If we continue with self-hosted systems, it might be really nice to be able to centralize our authentication so that people could just use a single "Evergreen community account" that would work for the bug tracker, wiki, translation, blog, version control, etc. Most of the self-hosted systems at least offer LDAP, so if we were to add an LDAP server to the mix we could manage authentication and authorization centrally…