kivikakk: gitlab backend maintainer
Manager Justification
It's hard to specify hard requirements for becoming a maintainer, which is why the documentation consists of flexible guidelines. Reviewers are encouraged to think of their eligibility for maintainership in the terms of "I could be ready at any time to be a maintainer as long as my work as an author and reviewer is consistent with other maintainers".
- The MRs reviewed by the candidate consistently make it through maintainer review without significant additionally required changes.
- The MRs authored by the candidate consistently make it through reviewer and maintainer review without significant required changes.
...justification...
Some suggested MRs from @kivikakk from the last month or two:
- Replace lang with data-lang in Rouge and AsciiDoc (gitlab-org/gitlab!224238 - merged) (highly security sensitive and important to get right)
- Dependency firewall - vulnerability rule evaluator (gitlab-org/gitlab!232708 - merged)
- Wire `author_source` into `completed_pipeline_e... (gitlab-org/gitlab!236776 - merged)
- Allow URL import into groups when personal proj... (gitlab-org/gitlab!237114 - merged)
- Improve lock contention for groups and projects... (gitlab-org/gitlab!235345 - merged)
- Fix snippet heading anchors always scrolling to... (gitlab-org/gitlab!242817 - merged)
- Fix broken XHTML in Atom feed for notes with li... (gitlab-org/gitlab!228411 - merged)
- Fix heading anchor links opening in a new tab f... (gitlab-org/gitlab!239519 - merged)
- Support checkbox rendering for org-mode (gitlab-org/gitlab!240908 - merged)
- Batch deployment commit lookups in GraphQL (gitlab-org/gitlab!241372 - merged)
- Pushbacks leading to MR closure:
Before Merging (Manager Tasks)
- Close any relevant trainee maintainer issues with a comment indicating that this merge request is being created, as (they are no longer required to become a maintainer).
- Mention the maintainers from the given specialty with the template below and ask them to provide feedback to the manager directly. Emphasize that any negative feedback should be communicated privately to the manager/mentor, not in the merge request, as outlined in our maintainership feedback documentation.
- Leave this merge request open for 1 week, to give the maintainers time to provide feedback.
- Check this box to confirm that you approve the access provision.
- Ensure we have at least 2 approvals from existing maintainers.
Template call to action
SPECIALITY Maintainers, please review this proposal to make TRAINEE maintainer of PROJECT.
* If you have blocking feedback adhering [to the documentation](https://handbook.gitlab.com/handbook/engineering/workflow/code-review/#request-maintainership-feedback) please share it with me privately.
* If you are in agreement, and can vouch for this proposal, please approve.
After 1 week, if there is no blocking feedback and at least 2 approvals, I will merge this MR.Once This MR is Merged
- Join the
#backend_maintainersSlack channel - Remove yourself from
maintainer_mentorship.ymland consider adding yourself as a maintainer mentor. - Let a maintainer add you to
gitlab-org/maintainers/rails-backendwithOwneraccess level. - Let a maintainer change your role in
gitlab-org/gitlabtoMaintainer. - Announce it everywhere
- Familiarize yourself with documentation for Merging a merge request
- Review the additional guidelines for BE maintainers
- Keep reviewing, start merging
🤘 😎 🤘
Edited by Armin Pašalić