Skip to content

Add Dave Pisek as Frontend Maintainer

David Pisek requested to merge dpisek-frontend-maintainer into master

Self-assessment

Hi there, fellow frontenders!

It’s about time, so here it goes: Please consider this MR to add me as a frontend maintainer 🙂

Why do I think I should be a maintainer

  • Growth mindset: I see every MR as a vehicle to learn and share knowledge. This includes finding out about features, best practices, patterns and ways of solving problems, UX solutions, shared components, APIs, … the list is long.
  • I took my time to be sure that I am ready. During my trainee maintainer period, I’ve tried to get to know as much as possible about our codebase and find my own review style.
  • Bias towards iteration: whenever possible I try to make optional suggestions with the possibility of tackling it in a follow-up. Larger suggestions I always try out on my local machine and then pack them into a patch to maybe help save everyone a bit of time.
  • Local testing: Learning about all of our features can be overwhelming, but by trying out as many changes as possible on my local machine I get a sense of what’s in the works. Having another person testing changes can help ensure quality too.
  • I try my best to give suggestions context and provide links to related resources when applicable.
  • Last but not least I think trying to create a good vibe is also very instrumental in keeping a good culture and team spirit. It should also be seen as a tool for us to get to know each other.
  • My main areas of interest are: GraphQL, testing, web standards, and accessibility (got so much to learn in all areas, but that’s where my current passion is)
  • Other areas I want to improve: Architectural thinking, staying up-to-date with frontend initiatives, RFCs, etc.
  • Special thanks to @ekigbo for providing an amazing support as a (unofficial) mentor - would not feel ready without you!

It's hard to specify hard requirements for becoming a maintainer, which is why the documentation consists of flexible guidelines. Nevertheless, it's still important to have a more formal list to help both a candidate and their manager to assess the "readiness" of the candidate.

  • Advanced understanding of the GitLab project as per the documentation:

    good feel for the project codebase, expertise in one or more domains, and deep understanding of our coding standards

  • 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.

Links to Non-Trival MRs I've Reviewed

Here is a link to my trainee maintainer issue: #5754 (closed)

Links to Non-Trivial MRs I've Written

Examples of challenging situations

One of our recent feature additions (security-training integration) required us to show different UI elements for non-ultimate users. We tried to solve this by using a GraphQL query that would provide us with the current license.

It all worked fine locally, went through reviews, and was deployed to production. Until we got users reporting that parts of the UI were not rendering as expected.

I was available to debug the issue and after seeing a GraphQL error on production I reached out to GraphQL experts on slack to find out more about it. It turned out that the query returned an error field unless the current user had admin-level privileges. This was by design.

The quickest way to mitigate the issue was to add a handler, which would make sure the UI renders if the query resulted in an error.

The drawback of this approach was that the initial intention of the change - to show different content for non-ultimate users - would temporarily be reverted, but at least the UI would be usable again. In parallel, we could start working on a long-term fix.

After coming up with that plan I reached out to another team member to double-check the approach and coordinate the effort. We agreed that this would be the best way forward and got the initial fix merged within an hour 😅

Link to the MR: gitlab-org/gitlab!86619 (merged)

Other contributions

  • Onboarding buddy multiple times
  • Added a few of gitlab-ui components and helpers: intersperse , sparkline charts, resize observer
  • Added Vue directive for hooking into HTML5 form validation feedback app/assets/javascripts/vue_shared/directives/validation.js
  • Introduced setWindowLocation jest helper

@gitlab-org/maintainers/frontend please chime in below with your thoughts, and approve this MR if you agree.

Once This MR is Merged

  1. Create an access request for maintainer access to gitlab-org/<project>.
  2. Join the [at]frontend-maintainers slack group
  3. Let a maintainer add you to gitlab-org/maintainers/frontend
  4. Announce it everywhere
  5. Keep reviewing, start merging 🤘 😎 🤘
Edited by Neil McCorrison

Merge request reports