Page MenuHomePhabricator

GitLab Issues experiment with Research
Closed, ResolvedPublic

Description

Research maintains a lot of code on GitHub (they have their own GitHub team).

Hosting all our code in one place is desirable:

  • Makes code searching easier
  • Gives us a full picture of our code
  • Canonical entry-point into our software

Ideally we'd be able to support the needs of Wikimedia-related code with our in-house hosted infrastructure. Moving projects from GitHub into GitLab was one of the reasons we decided to explore GitLab in the first place.


Research finds value in GitHub's Issues, and would like to use them in GitLab. Issues and wikis are turned off for repos on our GitLab instance. I've left issues on for the repos/research subgroup so they can experiment with Issues.

Just as hosting all our code in one place is desirable, keeping all our tasks in one place is desirable. As part of this experiment I've asked Research to keep track of how they’re using issues to answer the following questions:

  • Is GitLab's issue feature comparable to GitHub's issue feature? Is there anything preventing you from fully migrating from GitHub to GitLab?
  • What does GitLab issues provide that is not provided in our Phabricator?
  • What types of tasks are tracked via Research vs what is tracked in GitLab?
  • What effect does GitLab hosting have on collaboration outside your team?

Details

Due Date
Aug 31 2023, 6:00 AM

Event Timeline

thcipriani triaged this task as Medium priority.
leila moved this task from Backlog to In Progress on the Research board.

@thcipriani (context: I'm reviewing tasks in the Research Phabricator board):

  • FYI: I'm going to move this to Research - Backlog lane as we're not actively working on it at this point.
  • I imagine this is something still helpful for your team to have some feedback on. Can you let us know if the 4 questions (in bullet-point) in the task description are still the questions you want us to answer? If not, can you update the questions, please.
  • Also, please let me know if the task is not relevant for you and we should decline on our end. I understand you may already know a lot more from other places by now. : )

A couple observations:

  • while initially I liked the idea of using gitlab issues to track work, in practice isn't convenient if the planning/tracking is mostly done it other tools / outside gitlab. In addition, the research team has updated our phabricator process/workboards etc - using gitlab issues only makes things more convoluted
  • one exception to the above: research has used gitlab issues for tracking specific self-contained projects like outreachy internships (example: https://gitlab.wikimedia.org/repos/research/html-dumps/-/issues). If the tasks are not connected to work done in other teams (like most regular research projects do), having a place to track issues with code integration (like gitlab issues do) is nice feature to make use of.

My suggestion: keep the option to enable gitlab issues for special use cases like self-contained internships / external academic collaborations, but don't encourage using gitlab issues instead of phabricator for planning cross-team projects.

I am closing this as resolved, of course feel free to reopen to continue the discussion.