User Experience SIG - January 14, 2026

Contributing UX SIG
,
1

2026-01-14T17:00:00Z

  • Attending

    • Mark Waite
    • Jan Faracik
    • Juidth Lopez
    • Shreyash Purankar
    • Kris Stern

  • Many UI changes coming in the next LTS behind feature flags

  • Demo

  • Active work in Jenkins core (26 with web-ui label)

    • How to manage the new contributors?
      • Mark will send a proposal next week to Jenkins developers list
        • Update governance document with some additional concepts
      • Mark is using GitHub Copilot to review pull requests from new contributors
        • Results have been very, very good
      • Some examples:
      • Mistakes and their consequences
        • Mark posted to gsoc-sig
        • Failure to use pull request template - ask to use template, close if they don’t act on feedback?
        • Failure to describe testing done - ask for testing details, close if not provided in 24 hours?
        • Unrelated changes included in the pull request - ask to remove, close if not done in 24 hours?
        • Failure to accept design guidance - immediately close?
      • AI policy?
        • Less of a concern for Mark than the concern that contributors are responsible for pull request content
        • Developer list discussion for alternatives
          • Pull request authors are responsible for the content of the pull request

  • From the gsoc sig - Mark Waite’s comments

How to sabotage yourself as a new contributor - by Mark Waite

  • Don’t duplicate the bug before you try to fix it. By not duplicating the bug first, you’ll frustrate reviewers by fixing the wrong thing or changing more than is needed
  • Don’t read or follow the contributing guide. By not reading the contributing guide, you’ll frustrate reviewers with missing information and preventable mistakes
  • Don’t test the fix interactively. By not testing the fix interactively, you’ll frustrate reviewers when they test interactively and find the fix is incomplete or wrong
  • Don’t write automated tests for the fix. By not automating the verification of the fix, you’ll frustrate reviewers because they will either need to create that automation themselves or they will need to periodically perform interactive tests to confirm the fix still works
  • Don’t test the fix in the debugger. By not testing the fix in the debugger, you’ll frustrate reviewers when they detect logic errors you could have found yourself
  • Don’t use the pull request template when submitting the pull request. By not using the pull request template, you’ll frustrate reviewers by missing important information
  • Don’t run automated tests. By not running automated tests yourself, you’ll frustrate reviewers by having test failures on ci.jenkins.io that you could have found and fixed yourself
  • Don’t complete the pull request template. By ignoring or skipping things from the pull request template, you’ll frustrate reviewers by missing important information
  • Don’t take action on review comments. By not acting on review comments, you’ll frustrate reviewers as they think their review is not valuable
  • Don’t wait at least 3 days before asking for a review or an update on the status of a contribution. By rapidly or frequently asking for a review, you’ll frustrate reviewers who are working in many places and contributing from their limited time

That list is certainly not the ultimate list, but it highlights problems seen recently with submissions from new contributors. Please:

  • Duplicate the bug before trying to fix it
  • Read and follow the contributing guide
  • Test changes interactively
  • Create automated tests that show the problem is fixed
  • Test changes in the debugger so that you see them execute
  • Run automated tests locally before submitting a pull request
  • Use the pull request template and provide all the information it requests