Dear open source maintainers,
We want GitLab to be the best place for any software project,
whether open source or not, whether big or small.
The letter of GitHub's open source community
is clearly not addressed to us,
but we're thinking a lot about the issues that were mentioned in it.
We see many of these things happening and have been working on them for a long time,
not in the least because we develop on a busy public issue tracker ourselves.
Here we would like to share our thoughts about these issues and
what we’re planning to do to make things better with GitLab.
Issues are often filed missing crucial information like reproduction steps or version tested.
We’d like issues to gain custom fields, along with a mechanism (such as a mandatory issue template,
perhaps powered by a newissue.md in root as a likely-simple solution) for ensuring they are filled out in every issue.
In GitLab you can set a template for an issue and for a merge request.
We're also planning to add multiple templates,
that you can use depending on the reason for making an issue.
We're also interested in exploring
custom (required) fields.
new_issue.md file for templates is a nice idea, that we're happy
to discuss in this issue.
Issues often accumulate content-less “+1” comments which serve only to spam the
maintainers and any others subscribed to the issue.
These +1s serve a valuable function in letting maintainers know how widespread an issue is,
but their drawbacks are too great. We’d like issues to gain a first-class voting system,
and for content-less comments like “+1” or “:+1:” or “me too” to trigger a warning
and instructions on how to use the voting mechanism.
GitLab currently has a voting system that automatically transforms
a vote. As we use GitLab ourselves for issue tracking and feature voting,
this is something that has a high priority for us.
We've also planned several improvements to votes
and welcome more ideas and merge requests.
Issues and pull requests are often created without any adherence to the
CONTRIBUTING.md contribution guidelines, due to the inconspicuous nature of
the “guidelines for contributing” link when creating an issue and the fact that
it often contains a lot of information that isn’t relevant to opening issues
(such as information about hacking on the project). Maintainers should be able
to configure a file in the repo (interpreted as GFM) to be displayed at the top
of the new issue / PR page instead of that link. Maintainers can choose to inline
content there and / or link to other pages as appropriate.
Currently, we provide links to
CONTRIBUTING.md whenever you create an
issue or merge request. At the moment you can also leverage the issue
template to point people to specific rules.
We're interested in adding a custom contributing file on top of issues in GitLab.
Responses to specific suggestions
The original letter also included a long list of suggestions.
To see our response to every single point, please view
this issue on GitLab.com.
One issue that was raised several times was the ability to not create
merge commits. In GitLab.com and EE you can, as an alternative to the merge commits,
use fast-forward merges
or have merge requests be automatically rebased.
How we all build GitLab
Everyone is free to comment, create new issues, vote on, and
contribute to the development
of GitLab. We have short- and long-term goals, all of which are visible on the
issues of the repositories and on the direction page on the website.
If you want to change something, create an issue or submit a merge request.
You can choose to implement something yourself, or ask someone else to do it.
Great ideas will always get the attention they need.