People:removing roadblocks to productivity/project dev qualityoflife

From MozillaWiki
Jump to: navigation, search

Developer Quality of Life

Project manager: Chris Peterson

How to get involved

What we heard

  • Bugzilla is slow
  • TBPL and Try servers are slow
  • Tests are slow and flaky
  • Reviews are slow
  • Technical debt is growing
  • Tools are outdated and crufty
  • Documentation is missing

Shorter term actions

These are things we expect to accomplish in 2014.

Taras Glek's team is actively working on bringing Mozilla's rel eng infrastructure into the 21st century, including optimizing our cloud infrastructure for faster and cheaper TBPL and Try builds. Mark Côté's team has multiple engineers dedicated to Bugzilla features and performance.

Some projects in the works for 2014:

  • Pull-request-style development
    • Stand up Review Board server (bug 515210) planned for 2014 Q2
      • DVCS-aware for smarter diffs and revision history from
      • mach integration
      • Automatic BMO account integration
      • Join the mozilla-code-review mailing list for design discussions
    • Autoland (sheriff-initiated, hg-to-hg transplant) planned for 2014 Q3: bug 1017736

Longer term changes / shifts

These are things we expect will take time, influence, and repetition to shift.

  • Technical debt is not a technical problem; it's a prioritization problem. Technical debt is a fact of life and doesn't have a one-time fix. Developers and management need to negotiate a balance between new feature development and cleaning up technical debt. Can Mozilla leverage its large community of contributors to scale up work on technical debt?
  • Documentation is a challenge for most projects, especially for fast-moving open-source projects. Some teams are moving their documentation into mozilla-central so changes to code and documentation can be tracked in one place. Documentation is another area where Mozilla's large community may be able to help.
  • Code reviews are a common concern. Better tools like Review Board should make reviews faster and more productive, but we can also investigate ways to mentor new reviewers and share the review load.
  • New rel eng services, and also the Automation & Tools team's Treeherder project (TBPL 2.0).

Responses in this category

  • Half my bugs fall through the cracks unless I spend an inordinate amount of time and emotional energy advocating for them to be fixed. 55 votes
  • Very little time to address technical debt in code bases and bring them up to standard until it gets too bad, then just enough is done. 37 votes
  • Undated documentation (lots of docs, but the status is not always clear). 29 votes
  • Slow reviews. 26 votes
  • Lack of documentation. 25 votes
  • Documentation that doesn't exist, is out of date, or is difficult to find. 24 votes
  • Lack of infrastructure integration: Code review, building, testing, integration horribly disjointed. 22 votes
  • Try pushes take a very long time to complete. 20 votes
  • No team dedicated to creating tools to improve developer's lives leading to developers doing it themselves. 15 votes
  • Intermittent orange tests - if we could clear those out and work to re-integrate them when no longer intermittent we could have straight forward pass/fail on builds, better regression finding. 15 votes
  • B2G and Gecko essentially being different projects causing differences development model that are counterproductive to our goals. 12 votes
  • C++ 9 votes
  • Not giving enough priority to the quality of tests run in automation. Slow and flaky tests lead to more backouts and waiting a long time to get results from your push. 7 votes
  • Finding out "what is needed to move this bug forward?" requires looking at many fields. This may contribute to bugs falling through the cracks. 7 votes
  • Systematic and pervasive unwillingness to prioritize paying down tech debt; workarounds include hiring more people to prop up unwieldy systems or building new half-baked tools because the old half-baked tools "suck". 7 votes
  • Fighting with git. 7 Votes
  • Inconsistent test results of Travis, try server and local environment. 6 votes
  • Incoherent and disjoint tools situation for building and testing. 5 votes
  • Lack of unit tests, staging environments for many tools/services makes changing them more difficult. 4 votes
  • TBPL's job-oriented display hides what's really interesting: which individual tests failed, and how. 4 votes
  • 300 devs in large interdependent legacy codebase = slow feature development. 3 votes
  • Poor tools for internal developers. On a macro scale, we have very little investment in bugzilla, no one is full time on the build system, tbpl needs an overhaul, and often I have to print to debug. 3 votes
  • Complete lack of process/documentation. 2 votes
    • Bugzilla searches are slow. 25 votes
    • I have not found a way to quickly respond to needinfo requests that does not involve reading bugmail threads multiple times and out of order. 11 votes
    • Mid-air bugzilla collisions that require you to re-change flags, etc. 3 votes
    • Thunderbird does not show subjects for encrypted bugmail. 2 votes