People:removing roadblocks to productivity/project dev qualityoflife

From MozillaWiki
Jump to navigation Jump to search

Developer Quality of Life

Project manager: Chris Peterson

How to get involved

What we heard

Shorter term actions

These are things we expect to accomplish in 2014.

Longer term changes / shifts

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

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. http://www.squarefree.com/2009/04/20/getting-bugs-done/. 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
    • 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
Retrieved from "https://wiki.mozilla.org/index.php?title=People:removing_roadblocks_to_productivity/project_dev_qualityoflife&oldid=974638"