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:
- 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.
- 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)
- With the issue templates, you'd be off to a good start with this. We're worried about the complexity this can introduce. To discuss custom, required fields, see: #8988 (closed)
- 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
- This is a great idea, we're hoping to creating warnings like in Slack: #9000 (closed)
- View notifications without marking them as read
- #2425 (closed) We intend to do this with 8.5
- Allow disabling automatically marking them as read, so they have to be manually marked as read.
- we only distinguish between handled or not in our notification center #2425 (closed)
- 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 handle(semantics not decided on), which would allow you to do this.
- With our new notification center, you can manually toggle things as
- Turn unintuitive search query system into GUI
- We're working hard to improve search with several initiatives, such as: #5885 (closed). We're welcoming further suggestions
- 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
- This is a good idea that we're interested in doing: #9009 (closed)
- Select multiple issues and then close with a single comment
- Good idea, we're exploring it here: #9010
- Ability to merge issues
- We're exploring the idea of distributed issues, this would allow you to do these things #4084. Maybe we can start with a minimal merging system.
- Ability to move issues to other repos
- scheduled for 8.5 #3024 (closed)
- 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
- GitLab has a voting system that is made in part for this purpose. We're expanding this with easier sorting and filtering based on votes. #3763 (closed)
- 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.
- We're doing this: #3763 (closed)
- Add support for custom reply messages (e.g. “Can’t reproduce...”, “Please attach a test case...”, “Please use forum for questions...”, etc.)
- It's not entirely clear what this would entail. Many of our service engineers use TextExpander for quick replies. Issue to discuss this: #9022 (closed)
- 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.”)
- You can do this with issue templates gitlab-ee!28 (merged)
- Better tools for addressing tracker spam comments/issues
- This is something we're working hard on, as we're facing this problem ourselves. Please see the issues with the spam fighting label
- 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.
- GitLab has a different hierarchy, but this is not a bad idea to do for groups #9012
- 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.
- We're going to do this, it makes sense #9014 (closed)
- 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.
- This would be great with an automation, as discussed here: #9058
- 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.
- We're exploring this idea here: #9062
- Allow automation rules, such as automatically notifying or closing when issues have been untouched for a long time.
- This is not possible yet, but we're exploring the possibilities here: #9058
- 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.
- exploring this in this issue #8939