Wayne Haber

Innersource Summit - How GitLab breaks down barriers leveraging open-source processes to increase collaboration during the software development process It was a pleasure to present how GitLab breaks down barriers at the recent InnerSource summit.   DRI  (Directly responsible individual): Priorities for engineering teams are primarily set by product managers as the DRI in conjunction with their stakeholders, including the engineering managers, sales, support, etc. The backlog is actively managed by the product manager and engineering manager. Transparency : Employees can comment on any epics and the issues they break down into.  The general public can also do this for a significant portion of them.   The author of a change can be an employee on a team responsible for a section of code, an employee from another team, or the general public. The author creates and tests the change manually and by observing the results of the automated test cases and security scanning. The author then label

 It was great to be a part of the Fail Faster #podcast.  The theme was Continuous Growth with Continuous Iteration. We talk about how bringing transparency and constantly iterating leads to growth and fulfillment. We also discussed applying machine learning to improve the user experience. Podcast link

Blog My blog on the top five actions engineers should take based on the OWASP Top 10 2021 security updates was published today.  Blog: https://about.gitlab.com/blog/2021/11/15/top-five-actions-owasp-2021/ Trends It was also great to see the OWASP top 10 trends over the years graph that I created used in this GitLab blog and by others outside the company who came across it and found it to be useful.  It even made the front page of hackernews for a short time 😀 https://news.ycombinator.com/item?id=28938504 Animation: https://public.flourish.studio/visualisation/7574790/?utm_source=embed&utm_campaign=visualisation/7574790 Static:

  I had an idea to help make GitLab team members more proactively aware of email delivery issues that can cause issues for our user base. I was able to "get my hands dirty again" and wrote some code for an MVC. Fun! I collaborated with a couple of team members to improve my plans. Nice! I released it open-source. Check it out here: https://gitlab.com/gitlab-org/growth/issue-to-email-monitor/-/blob/main/README.md Cool! I brought it live. Sweet! I am now open to volunteers to collaborate to improve it (both GitLab team members and the general public). Marvelous!   In other words..#anyonecancontribute A little about the monitor: This monitor determines if there are issues observing from the time a GitLab issue is created to the time an email about the issue is received. This allows us to know how long the emails take to be delivered as this can impact user satisfaction based on the timeliness of receiving these updates. Many of the same components are used as a part o

 Great discussion with  Wayne Haber is Director of Engineering said about his work, How things works And What Drives Him, His Motivation, How He Solves Problems Get Solutions, Some Crucial And Key Points Was Intriguing, Its Nice To Project Him On My Show.

 It was a fun project to lead the effort to put together this reliability training for developers.   At GitLab, we have a focus on reliability in engineering. We have made many changes to our handbook, production documentation, and processes. While we have announced them via multimodal communication (engineering week in review document, slack, email, meetings, etc), not everyone has likely seen and internalized all of the important changes. We gathered all the crucial changes, explain why we made them, discuss a summary, and link to where you can find more information. Most of this training is available to the public. Some content is GitLab specific and some apply to any company focusing on reliability in engineering. The topics include:     The business impact of reliability     Reliability and values     Blameless culture     Limiting the impact of far-reaching work     Risk mapping     Change acceptance checklists     Definition of done     Backward compatibility     Error budgets