Skip to content

Making GitLab the best place for big open source projects

These are the criticisms of the current leading platform for big open source projects.

For our response to the main item please see https://about.gitlab.com/2016/01/15/making-gitlab-better-for-large-open-source-projects/

Please help me link to existing issues and create new where necessary:

Frustrations

  • Issue management and notifications do not scale for larger projects, they are overwhelming and it actively contributes to burnout of open source maintainers.
    • See the improvements below of concrete actions we're taking. At GitLab we use our own issue track for all development and feedback. We're constantly looking to improve this, if only if it's to improve our own situation. This is an absolute priority for us.
  • No validation that any part of CONTRIBUTING.md has been adhered to before an issue is created
    • With issue templates, the link to CONTRIBUTING.md from the issue form and us exploring further options, this is something we should be able to handle.
  • Auto subscribing users when they get mentioned. This encourages random users to mention maintainers in issues wanting direct support leading to a lot of email noise.
    • In GitLab you can set your notification level to 'Mention', which will only notify you on explicit mentions and not subscribe you to subsequent updates.
  • The existing pull request workflow and green “Merge” button encourage merge commits, which many larger projects do not allow.
    • In GitLab we support rebase and fast-forward merges.
  • Excessive comment noise due to +1s and other nonsense interactions
    • This is solved by GitLab's voting system.
  • People adding “famous” people as contributor for fun to their projects, creating frustration for them and spam in the activity stream.
    • This is a problem we have not yet encountered on GitLab.com. We are interested in looking to mitigate this problem if it comes up.

Improvements

  • Allow custom fields in issues (e.g. library version, language version, operating system)
  • Make fields required (e.g. library version or link to a test case; making such information mandatory would dramatically reduce noise)
  • Show contributing guidelines before opening an issue (yet another noise reduction)
    • We currently have this in the form when you open an issue
  • Show count of how many people will be notified next to the issue creation button
  • View notifications without marking them as read
  • Allow disabling automatically marking them as read, so they have to be manually marked as read.
  • Flag notifications or issues for future follow up (i.e. create a personal/private flag)
    • With our new notification center, you can manually toggle things as To do / To handle (semantics not decided on), which would allow you to do this.
  • Turn unintuitive search query system into GUI
  • Auto-search for "similar issues" based on the words in the issue title and body when the issue is created, to prevent dups - similar to how Stack Overflow already works
  • Select multiple issues and then close with a single comment
  • Ability to merge issues
  • Ability to move issues to other repos
  • Explicitly eliminate content-free replies like "+1", or convert them into a rating system for issues so watchers aren't constantly notified! A separate rating system would be nice too.
    • This is part of our voting system that comes out of the box with GitLab.
  • Voting system for proposals
  • Something that surfaces votes at an issue-viewing level that can be sorted easily by counts/labels. This allows distilling the highest priority bits to work on.
  • Add support for custom reply messages (e.g. “Can’t reproduce...”, “Please attach a test case...”, “Please use forum for questions...”, etc.)
  • Add support for default placeholder message when opening an issue (similar to what Google Code did — “What steps would reproduce a problem? … Expected result: … Actual result: … etc.”)
  • Better tools for addressing tracker spam comments/issues
  • Don’t make it so easy to submit bad PRs → For example, remove the default commit title when creating a commit from the GitHub UI. When I see “Update readme.md”, I know I’m in for annoyance.
    • We want to make it very easy to create PRs and MRs. We believe in using CI and many of the tools we've listed above to reduce the probability of creating a bad PR. Autocomplete and suggested forms make working with GitLab faster, so we're not inclined to remove such features, as their absence does not automatically imply better quality PRs.
  • Ability to block users from an organization.
  • Allow assigning issues to anyone who has contributed to the issue, not just project maintainers. This way issues can be assigned back to the OP when more info is needed.
  • Support explicitly marking an issue/pull request as “Needs Revision”/”Needs More Info” and then have the tag automatically removed once someone comments on the issue/updates the code in the pull request.
  • Support “private labels” for issues. Users should be able to add private labels to any issue, even if it’s a project they don’t maintain. They should then be able to use them for querying/filtering.
  • Allow automation rules, such as automatically notifying or closing when issues have been untouched for a long time.
  • Support linear histories in the big green merge button. The project maintainer should be able to specify whether merge commits should be created, or the change should be rebased on top of master.
  • Support the ability to change the target branch in a PR without having to close and reopen a new one -- This way you do not have to lose the comments and discussion that may have happened in the original PR
    • this is something that has been possible in GitLab for a long time.
  • Allow more than one format for reviewing issues. For example, displaying all issues within a spreadsheet format, sortable by columns.